Re: WaitForSingleObject() will not deadlock
On Sun, 08 Jul 2007 13:47:34 -0700, Frank Cusack <fcusack@fcusack.com>
wrote:
On Sat, 07 Jul 2007 15:58:15 -0500 "Doug Harrison [MVP]" <dsh@mvps.org> wrote:
behavior", it has to perform the assignment "x = 2" before calling rand()
and can't move "x = 3" above the rand() call. Coincidentally, and let me
stress for Joe, COINCIDENTALLY, this also tends to help multithreaded code,
because typically the compiler cannot see into functions like CreateThread
and mutex operations so must assume they can use x in ways that affect
"observable behavior".
Not being able to see into CreateThread shouldn't actually matter.
If the compiler CAN see into CreateThread, it will find that either it
can't tell whether or not CreateThread (recursively) will reference x,
or that yes, x is referenced.
I don't follow you. If it can't see into CreateThread, it must assume the
global x is reachable from CreateThread. Because it can't see into
CreateThread, MS is saved from having to mark CreateThread "special" or
making the compiler appreciate the significance of the memory barrier or
whatever CreateThread does to ensure Rule (1) is satisfied.
For mutex operations, not being able to see into them may indeed be
what makes it work.
It's the same principle at work as for CreateThread.
Or, and this is not an ISO C requirement AFAIK,
seeing that the mutex operation executes a membar may inform the
compiler that it can't do certain optimizations around the mutex call.
ISO C never heard of "mutexes" or "membars". All multithreading issues are
outside the scope of the current C and C++ Standards.
I imagine that compilers which can do inter-procedural-optimization
(most of them these days) must have special support for this.
Right, as I've said, if that were an issue, there would have to be a way to
suppress thread-unsafe optimizations, and declaring everything volatile
ain't it. Viable approaches include defining a way to mark functions
"special" or having the compiler recognize memory fences. (Note that VC8
does perform interprocedural optimization including link-time code
generation.)
--
Doug Harrison
Visual C++ MVP