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