ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Glib provides a set of functions to atomically read and set int and void* values. The documentation says that, where possible, this uses atomic write, read, and test operations provided by the specific architecture, and where the architecture doesn't support it glib uses slower backups.
My question is, are these or any similar functions likely to play well with bit fields? I'm looking to write an application that would require lightning-fast IPC between two processes, and I'm looking to use SysV style shared memory to fit the task. In the structure I'm creating I thought that I'd use a single unsigned char of data to represent eight different pollable flags. I'd rather not implement a semaphore for each value.
As you might have guessed, performance and memory footprint are at a premium here - hence the bothering with bit fields.
The question's over, but in case you're wondering, the application is a (very experimental, design phase) VFS. I don't feel like gnome-vfs or KIO will reconcile very soon, and I don't like the freedesktop.org assumption that a VFS is for desktop (graphical) apps only, so I'm starting to design one myself. If this ever becomes more than a crazy idea in my head and ravings on paper, I'll get a sourceforge and let you know then.
A spin lock is pretty much exactly what I'm trying to implement. I'm just trying to keepdown the amount of shared memory required by using 1-bit booleans. Unfortunately for me, It appears that atomic operations only play well with an entire int or pointer, so I guess I'll have to use 32 bit booleans.
To avoid uncertainty about interrupting access to a variable, you can use a particular data type for which access is always atomic: sig_atomic_t. Reading and writing this data type is guaranteed to happen in a single instruction, so there's no way for a handler to run "in the middle" of an access.
The type sig_atomic_t is always an integer data type, but which one it is, and how many bits it contains, may vary from machine to machine.
Data Type: sig_atomic_t
This is an integer data type. Objects of this type are always accessed atomically.
In practice, you can assume that int and other integer types no longer than int are atomic. You can also assume that pointer types are atomic; that is very convenient. Both of these are true on all of the machines that the GNU C library supports, and on all POSIX systems we know of.
Go to the previous, next section.
So, int and smaller is atomic? If this were the case then why have atomic libraries. I had thought that this was not the case. I found the info here: