mutex or critical section

3 views
Skip to first unread message

Alexander Terekhov

unread,
Apr 25, 2002, 5:49:52 PM4/25/02
to
< Followup-To: comp.programming.threads >

Henry Zhang wrote:
>
> I heard it is suggested to use critical section rather than using mutex,
> especially for local processes. is there a reason for that?

Forget it! Instead, check this out:
http://sources.redhat.com/pthreads-win32

regards,
alexander.

Martin Dowie

unread,
Apr 26, 2002, 5:34:41 AM4/26/02
to
> > I heard it is suggested to use critical section rather than using mutex,
> > especially for local processes. is there a reason for that?
>
> Forget it! Instead, check this out:
> http://sources.redhat.com/pthreads-win32

So what? POSIX threads standard defines an *API* and the behaviour
required of the API - it doesn't dictate *how* the API should be
implemented and that is whole point of the OP's question - one
implementation may lead to critical sections that are faster than
mutexes or visa-versa.

Alexander Terekhov

unread,
Apr 26, 2002, 6:23:59 AM4/26/02
to

First, I'd recommend to you, Martin, that before you
begin with your threading carrier, you better first
learn how to properly use usenet. comp.lang.c++
(C++0x/future directions w.r.t. threading aside) has
NOTHING to do with critical sections and/or mutexes.
So, again, and in BOLD text for you now:

< FOLLOWUP-TO: COMP.PROGRAMMING.THREADS >

Martin Dowie wrote:
>
> > > I heard it is suggested to use critical section rather than using mutex,
> > > especially for local processes. is there a reason for that?
> >
> > Forget it! Instead, check this out:
> > http://sources.redhat.com/pthreads-win32
>
> So what?

Click on link and find it out yourself.

> POSIX threads standard defines an *API* and the behaviour
> required of the API - it doesn't dictate *how* the API should be
> implemented and that is whole point of the OP's question - one
> implementation may lead to critical sections that are faster than
> mutexes or visa-versa.

The whole point of the OP's question is whether to use
brain-damaged MS-critical-sections or even more brain-damaged
MS-mutexes. The right answer is "Forget it!", use *standard*
mutexes (normal/error-check/recursive-if-you-are-so-stupid)
which work really well together with condition variables
to build robust/simple/race-free/general/etc. synchronization
protocols. There are some other aspects to it as well, but
that's beyond the scope of the OP's question, I think.

regards,
alexander.

martin.m.dowie

unread,
Apr 26, 2002, 9:26:10 AM4/26/02
to
"Alexander Terekhov" <tere...@web.de> wrote in message
news:3CC92ABF...@web.de...

>
> First, I'd recommend to you, Martin, that before you
> begin with your threading carrier, you better first
> learn how to properly use usenet. comp.lang.c++
> (C++0x/future directions w.r.t. threading aside) has
> NOTHING to do with critical sections and/or mutexes.
> So, again, and in BOLD text for you now:

Apologies for that - I was using the google groups web site
to send that reply for the first time and didn't notice the
usenet groups window...

I notice your replies are going there (comp.lang.c++) too,
by the way. I agree that this is not a C++ specific topic.
[snip]

> The whole point of the OP's question is whether to use
> brain-damaged MS-critical-sections or even more brain-damaged
> MS-mutexes. The right answer is "Forget it!", use *standard*
> mutexes (normal/error-check/recursive-if-you-are-so-stupid)
> which work really well together with condition variables
> to build robust/simple/race-free/general/etc. synchronization
> protocols. There are some other aspects to it as well, but
> that's beyond the scope of the OP's question, I think.

The entire OP is:

"I heard it is suggested to use critical section rather than using mutex,
especially for local processes. is there a reason for that?

thanx a lot!"

Why do you think he is using any Microsoft OS?..

Alexander Terekhov

unread,
Apr 26, 2002, 11:50:03 AM4/26/02
to

"martin.m.dowie" wrote:
[...]

> I notice your replies are going there (comp.lang.c++) too,
> by the way.

Ah... but those are mostly off-topic "shouting match"
replies, nothing more than that! ;-)

[...]


> > The whole point of the OP's question is whether to use
> > brain-damaged MS-critical-sections or even more brain-damaged
> > MS-mutexes. The right answer is "Forget it!", use *standard*
> > mutexes (normal/error-check/recursive-if-you-are-so-stupid)
> > which work really well together with condition variables
> > to build robust/simple/race-free/general/etc. synchronization
> > protocols. There are some other aspects to it as well, but
> > that's beyond the scope of the OP's question, I think.
>
> The entire OP is:
>
> "I heard it is suggested to use critical section rather than using mutex,
> especially for local processes. is there a reason for that?
>
> thanx a lot!"

Yep.

> Why do you think he is using any Microsoft OS?..

Uhmm, what do you mean? And what does this have
to do with POSIX threads emulation layer (on top
of Win32 brain-damaged stuff, BTW) I've recommended
to OP to take a look at/use instead?

regards,
alexander.

martin.m.dowie

unread,
Apr 26, 2002, 2:54:14 PM4/26/02
to
"Alexander Terekhov" <tere...@web.de> wrote in message
news:3CC9772B...@web.de...

Well, the assumption is that OP is using Win32, when he made no sure
statement. He may not have choice in which OS he is using (perhaps it is
Integrity or On-Core or Raven or perhaps its an own-build OS). The point is
that without knowing what OS he _is_ using no one can make much of a claim
about the relative performance of CS v Mutex (even among those which have a
posix api).

It would have been _really_ handy if the OP had mentioned this info... :-)

David Schwartz

unread,
Apr 26, 2002, 5:09:31 PM4/26/02
to
"martin.m.dowie" wrote:

> The entire OP is:
>
> "I heard it is suggested to use critical section rather than using mutex,
> especially for local processes. is there a reason for that?
>
> thanx a lot!"
>
> Why do you think he is using any Microsoft OS?..

Because WIN32 has two mutex-like synchronization primitives, one called
a mutex and one called a critical section. Further, it is suggested to
use a critical section rather than a mutex, especially for local
processes. Do you know of any other platform that has two
synchronization primitives with those names and where critical sections
are especially preferred over mutexes for local processes?

DS

Alexander Terekhov

unread,
Apr 27, 2002, 1:16:32 PM4/27/02
to

BTW, I have a rather interesting link on subject:

http://world.std.com/~jmhart/csmutx.htm

"....
Bottom Line:

1.CRITICAL_SECTIONS only provide high performance
when the process is running in the foreground and
the number of active (ready) threads is limited.

2.A background process, or a process with numerous
active, unserialized, threads can be better off
using a mutex.

3.You should design your threaded applications carefully,
keeping in mind the observations from this relatively
simple test program.

4.Two or more threads running on separate processors
in an SMP system and contending for the same resource
will, in some cases, perform very poorly. ...."

regards,
alexander.

t...@cs.ucr.edu

unread,
Apr 29, 2002, 10:13:43 AM4/29/02
to
Alexander Terekhov <tere...@web.de> wrote:
[...]
: "....
: Bottom Line:

: 1.CRITICAL_SECTIONS only provide high performance
: when the process is running in the foreground and
: the number of active (ready) threads is limited.

: 2.A background process, or a process with numerous
: active, unserialized, threads can be better off
: using a mutex.

: 3.You should design your threaded applications carefully,
: keeping in mind the observations from this relatively
: simple test program.

: 4.Two or more threads running on separate processors
: in an SMP system and contending for the same resource
: will, in some cases, perform very poorly. ...."

I don't understand how MS "critical sections" are supposed to work.
It sounds like they have a user-space spinlock in addition to a mutex.
To acquire the critical section a thread waits on the spinlock util
some wait-time threshhold is exceeded. Then it incurs the overhead of
a mutex call and waits passively on an associated mutex. Is that the
basic idea?

Tom Payne


Alexander Terekhov

unread,
Apr 29, 2002, 10:38:22 AM4/29/02
to

t...@cs.ucr.edu wrote:
>
> Alexander Terekhov <tere...@web.de> wrote:
> [...]
> : "....
> : Bottom Line:
>
> : 1.CRITICAL_SECTIONS only provide high performance
> : when the process is running in the foreground and
> : the number of active (ready) threads is limited.
>
> : 2.A background process, or a process with numerous
> : active, unserialized, threads can be better off
> : using a mutex.
>
> : 3.You should design your threaded applications carefully,
> : keeping in mind the observations from this relatively
> : simple test program.
>
> : 4.Two or more threads running on separate processors
> : in an SMP system and contending for the same resource
> : will, in some cases, perform very poorly. ...."
>
> I don't understand how MS "critical sections" are supposed to work.
> It sounds like they have a user-space spinlock in addition to a mutex.

Nah, *MS-event* (bin.sema, if you like).

> To acquire the critical section a thread waits on the spinlock util
> some wait-time threshhold is exceeded. Then it incurs the overhead of
> a mutex call and waits passively on an associated mutex. Is that the
> basic idea?

Yep, AFAIK.

regards,
alexander.

Gia Datuashvili

unread,
Apr 30, 2002, 4:13:00 AM4/30/02
to
"Alexander Terekhov" <tere...@web.de> wrote in message
news:3CCADCF0...@web.de...

> BTW, I have a rather interesting link on subject:
>
> http://world.std.com/~jmhart/csmutx.htm
>
> "....
> Bottom Line:
>
> 1.CRITICAL_SECTIONS only provide high performance
> when the process is running in the foreground and
> the number of active (ready) threads is limited.
>
> 2.A background process, or a process with numerous
> active, unserialized, threads can be better off
> using a mutex.
>
> 3.You should design your threaded applications carefully,
> keeping in mind the observations from this relatively
> simple test program.
>
> 4.Two or more threads running on separate processors
> in an SMP system and contending for the same resource
> will, in some cases, perform very poorly. ...."

Have to disagree with bottom line of J.M.Hart. If real win32 code needs to
serialize threads for very brief period of time (for example removing head
element from link list) then setting high spin lock count on critical
section gives much better performance compared to mutexes. This is a result
of some extensive tests on 4 CPU NT servers (where everything was naturally
running in background), among which was the use of synchronization for
custom heap implementation :)

Of course in some extreme (synthetic?) cases critical section performance
will degrade to be less than of mutex (but not much). However this is hardly
a reason to conclude that critical sections arfe useless.

thanks
-gia

t...@cs.ucr.edu

unread,
Apr 30, 2002, 5:58:42 AM4/30/02
to
Gia Datuashvili <gdatua...@hotmail.com> wrote:
[...]
: Have to disagree with bottom line of J.M.Hart. If real win32 code needs to

: serialize threads for very brief period of time (for example removing head
: element from link list) then setting high spin lock count on critical
^^^^^^^^^^^^^^^
: section gives much better performance compared to mutexes.

Is the idea to switch to some form of non-busy waiting after that much
spinning?

The commonly understood tradeoff is that busy waiting has negligible
locking and unlocking overhead but high overhead per time spend
waiting. There are well-known formulas giving waiting times as a
function of arrival rates and the distribution of service times. This
trick puts an puts an adjustable upper-bound on the spin-lock service
times. (Clever stuff!) When loads (arrival rates) get sufficiently
high, it would probably pay to lower the spin-lock count. Right?

Tom Payne


Reply all
Reply to author
Forward
0 new messages