Atomic operation question

PatrickNew · 05-09-2007, 05:52 PM

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.

paulsm4 · 05-10-2007, 11:52 AM

It sounds like you want to reinvent a "spinlock" for yourself.

Here are a couple of links that might help:

http://www.open-std.org/jtc1/sc22/wg...007/n2195.html

http://msdn.microsoft.com/msdnmag/is...urrentAffairs/

http://www.cs.usu.edu/~jerry/Classes.../hardware.html

'Hope that helps .. pSM

PatrickNew · 05-10-2007, 01:00 PM

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.

jim mcnamara · 05-11-2007, 05:13 AM

There are "atomic" libraries, too:

http://apr.apache.org/docs/apr/0.9/a....html#_details

PatrickNew · 05-12-2007, 12:11 AM

From some documentation for GLibC

Quote:

Atomic Types

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:

http://www.aquaphoenix.com/ref/gnu_c...60.html#SEC360