(no subject)

From: williamkempf_at_[hidden]
Date: 2001-09-10 22:07:04

--- In boost_at_y..., k.hagan_at_t... wrote:
> Bill Kempf wrote...
> 
> > This [http://world.std.com/~jmhart/csmutx.htm] was the article
> > that someone pointed me to.  The conclusion was that CS are only
> > faster if:
> >
> > * There are less than 8 threads total in the process.
> > * You weren't running in the background.
> > * You weren't on an dual processor machine.
> 
> That's not how I read it. The test program used in this paper
> does nothing else but bang on 1 or 2 critical sections. That
> surely isn't realistic. Most programs don't have 8 threads that
> have nothing better to do in life than torture a single CS.

The article claims, however, that the threads need not wait on the CS 
to cause the performance problems.  I'm skeptical too, but they do 
make this claim.

> Entering a CS is one or two instructions unless the section is
> already held, in which case it is a wait on a mutex. Waiting on
> a mutex involves a kernel switch. OK, so someone has written a
> benchmark that shows the mutex winning. Am I the only person who
> thinks the benchmark might be suspect?

It's a tad more complicated then "one or two instructions", but not 
by much (it's actually a loop with a relatively expensive atomic 
compare and swap).  You aren't the only one that's skeptical, however.

Bill Kempf