825
Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Joe Seigh
Date : Sat Apr 16 2005 02:19 pm

On Sat, 16 Apr 2005 18:54:48 +0300, Peter Dimov <pdimov@gmail.com> wrote:

>
> But if I place a limit of at most one writer... would I be able to get away
> with something like:

Single writer on the target shared ptr and multiple concurrent readers
on the source shared ptr, the one that you're copying.

>
> l1:
>
> load pointer to object
> load pointer to count
> set hazard pointer
>
> fence
>
> compare pointer to object
> compare pointer to count
> compare hazard pointer
>
> if mismatch goto l1
>
> ?
(...)

You're need to atomically load the object and count ptrs at the same time
so you know their associated with each other.  This is a problem if you're
trying to avoid atomic double word loads because not all platforms have it.
Put an extra ptr to object in refcount object.  So you get

l1:
load pointer to count             // atomic
if null return (null, null)       // this works because "null object" is never deallocated
                                   // no need to increment refcount for it.
set hazard pointer                // atomic
fence
compare hazard ptr to count ptr
if mismatch goto l1

atomically increment refcount if not zero
if zero goto l1

unset hazard ptr
return (pcount, pcount->pobject)  // to be stored in target shared pointer


The setting of the pcount and pobject fields in the target shared pointer
each need to be atomic respectively.  You'll want acquire and release
semantics since even though you have single writer, you still have
multiple concurrent readers.


For read access

l1:
load pointer to object            // atomic
set hazard pointer                // atomic
fence
compare hazard ptr to object ptr
if mismatch goto l1

.... read access to object ...


unset hazard ptr



I left out the details on the hazard ptr logic since there's multiple
ways of doing that and it's not really important here.



-- 
Joe Seigh

.

0