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

From: Pavel Vasiliev (pavel_at_[hidden])
Date: 2003-02-12 11:10:51

Alexander Terekhov wrote:

> Peter Dimov wrote:
> [...]
>> You are missing the fact that nobody (even Google) has a clue as to what
>> pthread_refcount_enroll_one is/does. ;-)

> Ah. Sorry. Basically it's a rather simple "CAS"- ["compare-and-swap"] 
> or "LL/SC"- [load-locked/store-conditional] based operation; in terms 
> of proposed Java-atomics(*): <behaviorally, error checking aside>

> extern "C" int pthread_refcount_enroll_one(pthread_refcount_t* rc) {
>   size_t value;
>   do {
>     if ( 0 == (value = rc->__get()) )
>       return PTHREAD_REFCOUNT_DROPPED_TO_ZERO;
>   } while (!rc->__attemptUpdate(value, value + 1));
>   return 0;
> }

> regards,
> alexander.

> (*) [but WITHOUT any memory synchronization/barriers for _enroll_*()]
>     http://groups.google.com/groups?threadm=3D8B257C.4D8D58F%40web.de
>     (Subject: Re: rwlock using pthread_cond (or Win32 events) [last
>     link retired; stuff is available here: <http://tinyurl.com/5mmj>])

pthread_refcount_enroll_one() (== "increment_if_non_zero()") may be
emulated in Win32 (using InterlockedCompareExchange()).

The problem is what to do on e.g. current Unix'es + GCC.
Alternatives are either wait for pthread_refcount_t in many pthreads
implementations or to explicitly use inline assembler(s).

Other alternatives?

The problem is so obvious that the question may be thought rhetorical.
But I really ask whether you have some suggestions.

Pavel