Re: Boost.Threads - Questions

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 http://www.gotw.ca/gotw/045.htm that
>seem to indicate that the win32 atomic primitives beat a critical section 
>by
>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 http://explorer.msn.com/intl.asp