Boost logo

Boost Users :

From: Mark Sizer (yg-boost-users_at_[hidden])
Date: 2003-07-31 18:10:42

Jason Winnebeck wrote:

> Mark Sizer wrote:
>>Generically, the difference between critical sections and mutexes is
>>immense. In terms of implementation, one never knows.
>>A critical section blocks EVERYTHING else in the process. A mutex only
>>blocks things that are waiting on that particular mutex.
> Are you absolutely serious/sure about that? I've been using critical
> sections becauase I couldn't find a reason to use mutexes. So far I've
> only run my program on single processor machines (where it probably
> doesn't matter), but I'd hate to think I would have a huge amount of
> contention on multiprocessor machines.
> I can see how crit secs can be faster on a single CPU machine with those
> semantics, because when you schedule the process, you just decide to
> only schedule that thread. And on a single CPU just setting a flag
> should work and be safe to do.
> Jason

I wouldn't bet my life, or even a paycheck on it, but I'm pretty sure.
It may be a distinction that some book made years ago that has stuck in
my head.

Here's MSDN's summary (not that I'm claiming MSDN is authoritative):

Critical section objects provide synchronization similar to that
provided by mutex objects, except that critical section objects can be
used only by the threads of a single process. Event, mutex, and
semaphore objects can also be used in a single-process application, but
critical section objects provide a slightly faster, more efficient
mechanism for mutual-exclusion synchronization (a processor-specific
test and set instruction). Like a mutex object, a critical section
object can be owned by only one thread at a time, which makes it useful
for protecting a shared resource from simultaneous access. There is no
guarantee about the order in which threads will obtain ownership of the
critical section, however, the system will be fair to all threads.
Unlike a mutex object, there is no way to tell whether a critical
section has been abandoned.

The efficiency issue implied here could be that mutexes can be named
objects shared across PROCESSES, not just threads within a process. That
would not apply to boost::mutexes - they're not named.

The Win32 critical section API does seem to imply that there are more
than one of them - otherwise why pass a pointer?

A google search of "POSIX critical section" turned up the fact that
POSIX mutexes are generally implemented under Windows as CriticalSections.

It's looking like a case where the terms are interchangeable without a
VERY specific context. It looks like I'm wrong :(

- Mark

P.S. I checked a couple of old textbooks I have on my bookshelf and I
couldn't find the distinction I recall, either.

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at