Subj : Re: YALFAm (Yet Another Lock Free Approach, maybe) To : comp.programming.threads From : Joe Seigh Date : Thu May 19 2005 10:07 am On Thu, 19 May 2005 12:08:37 GMT, David Butenhof wrote: > Chris Thomasson wrote: >>> Even with the _InterlockedCompareExchange() intrinsic function on Windows? >> >> Well, I am "not totally sure" of Microsoft's specific guarantees wrt >> implementing sensitive multi-threaded algorithms. It might be safe... >> >> Yet again, it might not be so safe after all... > > Gee, Chris. I have this odd feeling of deja vu. Haven't we, uh, been > here before? ;-) > > The problem with all this is that Microsoft code and documentation was > written for a really primitive in-order X86 architecture. The code has > been adapted somewhat randomly along the way, documentation has not been > updated to reflect DESIGN INTENT, and in fact it's by no means clear > that there really IS any design intent. > > So you can experiment and bet your code that they INTEND it to do what > you currently observe, and risk that they'll change it, and that future > adaptations will remain true to your assumption... or you can play a > little safer and go by the most loose interpretation of what they > actually SAY. Or you can be paranoid and assume they'll probably screw > it up in the future for their own reasons (or for no reason at all), and > not trust it as far as it could throw you... > Yes, we have been here before. This is the "Microsoft has no formal explicit semanitcs but neither does Posix". The only thing we can say about Posix is there are a few well know thread design patterns that are widely considered as being supposed to work in Posix. DCL (DCSI) as being an example of a pattern that does not work in Posix. I'd name some patters that do work in Posix but I don't think we have names for those patterns. There's some work being done to define a formal thread model for C++ but looking at the mailing list discussion so far, they look on track to become the poster child of how not to do it, i.e. using a meta implementation to define semantics. Plus they're forgetting that part of what started people to seriously consider formally defining threads for C++ was lock-free programming which depends heavily on pointers and pointer abstraction. And C++ pointer abstraction is somewhat lame to make an understatement. If they would look at Java, they would see that there is great reliance on being able to distinquish between thread local references and heap references, the JVM exploiting the level of pointer indirection that occurs in the JVM. Considering there's two people that have a background in Java threads, that's rather strange oversight. I suspect after all the work is done on the C++ thread model you will end up with stuff that will be considered unsafe to run on any system but Microsoft windows which has a high tolerance for errors (by windows users that is, not the OS). Which is where we are today. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software. .