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