[boost] Re: Weak ref. via atomicity (RE: Smart pointers:...)

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-02-12 11:25:52

Pavel Vasiliev wrote:
[...]
> Interestingly. pthread_refcount_enroll_one() in your implementation
> really eliminates need in any explicit locking.

I hope so. Yeah, as you wrote <quote> ...problem is much the same: 
"test and conditionally increment" </quote>.

> 
> Your code showed also that I overlooked the more simple way to deal
> with weak_count. To satisfy aesthetic feelings 
                              ^^^^^^^^^^^^^^^^^^

;-)

> I place here the corrected version of my previous code.

Well, 

Given: two threads -- A and B, 
       thread A has "strong" one,
       thread B has "weak" one,
       strong_count == 1, weak_count == 2.

Thread A, in release_strong:
       atomic_decrement(&strong_count) == 0,
Thread B, in acquire_strong_from_weak:
       lock,
       see atomic_increment(&strong_count) > 0,
       (strong_count == 1, weak_count == 2)
       return true (and unlock),
       ...
       enter release_strong()
       atomic_decrement(&strong_count) == 0,
       enter strong_refs_lost(),
       see strong_count == 0,
       set strong_count < 0,
       unlock,
       destroy,
       enter release_weak(),
       atomic_decrement(&weak_count) == 1,
       (strong_count < 0, weak_count == 1)
       ...
       enter release_weak(),
       atomic_decrement(&weak_count) == 0,
       destruct_self()
Thread A, enter strong_refs_lost():

WHA.. Nah, Lukashenko retires and establishes peace and democracy in 
the Middle East. ``Not bad.'' ;-)

Well, presuming that I'm NOT missing and/or misunderstanding something
with respect to the "flow" above, a sort of "moral" is that you should
better NOT increment a ZERO count... unless you *really* wish to have
something along the lines of:

http://groups.google.com/groups?selm=3D021EA4.E2217C09%40web.de
(Subject: Re: Objects in container: creation and deletion details)

with Zombies, resurrection [God rules], etceteras.

And, BTW, < Forward Inline >

-------- Original Message --------
Newsgroups: comp.programming.threads
Subject: Re: threadsafe reference counting

Alexander Terekhov wrote:
> 
> < kinda pthread_refcount_t-"SKETCHv3" > ....

Here's the "updated" SKETCH:

PTHREAD_REFCOUNT_MAX                 // upper bound
PTHREAD_REFCOUNT_INITIALIZER(N)      // macro for statics INIT
pthread_refcount_init()              // mutex like but with initial value
pthread_refcount_destroy()           // also mutex like
pthread_refcount_getvalue()          // see "COW_AtomicInt3" string example
pthread_refcount_setvalue()          // see "COW_AtomicInt3" string example
pthread_refcount_increment()         // without any msync whatsoever
pthread_refcount_add()               // without any msync but with r.checking
pthread_refcount_decrement()         // with msync for proper mut.obj-cleanup
pthread_refcount_subtract()          // with msync and with r.checking
pthread_refcount_decrement_nomsync() // without any msync whatsoever
pthread_refcount_subtract_nomsync()  // without any msync but with r.checking
pthread_refcount_enroll_one()        // without any msync whatsoever
pthread_refcount_enroll_many()       // without any msync but with r.checking
pthread_refcount_attr_*()            // PROCESS_SHARED and etc. attr-stuff
std::size_t as "value type"          // for get/set/add/... "value" param
PTHREAD_REFCOUNT_DROPPED_TO_ZERO     // for pthread_refcount_decrement*() 
                                     // and pthread_refcount_sub() to 
                                     // indicate "dropped to zero" condition
                                     // that MAY be used to safely destroy
                                     // associated ref.counted object or 
                                     // simply continue -- increment/setval
                                     // also used for weak->strong "enrolls"
                                     // by pthread_refcount_enroll_one() and
                                     // pthread_refcount_enroll_many()

Uhmm, as WW-aka-Attila says... Kapis?

Comments/suggestions/objections/whatever? (an essay from David Butenhof 
would be greatly appreciated as well ;-) )

regards,
alexander.

--
http://www.usenix.org/publications/library/proceedings/c++94/full_papers/ellis.a