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
> >> Think about needs for counters of various totals to be reported
> >> 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
> >> particular efficiency issue there, just safety.
> >That's simple addition, not a full range of integral operations,
> >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
> such a common need arises? And test it, and document it, and so
> rather have it (and other common usage patterns) as part of a
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
> >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
> But that is more error prone (if the mutex is manipulated manually,
> 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
> 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
> >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
> >> 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
> >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.
> >thread_safe_int_least32_t i = 10;
> >i = (i + 2) / 2;
> >The above expression should be executed "atomically" (as in no
> >thread can change the value of 'i' while the expression is being
> >evaluated) but it is not. The internal mutex is only locked
> >the call to a single operation, so it's possible for another
> >to interrupt and change the value of 'i' in between the '+' and
> >the '/'. It can even interrupt before the assignment! This is
> >atomic_t has very specific functions that can be called such as
> >and dec() and doesn't have overloaded operators such as '++'
> So reduce it to functions which can be safely provided.
> The point is to give programmers a nice palette of mid and hi level
> not just the very low level ones. Jens Maurer's bounded queue was
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk