Re: New file uploaded to boost

From: williamkempf_at_[hidden]
Date: 2001-05-22 16:42:01

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 04:09 PM 5/22/2001, williamkempf_at_h... wrote:
> 
>  >> The one need that keeps coming up is thread-safe counter known 
to
>  >hold at
>  >> least 32 bits.
>  >
>  >If we were to limit it I'd think it would be better to say at 
least
>  >sizeof(int) bits.  I'm sure there are some architectures that 
would
>  >allow for efficient 16 bit atomic operations since an int is 16 
bit
>  >there, while 32 bit atomic types would have to rely on the much
>  >slower mutex.  At this point atomic_t could fit this bill simply 
by
>  >changing the documentation (i.e. the current implementation fits 
the
>  >bill any way).
> 
> I've run into the need for about a dozen counters now, and every 
one of 
> them had to be at least 32 bits.  Slow, fast, it didn't matter, 
they had to 
> be at least 32 bits even on platforms where int is 16 bits.
> 
> The whole thing with atomic_t might be a red herring.  It may well 
be that 
> thread_safe_int_least32_t needs a full set of integer operations.  
So even 
> if sizeof(int)==32, it can't just be a typedef for atomic_t.

So maybe we need a full range of thread_safe* int types (as from 
stdint.h)?  This would be possible but will be an even bigger pain to 
implement than what we currently have with atomic_t.  I'm also not 
sure that it would be generally useful to go to this extent.  What 
motivates the need for your counters to be 32 bits or greater?  Is 
there a real need for the speed of atomic operations as well, or 
would a mutex suit the problem domain?  If there were a MAX_ATOMIC_T 
macro could you use it to do conditional compilation?

I guess what I'm wondering is if you're falling onto a corner case 
(even if a somewhat common one) better suited to user code than a 
case in which the library should give a solution.  Especially 
considering the possibility of the library being the basis for a 
standards submission.

Just brain storming... I guess another possibility would be to define 
atomic_t as a template taking an integral parameter type with 
specializations for types that can be natively implemented.  This 
might actually make the implementation a bit simpler, but again I 
wonder about the actual usefullness of this as a core part of a 
threading library.

Anyone with any thoughts/opinions on this?

Bill Kempf