Re: A Quick Question about Threads

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):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/critical_section_objects.asp

<quote>
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.
</quote>

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.