Re: WaitForSingleObject() will not deadlock

On Sun, 08 Jul 2007 23:15:22 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:


No, it does not. The value of having a standard is that you can say things
like the following. (We in the Windows world have to rely on the fact that
it would be stupid to make weaker guarantees than POSIX does, because then
it would require us to use losing practices such as requiring volatile on
top of synchronization, which is a non-viable approach, as I've explained
elsewhere in this thread.)

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/2541783548d3c2e4/bc199a2e3f1c3fbb?#bc199a2e3f1c3fbb
<q>
....
Instead, one writes POSIX 1003.1c-1995 code, (or "UI thread" code, or even
Win32 threaded code), which is BASED ON ANSI C (but is NOT ANSI C), and
provides ON TOP OF ANSI C support for multithreaded programming that DOES
NOT require volatile (and in fact cannot benefit from use of volatile).
Such code, to redundantly reiterate yet again, is NOT, repeat, NOT strict
ANSI C. Its behavior cannot be explained, described, or reasoned about
simply in terms of the ANSI C specification, no matter how expert one might
be in the nuances of that standard. Again, (yes, once again redundantly
reiterating), THREADED CODE IS NOT ANSI C.

And that's really all there is to it.

To put this another way, it's perfectly legal for an ANSI C compiler to
apply optimizations that would break threaded code by invalidating data
visibility requirements. (Though in practice expert compiler developers
tell me such optimizations are extraordinarily difficult to exploit in
practice, and at least as of several years ago nobody was aware of anyone
who had succeeded.) But such a compiler, while it might be 100% conformant
to ANSI C requirements, and might seem "really cool" from a myopic ANSI C
point of view, is NOT a POSIX conforming compiler, and cannot be used for
threaded programming. "Correct" is often a relative statement. (As Obi Wan
put it, "Many of the truths we cling to depend greatly on our point of
view.")
....
</q>

--
Doug Harrison
Visual C++ MVP