Boost logo

Boost :

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-20 12:50:29

>> >Interlocked* is much more efficient, is it not?
>>More efficient, yes. Much more... maybe, maybe not.

>Herb Sutter has some measurements at that
>seem to indicate that the win32 atomic primitives beat a critical section
>orders of magnitude in some cases.

Emphasis on "some". Also note that the difference between the atomic
operations and critical sections were not "orders of magnitude", and the
simple boost::mutex type may be implemented via critical sections at some
point and may show the same characteristics on other platforms.

>>Regardless, there's
>>valid reasons to not include atomic integer operations in the initial
>>submission, and that's simply the way it's going to be.
>The question I asked was "what are the reasons for not including
> >atomic_t?",
>not "do reasons exist?" or "will this be the way it's going to be?"

There are several reasons. First, it's very difficult to implement this
portably in C++. On nearly all platforms (Win32 is the one exception I'm
aware of) you have to step out of C and into Assembly to accomplish this.
Even inline Assembly won't help with this pain, since each compiler does
inline Assembly in its own unique way. And even on Win32 you have some
issues when we migrate to Win64 (for instance, the signature for
InterlockedCompareExchange() has recently been modified). Second is the
issue of memory synchronization. An atomic integer concept should not
automatically synchronize memory, as per memory barriers, since this
operation is expensive and won't always be needed/wanted. You can expect
that MS won't make the Interlocked*() operations do memory synchronization
for this very reason. This makes interlocked operations more difficult to
use portably. At the very least we'd need to include a memory barrier
concept, and even then you can expect a lot of users to do this wrong.

So, what you really want is not an atomic_t type, but a ref_count type.
Initially this type will probably have an optimized implementation only for
Win32. I don't know for sure, but you may even find that there's little
optimization available for MPU architectures that need memory synchs, since
this operation may be nearly as expensive as a mutex lock any way.

In the end, the main reason for exclusion is that it's simply an
optimization (no matter how big of one) and so doesn't fit the criteria for
"minimal yet complete". For instance, note that POSIX doesn't define a
pthread_atomic_t type and operations, but POSIX folks get along nicely with
out it.

>Why force users to roll their own atomic_t? They will.

I'd expect they'd roll their own ref_count instead. If someone does roll
one that's portable before we get around to it they can always submit it to
Boost.Threads for inclusion.

Bill Kempf

Get your FREE download of MSN Explorer at

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