From: "Andrew J Bromage" <ajb@[...].net> 
>  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
mutex.
> 
>  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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost