Re: New file uploaded to boost

From: williamkempf_at_[hidden]
Date: 2001-05-23 13:32:19

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 09:38 AM 5/23/2001, williamkempf_at_h... wrote:
> 
>  >> it.  There is nothing wrong with a mutex.
>  >
>  >No, but there is something wrong with a mutex being used at this
>  >granularity.
>  >
>  >> 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.
>  >
>  >That's simple addition, not a full range of integral operations, 
so
>  >it's not much of an example of the need for a full
>  >thread_safe_int_least32_t.  This particular example would best be
>  >served by "traditional" synchronization, i.e. you'd roll the
>  >synchronization yourself.  Why?  Well, it's just to simple of an
>  >example to be worth addressing in a library.
> 
> It may be simple, but who wants to write even a simple class every 
time 
> such a common need arises?  And test it, and document it, and so 
on.  I'd 
> rather have it (and other common usage patterns) as part of a 
library.

As has been pointed out before, some patterns are best left as 
patterns and not codified into classes.  The monitor pattern is a 
good example of this.  Singletons are another good example.  This one 
is just one more example.

>  >  For instance, it's
>  >quite possible that there will be multiple such totals that need 
to
>  >be updated and it would be better to use a single mutex for all of
>  >them then to use a mutex per total as would be done by a library
>  >solution.
> 
> But that is more error prone (if the mutex is manipulated manually, 
rather 
> than wrapped in a class),

I never suggested manipulating the mutex manually.  I'd expect the 
totals to be wrapped up into an appropriately designed class which 
handles the synchronization in the most efficient manner possible.

> is slower (if there are multiple threads 
> contending for otherwise unrelated counters),

This is where you need to look at the bigger picture.  As I said, if 
multiple counters are going to be modified using a single mutex is 
going to be faster than using a mutex per counter.  What's needed all 
depends on the usage requirements of a given application.  A library 
can't even begin to guess what level of granularity is best, and so 
it shouldn't try to.

> and in general making an 
> assumption about what a programmer wants to optimize.

Actually, it makes no assumptions.  A thread_safe_int_least32_t on 
the other hand makes several assumptions on what to optimize, which 
is precisely what I was pointing out here.

>  Maybe the programmer 
> wants to favor programming effort, safety, and speed rather than 
mutex 
> memory space.

A thread_safe_int_least32_t addresses effort, but it does not address 
safety or speed.  And I never even considered mutex memory space.
 
>  >> 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.
>  >
>  >The reason to bother is to attain the optimal granularity of lock
>  >(and an "application mutex" might not fit that bill either).  A
>  >threading library can't predict what level of granularity is 
optimal
>  >since it's going to depend on the application, so such a type just
>  >isn't appropriate.
>  >
>  >Beyond that, there's a severe problem with a
>  >thread_safe_int_least32_t that behaves as an int.  The level of
>  >granularity of such a lock can actually lead to errors in usage.  
For
>  >example:
>  >
>  >thread_safe_int_least32_t i = 10;
>  >i = (i + 2) / 2;
>  >
>  >The above expression should be executed "atomically" (as in no 
other
>  >thread can change the value of 'i' while the expression is being
>  >evaluated) but it is not.  The internal mutex is only locked 
during
>  >the call to a single operation, so it's possible for another 
thread
>  >to interrupt and change the value of 'i' in between the '+' and
>  >the '/'.  It can even interrupt before the assignment!  This is 
why
>  >atomic_t has very specific functions that can be called such as 
inc()
>  >and dec() and doesn't have overloaded operators such as '++' 
and '--'.
> 
> So reduce it to functions which can be safely provided.
> 
> The point is to give programmers a nice palette of mid and hi level 
tools, 
> not just the very low level ones.  Jens Maurer's  bounded queue was 
a good 
> example.

The bounded queue can't compare to a thread_safe_int_least32_t in 
this case, IMHO.  The queue is a tight design that can be easily 
reused efficiently and safely for a large number of applications, 
while the thread_safe_int_least32_t makes so many assumptions as to 
make it's applicability very small with very little added benefit.

Bill Kempf