Re: WaitForSingleObject() will not deadlock
On Sat, 07 Jul 2007 13:42:54 -0700, Frank Cusack <fcusack@fcusack.com>
wrote:
On Sat, 07 Jul 2007 14:05:46 -0500 "Doug Harrison [MVP]" <dsh@mvps.org> wrote:
On Fri, 06 Jul 2007 16:32:46 -0700, Frank Cusack <fcusack@fcusack.com>
wrote:
Imagine this code:
enter_critical_section();
write(some_data);
write(more_data);
leave_critical_section();
You could use such a construct to guarantee that the two write()s here
are not interleaved with other write()s. This does not require a membar
and so could be implemented with a semaphore that doesn't issue membars.
If "write" involves writing to memory and doesn't do any synchronization of
its own, you still need memory barriers to prevent the memory updates from
moving outside the faux "critical section" (at the hardware level, at
least), where they can interleave.
Yes, write() would itself require a membar. No need (in this example)
to also add that overhead to the surrounding enter/leave.
I believe most people think of mutexes when they hear the term "critical
section", and I also think most people have never written a "critical
section" that works like you've described. You are constraining write order
at the hardware level inside the protected region, and ordinarily, that can
be ignored. In fact, it routinely is ignored. No, "routinely" is too weak a
characterization; "almost always" captures the reality of it better.
While waiting for a cite that says POSIX semaphores don't guarantee memory
visibility, I found this thread:
fast semaphore implementation requires acquire/release?
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/1e95305148e02caf/7fcb2814e78c1bd7?#7fcb2814e78c1bd7
It starts off:
<q>
Somebody posted a "fast semaphore" implementation here some time ago and
it was implemented using atomic operations. However, it had no memory
barrier calls in it, which implies that if the user of it wants to
synchronize memory, the user would have to do that himself. This seems
to me to be out of line with user expectations and out of line with
current Posix and WinNT OS semaphore implementations.
</q>
Some immediate replies included:
Message 2
<q>
The windows interlocked operations do have memory barrier properties so
that "fast semaphore" implementation does have memory synchronization.
</q>
Message 34
<q>
Apart from blocking, semas are basically atomic flags or counts. Given
that the least surprising behavior is sequential consistency, semaphore
operations (lock/unlock/getvalue) should better be fully-fenced and
provide illusion of the so-called "remote write atomicity". Note that
mutexes (vs semas) are much less heavier in this respect.
</q>
Two things stand out:
1. Even the "fast" semaphore is fenced.
2. Mutexes are less constrained than semaphores.
All the responses I read seem to agree that POSIX semaphores are fenced.
--
Doug Harrison
Visual C++ MVP