Subj : Re: posix and lock-free algorithms To : comp.programming.threads From : David Schwartz Date : Thu Aug 04 2005 06:24 pm "Sean Kelly" wrote in message news:1123181434.951578.165440@g14g2000cwa.googlegroups.com... > 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. Obviously, if you know every possible thing that could prevent the code from working on a particular combination of compiler, libraries, and hardware and properly address all of those issues, the code will work. In practice, this isn't as difficult as it sounds. The usual practice is to first implement whatever you need in clearly commented, portable POSIX code. Test it and make sure it works. Then, for the platforms you care the most about, write platform-specific replacements and test them independently. It's a good idea to make sure the particular code you're replacing does in fact have a performance impact on each platform where you plan to replace it. And it's also good to make sure the platform-specific code is in fact measurably faster. Otherwise, the added risk, complexity, and fragility isn't worth it. For gcc/x86/Linux it's not too hard at all to implement some simple things in a platform-specific more efficient way that seems safe. For example, atomic 32-bit increments, decrements, and compare-and-swap are trivial to implement and can have a performance impact in some cases. Hand-coded spinlocks, for reasons I've never seem to understand, also seem to outperform the POSIX spinlocks on x86/gcc/Linux. Perhaps the library isn't hyper-threading aware or something, I never tracked down the details. DS .