Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-08 06:31:34

From: "Andrew J Bromage" <ajb_at_[hidden]>
> On Wed, Aug 07, 2002 at 01:44:02PM +0300, Peter Dimov wrote:
> > Your "once" object is dynamically initialized. It is pretty much the
same as
> > a boost::mutex; there is no reason for it to be more efficient than a
> The same argument could be made against lightweight mutexes,

True. Pretty much the only reason for their existence is that they are
header-only. Lightweight mutexes were supposed to be more efficient than a
simple mutex, but as it turns out, this is rarely possible. They are simply
not worth the effort; it is deceptively easy to come up with a "solution"
that passes all tests on your machine and fails mysteriously once in a week
on another box.

The only platform where lightweight_mutex consistently "wins" is Win32/x86,
and this makes me pretty nervous, since it probably means there's a bug
somewhere. :-)

> or atomic counters.

Atomic counters have a definite size advantage over a mutex.

> On all platforms that I'm aware of, releasing a mutex lock costs at
> least one system call. On many platforms, even obtaining an
> uncontested lock costs a system call. This is a heavyweight
> solution for a lightweight problem: protecting a read of a single flag
> which is only going to be mutated once in its lifetime. I can see
> this causing problems in times of heavy concurrency.

The system call is important - if it prevents inlining. Most of the
remaining overhead is caused by the memory synchronization, and there is no
way to avoid it. Even an atomic_counter must synchronize memory in order to
be useful.

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