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