Re: WaitForSingleObject() will not deadlock

On Sun, 1 Jul 2007 21:35:36 -0700 "Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> wrote:
CRITICAL_SECTION (EnterCriticalSection, LeaveCriticalSection) provides a
memory fence, too.

Seems expensive then. A pthreads semaphore (typically used to guard a
critical section) has no memory visibility guarantees and as such can
be implemented with so-called atomic ops instead of memory barriers.

CRITICAL_SECTION is fast, intra-process, recursive mutual exclusion
synchronization object.

Not as fast as a pthreads semaphore, since the CRITICAL_SECTION has
to execute a memory barrier (fence).

Kernel mutex (CreateMutex) can be used to synchronize _between_ processes,
too, but since it requires a roundtrip to kernel mode, its overhead is more
than of CRITICAL_SECTION. A kernel mutex also takes care of priority
inversion, which CRITICAL_SECTION does not.

posix mutexes (good implementations, anyway) only require entry into
the kernel when they are contested. Uncontested mutexes are extremely
fast. Solaris has an "adaptive mutex" which only enters the kernel
after spinning for a bit first, which is consistent with the design
philosophy that you should only hold on to mutexes for very short
periods of time. (There are more rules but it's not important to my
point.)

It almost doesn't make sense that CRITICAL_SECTIONs execute a membar
since Windows really only runs on x86, which is TSO. This is probably
just a nod towards more widespread use (ie, less skilled programmers)
who might otherwise get the semantics wrong.

-frank
.

Relevant Pages
Loading