RE: [boost] Re: shared_count

From: Yitzhak Sapir (ysapir_at_[hidden])
Date: 2002-02-13 11:13:26

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

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.

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

> -----Original Message-----
> From: bill_kempf [mailto:williamkempf_at_[hidden]]
> Sent: Tuesday, February 12, 2002 9:20 PM
> To: boost_at_[hidden]
> 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_[hidden]> 
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
>