Re: WaitForSingleObject() will not deadlock
On Wed, 04 Jul 2007 01:15:31 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
Actually, all I found in the Butenhof reference was a quote from Alice in Wonderland, and
the next page is 97, thus skipping everything in between.
Oh well, I was skeptical the Google Books link would work, and now I know
it doesn't. (I was really surprised to find the whole text of the book
available to me; it must be a great comfort to the publisher/author that
it's not linkable.) Anyway, here is what I was trying to link to:
"Programming with POSIX Threads", page 89
<q>
1. Whatever memory values a thread can see when it creates a new thread can
also be seen by the new thread once it starts. Any data written to memory
after the new thread is created may not necessarily be seen by the new
thread, even if the write occurs before the thread starts.
2. Whatever memory values a thread can see when it unlocks a mutex (leaves
a synchronized method or block in Java), either directly or by waiting on a
condition variable (calling wait in Java), can also be seen by any thread
that later locks the same mutex. Again, data written after the mutex is
unlocked may not necessarily be seen by the thread that locks the mutex,
even if the write occurs before the lock.
3. Whatever memory values a thread can see when it terminates, either by
cancellation, returning from its run method, or exiting, can also be seen
by the thread that joins with the terminated thread by calling join on that
thread. And, of course, data written after the thread terminates may not
necessarily be seen by the thread that joins, even if the write occurs
before the join.
4. Whatever memory values a thread can see when it signals or broadcasts a
condition variable (calling notify in Java) can also be seen by any thread
that is awakened by that signal or broadcast. And, one more time, data
written after the signal or broadcast may not necessarily be seen by the
thread that wakes up, even if it occurs before it awakens.
</q>
No surprises there. The MSDN link indicates this applies to other sync
objects plus CRITICAL_SECTION. It's nice for it to be stated, but for all
the reasons we've talked about, it couldn't be any other way. For Windows,
I expect you could add:
5. Whatever memory values a thread can see when it calls PostMessage or
SendMessage can also be seen by the thread that retrieves or processes the
message.
I don't recall seeing any explicit statement of this, but again, I don't
see how it could be otherwise.
Memory ordering (which I would not have thought of as "memory visibility guarantees") is
an ancient topic.
In this context of using synchronization objects such as mutexes,
"visibility" subsumes "ordering".
--
Doug Harrison
Visual C++ MVP