Re: [Boost-Users] Re: A Quick Question about Threads

From: Richard Howells (Richard_at_[hidden])
Date: 2003-08-01 03:18:14

Mark,

You may be in good company here. There is a strong myth, that has been
running for years, that a Win32 critical section is a way of obtaining
*exclusive* use of the CPU. It's just plain wrong, but there are a
surprising number of folks who believe it. From that thought, on a
uniprocessor, everything else *would* stop when a thread entered a critical
section.

In a previous life you were likely unlucky enough to get exposed to someone
who told you this.

Best - Richard

----- Original Message ----- 
From: "Mark Sizer" <yg-boost-users_at_[hidden]>
To: <boost-users_at_[hidden]>
Sent: Friday, August 01, 2003 12:10 AM
Subject: [Boost-Users] Re: A Quick Question about Threads

>
>
> 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.
>
>
>
>
>
> Info: <http://www.boost.org>
> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
> Unsubscribe: <mailto:boost-users-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>