Hi Tim, thanks, that was very helpful. Unfortunately, I am only now finally getting back to looking into this again.
On Tue, Aug 27, 2013 at 11:50 AM, Tim Goetze <[email protected]> wrote: > It's been a while since I did some research: IIrc on i386, 32-bit read > or write access is atomic if the variable address is 32-bit aligned, > while on ARM only byte-size read and write operations are atomic, > regardless of alignment. (On a sidenote, it is not realistic to > expect gcc to honour alignment instructions.) I take from this that it's generally not safe to assume that any read or write operation is atomic, because I can't reliably control alignment. Indeed, this is the general impression I get from reading and searching on the web (mostly StackOverflow). I stumbled upon this superb talk by Herb Sutter [1], which really made things a lot clearer to me. My understanding now is that: 1. Atomicity (meaning atomic read and write) in and by itself is not enough. I also need to ensure that memory access does not get reordered across my atomic reads and writes (so that, for example, I don't happen to increase the write counter before the data is actually written to the buffer). 2. To ensure atomicity and to enforce these memory barriers I always need some (cpu/architecture specific) special instructions. It looks like C++11 actually now has support for atomic operations which fulfill the above two points, so I'll likely try to go down that route. Does anybody have experience with the new C++ atomic header? > For passing data between threads locklessly in a deterministic manner, > I'd recommend a FIFO, which you can build with byte-sized counters. I am using two queues, one to pass messages from the gui to the engine, and one the other way around. Still, for largish data structures it does not seem practical to copy them back and forth between the threads so I need to be careful how I update these data structures. Cheers, Burkhard [1] http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
