...@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
|> 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
Ok. If you had a powerpc you could safely increment the reference thread using
loop1: lwz rx, ptr # load global shared pointer value
Any writer thread deleting or changing the shared global pointer would
For those not familiar with load reserved and store conditional, load reserved
The recheck of the global shared pointer guarantees that your reserve occurred
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.