Re: [boost] Re: New file uploaded to boost

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
 >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.
 >
 >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.

--Beman