Re: WaitForSingleObject() will not deadlock
On Mon, 09 Jul 2007 10:13:39 -0700, Frank Cusack <fcusack@fcusack.com>
wrote:
I'm saying that even if the compiler CAN see into CreateThread
(e.g. if you are building an entire platform from scratch, say a
kernel with its own kernel-level threads library), CreateThread
will be sufficiently complex that it can't tell if x is reachable.
I think that's a pretty big leap of faith. Forget about CreateThread then.
There's also mutex lock/unlock.
And therefore NOT being able to see into CreateThread is not the
magic that prevents code motion. Of course it makes things go
faster if the compiler can't see into CreateThread.
The difference between "not being able to see into it" and "being able to
see into it and hoping the function is sufficiently complex" is the
difference between guaranteed and non-guaranteed. I wrote earlier about
mutex lock/unlock in my example that showed the compiler looking into empty
"lock/unlock" functions:
<q>
Finally, imagine the compiler *can* actually see into lock/unlock, wherever
they reside, and those functions are implemented as mutex lock/unlock
operations. Per the example I just presented, it would be able to tell they
don't modify x, and it could optimize f() as shown above. Clearly, that
would be wrong for MT programming. The absolutely wrong approach to solving
this problem would be to require the user to make x volatile; that was the
shortcoming of the ancient compilers you talked about earlier. The *right*
approach would be to provide some way to mark lock/unlock as having "memory
barrier" semantics. (Of course, if the compiler can see into those
functions and they actually contain memory barrier instructions, it should
be unnecessary to mark them as special, because the compiler should
understand what is implied by using memory barriers.)
</q>
The point is, you can't just *hope* the function in question is
"sufficiently complex" to prevent an unsafe optimization. You have to
*define* the conditions that will prevent those optimizations and program
accordingly. "Not being able to see into an opaque DLL" is such a
condition.
--
Doug Harrison
Visual C++ MVP