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
> these. If they are out to implement semaphores, which the site says
> were removed for being error-prone, and "atomic long" or "atomic
> 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
> 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
> method, you could prevent this]. All you can do is safeguard them
> 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
> event variables/semaphores" questions, for many commonly asked for
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
> see how it's "useful only for generating synchronization
> In my suggestion all this would be wrapped by high level objects
> would model "long" or "bitset" and be a lightweight version of the
> equivalent "long"/"bitset", with semantics that allow such common
> 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:
2) atomic list manipulation
3) as a VERY low level mechanism for implementing higher level
(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.
> > -----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
> > 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
> > novices misuse the operations.
> > Like I said, though, that decision is unpopular and I'll likely
> > 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/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk