Subj : Re: posix and lock-free algorithms To : comp.programming.threads From : David Hopwood Date : Thu Aug 04 2005 09:33 pm Sean Kelly wrote: > David Schwartz wrote: >>"David Hopwood" wrote: >> >>>"Applications shall ensure that access to any memory location by more >>> than one thread of control (threads or processes) is restricted such >>> that no thread of control can read or modify a memory location while >>> another thread of control may be modifying it." >> >> That still bites you. > > Out of curiosity, is this a rule that is always adhered to or do some > folks bend the rules if they're targeting specific hardware? In other > words, if I wrote inline asm on a POSIX system that code contained > memory ordering instructions, how likely is it that the code block > would not behave as intended? Basically, I'm wondering whether/how > anyone does lockless programming on such systems if the spec makes no > guarantees about correct behavior. At the moment, very few people intentionally do lock-free programming. Getting away with not using locks is a different thing entirely. Recently I wrote a prototype of a multi-threaded embedded app that relied on release consistency; it was to be used only on x86 Windows (although the differences from POSIX are not important in this case). The application worked, and I was reasonably confident that I knew why it worked. Still, I ended up deciding never to do that again. The main reason was the difficulty I would have had in explaining to other people how and why it worked. Also, even though the program was quite small (10000 lines of C; 6 threads), the complexity of communication between threads was getting near the limit of what would have been maintainable. To simplify it, I was progressively rewriting the code to use message passing, although the project failed for unrelated (hardware) reasons before that could be finished. -- David Hopwood .