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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
