Boost logo

Boost :

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.


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:
       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,
       enter release_weak(),
       atomic_decrement(&weak_count) == 1,
       (strong_count < 0, weak_count == 1)
       enter release_weak(),
       atomic_decrement(&weak_count) == 0,
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:
(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_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 ;-) )



Boost list run by bdawes at, gregod at, cpdaniel at, john at