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-10 18:21:36

________________________________________
De: boost-bounces_at_[hidden] [boost-bounces_at_[hidden]] En nombre de Peter Dimov [pdimov_at_[hidden]]
Enviado el: viernes, 10 de abril de 2009 19:21
Para: boost_at_[hidden]
Asunto: Re: [boost] atomic_count::operator++ return type

JOAQUIN M. LOPEZ MUÑOZ:
> > Hi,
> >
> > Some of the implementations of boost::detail::atomic_count::operator++
> > return a long (vg. Win32) while for others the return type is void.
> > Is it feasible to change this so that a long (i.e. the value of the atomic
> > count after incrementing) is returned always?
> > As it happens, I have a usage case for this in Boost.Flyweight.
> 
> What memory visibility guarantees does your use case need? op++ returns no
> value because it currently promises no visibility guarantees.

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. There code's rationale is commented, but
don't hesitate to ask if something's not clear. Of course I wouldn't
need the extension to op++ if there's an alternative manner to
implement the protocol
.
Thank you,

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