Re: shared_count

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-13 12:52:49

--- In boost_at_y..., "Yitzhak Sapir" <ysapir_at_y...> wrote:
> I have a situation now that I'd like to use sort of a run_once on
> dynamically created objects.  I can't use run_once because it gets a
> function pointer, not a function<0>.  Maybe this counts for you as a
> "synchronization primitive." 

Actually, there's a request to allow run_once to take a function<0>, 
and I'll likely be making that change soon.  It originally didn't 
because there's an obvious race condition here (the function<0> has 
to be instantiated only once), but as others pointed out there are 
several usages where this race won't exist.

> However, I don't see how you could "safeguard" a person by not 
providing
> these.  If they are out to implement semaphores, which the site says
> were removed for being error-prone, and "atomic long" or "atomic 
bitset"
> would be all they needed, they could just use a bitset/long with a
> mutex.  You can't prevent them from doing really stupid stuff, just 
like
> you can't (at least not easily) prevent people from allocating
> scoped_lock on the heap and doing away with the entire scoped_lock
> framework.  [Maybe if you provide just a copy constructor and a 
factory
> method, you could prevent this].  All you can do is safeguard them 
from
> making more "optimal" or lightweight semaphores, but not from making
> semaphores themselves.  However, for the meantime, maybe this issue
> should be dealt with in the FAQ, which deals with "why isn't there 
also
> event variables/semaphores" questions, for many commonly asked for
> primitives.

You can't prevent all misuses, no.  The particular misuse I was 
concerned with, however, is illustrated by your request below.
 
> However, if a "mutex/long" is good enough for the mutex example, I 
don't
> see how it's "useful only for generating synchronization 
primitives."
> In my suggestion all this would be wrapped by high level objects 
that
> would model "long" or "bitset" and be a lightweight version of the
> equivalent "long"/"bitset", with semantics that allow such common 
uses
> as "update and return resulting value."

At first an atomic_t appears to just be a high level "model 'long'" 
as you put it.  But it's not.  The full range of operations are not 
supported.  Worse yet, those that are supported can't be used to do 
arithmetic computations safely (as in you can't chain two increments 
with out a race condition).  In general there are three uses for 
atomic integer operations:

1) ref-counting
2) atomic list manipulation
3) as a VERY low level mechanism for implementing higher level 
synchronization types

(1) should be handled by a ref-counting concept, not by a generic 
atomic_t type.  (2) is an interesting one, but not often used (it is, 
however, the best argument for inclusion).  (3) generally requires 
platform knowledge any way, so the existence of "portable" atomic 
integer operations only give the illusion of being of any benefit.

Again, though, I must stress that my decision was unpopular and VERY 
likely will be changed in the future.

Bill Kempf 
> > -----Original Message-----
> > From: bill_kempf [mailto:williamkempf_at_h...]
> > Sent: Tuesday, February 12, 2002 9:20 PM
> > To: boost_at_y...
> > Subject: [boost] Re: shared_count
> > 
> > Yes, it was discussed, and *I* determined (against the wishes of 
> > several) that it was too error prone.  I felt that the operations 
> > were only useful for generating synchronization primitives, which 
I'd 
> > hoped to cover with the library, or for ref-counting.  The ref-
> > counting usage would be safer implemented with a simple ref-count 
> > concept then to expose all of the atomic operations where too 
many 
> > novices misuse the operations.
> > 
> > Like I said, though, that decision is unpopular and I'll likely 
have 
> > to re-think the decision at some point.
> > 
> > Bill Kempf
> > 
> > 
> > Info: http://www.boost.org  Send unsubscribe requests to: 
> > <mailto:boost-unsubscribe_at_y...> 
> > 
> > Your use of Yahoo! Groups is subject to 
> > http://docs.yahoo.com/info/terms/ 
> > 
> >