From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-05-22 19:41:38
At 05:52 PM 5/22/2001, williamkempf_at_[hidden] wrote:
>--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
>> The whole thing with atomic_t might be a red herring. It may well
>> thread_safe_int_least32_t needs a full set of integer operations.
>> if sizeof(int)==32, it can't just be a typedef for atomic_t.
>I just realized what you're saying here. I don't think there's any
>way to natively give a full set of integer operations to a type with
>out using a mutex.
That's what I mean about atomic_t being a red herring. Forget about
it. There is nothing wrong with a mutex.
Think about needs for counters of various totals to be reported by several
worker threads. Each thread would keep its own local totals (so they could
be updated efficiently without locking), but then just before closing down
would update the shared thread_safe_int_least32_t program totals. No
particular efficiency issue there, just safety.
Now of course there could be an application mutex, but why bother? It just
opens up the possibility of misuse. A thread_safe_int_least32_t would wrap
the functionality up in a nice safe package that would be very hard to
misuse. That's what C++ classes are all about.
I wouldn't overgeneralize the idea. 32-bits, maybe later a least 64-bit
flavor, but that is it. Or maybe thread_safe_long. That would be OK, but
I like the explicitness of a visible 32-bit guarantee.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk