________________________________________ De: boost-bounces@lists.boost.org [boost-bounces@lists.boost.org] En nombre de Peter Dimov [pdimov@pdimov.com] Enviado el: domingo, 12 de abril de 2009 15:24 Para: boost@lists.boost.org 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