|> In article <1998Jun23.081...@bose.com>, Joe Seigh <se...@bose.com> wrote:
|> >Using abstract pointers still has the same problem.  It just adds an
|> >extra step of indirection.  Once the actual pointer is fetched you still
|> >have the possible race condition.  Unless of course you put the reference
|> >count in the abstract pointer itself and that abstract pointer is never
|> >deallocated.
|>
|> The abstract pointer is never deallocated (really, we shouldn't be talking
|> about deallocation of pointers, but deallocation of objects which are
|> pointed at).
|>
|> Conventional pointers retain their value after what they point to is
|> freed; however, that value becomes meaningless. In the C language,
|> *any* use of a pointer value that previously referred to storage
|> that has been freed leads to undefined behavior.
|>
|> In contrast, the ``abstract pointer'' (better referred to as a name) retains
|> its meaning even after the object it refers to has disappeared. Using that
|> name as an argument to a search operation does not create a hazard; the
|> operation safely reports that the object which used to have that name is gone.
|>
|> One potential problem that arises is related to the reuse of names.
|>
|> But enough about that, I would like to hear about other interesting
|> ideas!

Ok.  If you had a powerpc you could safely increment the reference thread using
something like the following.

        loop1:  lwz     rx, ptr         # load global shared pointer value
                                        # test for null not shown here
        loop2:  lwarx   ry, 0, rx       # load reserved on reference count
                sync                    # memory barrier
                addi    ry, 1           # increment reference count
                cmp     rx, ptr         # check if shared global pointer has changed
                bne-    loop1           # if changed, retry
                stwcx.  ry, 0, rx       # store conditional of reference count
                bne-    loop2           # retry if reference count update failed

Any writer thread deleting or changing the shared global pointer would
first change the pointer and then decrement the reference count.

For those not familiar with load reserved and store conditional, load reserved
puts a "reserve" for the current processor on the storage location the load
occurred from.  Store conditional fails if the "reserve" was lost, i.e. among
other things, if some other processor stored into that storage location in the
interval since the "reserve" was set.

The recheck of the global shared pointer guarantees that your reserve occurred
before the global shared pointer was changed and thus before the decrement of
the reference count.  If the object was deallocated the increment of the
reference would either fail on the global pointer recheck or on the store
conditional.

--
Joe Seigh