Re: [boost] atomic_count::operator++ return type

Subject: Re: [boost] atomic_count::operator++ return type
From: JOAQUIN M. LOPEZ MUÑOZ (joaquin_at_[hidden])
Date: 2009-04-11 17:55:50

________________________________________
De: boost-bounces_at_[hidden] [boost-bounces_at_[hidden]] En nombre de Peter Dimov [pdimov_at_[hidden]]
Enviado el: sábado, 11 de abril de 2009 2:15
Para: boost_at_[hidden]
Asunto: Re: [boost] atomic_count::operator++ return type
> 
> JOAQUIN M. LOPEZ MUÑOZ:
> > I'm afraid I don't quite get what you mean exactly by memory visibility in
> > this context: I guess I need the same behavior (mutatis mutandis) as given
> > by op--. In case it sheds some light, the usage case I talk about can be
> > taken a a look at
> >
> > https://svn.boost.org/trac/boost/browser/trunk/boost/flyweight/refcounted.hpp
> >
> > The protocol is a classical refcounting mechanism with a twist due to the
> > possiblity that values are retrieved even if their recount drops to zero.
> 
> I'm not sure how this works... what is TrackingEntry? 

It is a façade to the functionality provided by the rest of
Boost.Flyweight for the use of the refcounting mechanism:

http://www.boost.org/libs/flyweight/doc/reference/tracking.html#tracking

* TrackingHelper::entry(h) returns the value to
which the refcounted_handle h refers (which is implicitly
convertible to a refcounted_value). Think of it as a dereference
operator.
* TrackingHelper::erase(h,check_erase) deletes the value
refered to by h iff check_erase(h) returns true. The execution
of this routine happens in a locked context (including the
call to check_erase and erasure itself).
* Though it may not be apparent, the execution of
explicit refcounted_handle(const Handle&) also happens
in a locked context (this is important to the implementation
of the refcounting protocol).

> How do you handle the possibility of
> 
> - thread A detaches the last reference, calls erase, erase calls
> check_erase, gets true, and is preempted;

This cannot happen as check_erase is invoked in
a locked context. The critical point where preemption can
occur is between detaching of the last reference and
execution of erase, which is precisely what the del_ref
member variable keeps tracks of; if A resumes after
preemption and the value has acquired a new reference
the count of deleters will be >0 and check_delete
will return false.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo