Boost logo

Boost :

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

--- In boost_at_y..., k.hagan_at_t... wrote:
> Bill Kempf wrote...
> > This [] 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at