Hi Joël, Atomic operations are by "convention" (and here I'll refer to Tannebaum etc.) put inside of "critical areas" that you protect with something like a mutex/semaphore/etc. that provides the needed concurrency prevention, but needs to be made fine grained, ie. each variable/operation shared should have it's own mutex/semaphore/etc. Atomic operations, as in single instructions, are only really "guaranteed" at the assembler level for the CPU instruction(s) that the CPU(s) are able to guarantee atomicity, and mutexes/semaphores/etc. are implemented using those low level instructions, to provide you with the needed abstraction without having to know the specifics of the CPU (ie. Sparc/x86/Itanium/ARM/PowerPC/etc.). To make it more "intuitive, you could always abstract the specific atomic updates/operation in a function call and just declare it inline etc. for performance On Fri, Apr 10, 2015 at 1:37 AM, Joël Krähemann <weedlight@xxxxxxxxx> wrote: > Hi, earlier me experienced problems by using atomic operations on GNU/Linux. > Are there functional tests out there me could run? The root case is > uncertain because there were known issues like unsigned long overflow and > concurrent read access. > > I'm developing a music sequencer and dealing often with threads. For now me > did a work-around using mutices. But me intend to use atomic operations > again because it makes more intuitive and simpler. > > http://gsequencer.org is hosted on GitHub as > https://github.com/weedlight/ags-devel > > For the grand picture the engine is running and me adjust dial widget to > modify AgsPort field by atomic operations. > > At the moment me tries to bring 0.4.2 version to a successful end, marked as > stable. > > kind regards, > Joël > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-c-programming" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
