Boost logo

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
> >hold at
> >> least 32 bits.
> >
> >If we were to limit it I'd think it would be better to say at
> >sizeof(int) bits. I'm sure there are some architectures that
> >allow for efficient 16 bit atomic operations since an int is 16
> >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
> >changing the documentation (i.e. the current implementation fits
> >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

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