Re: WaitForSingleObject() will not deadlock

On Wed, 04 Jul 2007 01:15:31 -0400, Joseph M. Newcomer
<newcomer@xxxxxxxxxxxx> 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
.

Relevant Pages

  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... Whatever memory values a thread can see when it unlocks a mutex (leaves ... situation of this nature on any closely-coupled MIMD architecture, ... can exist in a distributed MIMD architecture, but in that case, the mutice have to keep ...
    (microsoft.public.vc.mfc)
  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... data written after the mutex is ... standardized multithreading library designed to run efficiently on existing ... A C compiler is not required to do this, and it can still be a conforming C ...
    (microsoft.public.vc.mfc)
  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... and after the clause, "However, if you were to uncomment the line that sets ... data written after the mutex is ... No, you have to lock the same mutex, and reflects that. ...
    (microsoft.public.vc.mfc)
  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... and after the clause, "However, if you were to uncomment the line that sets ... data written after the mutex is ... No, you have to lock the same mutex, and reflects that. ...
    (microsoft.public.vc.mfc)
  • Re: Emulating PTHREAD_MUTEX_RECURSIVE - recursive mutex implementation...
    ... turned out to be non-recursive mutex deadlock - and that was not the ... found non-recursive mutex to lead to more complex code in general. ... In my memory allocator, there is a possibility to get memory profile ...
    (comp.programming.threads)