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-12 16:02:34

________________________________________
De: boost-bounces_at_[hidden] [boost-bounces_at_[hidden]] En nombre de Peter Dimov [pdimov_at_[hidden]]
Enviado el: domingo, 12 de abril de 2009 15:24
Para: boost_at_[hidden]
Asunto: Re: [boost] atomic_count::operator++ return type

JOAQUIN M. LOPEZ MUÑOZ:
> > This does not work because of scenarios like the following:
> >
> > 1. Thread A detaches the last reference to x and is preempted
> > when it's about to enter erase.
> > 2. Thread B retrieves x so that its refcount is now 1. After
> > some work with x, thread B detaches the reference to x,
> > whose refcount drops again to zero, enters erase and
> > eliminates x.
> > 3. Thread A resumes, but erase now attempts to work with
> > a nonexistent x.
> 
> Here by x you mean the refcounted_value, I guess. Yes, this doesn't work if
> 'Handle' is a raw pointer, for example. I think, however, that it does work
> if erase doesn't need to dereference the handle in order to see that it's
> already been removed.

I don't see a way that erase can know that in a reasonably efficient
way --Handle is usually an iterator, you know.

But maybe we're diverting off a bit. Given the current constraints,
I've got a protocol that could be implemented with an extension
to the interface of atomic_count::op++. Is this a reasonable thing
to ask, or are there unavoidable obstacles to have it?

Rereading the internal documentation of atomic_count, I see that
op-- returns 0 if the new value is zero and something else otherwise.
In the same fashion, it'll probably suffice with an op++ that returns
0 if *the value before incrementing* was zero, and something else
otherwise, so it'd behave like a post increment, not exactly what
we have now.

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