Subj : Re: Hazard pointer w/ extra memory barrier
To   : comp.programming.threads
From : Chris Thomasson
Date : Tue May 10 2005 02:56 pm

>I think if you store into a hazard pointer that is not null
> then you need release semantics on that store to prevent any
> prior accesses from occurring after that store.

I think you are correct... You probably would need to make sure that all 
prior load's occur and store's be made visible before the:

hptr( null ) => hptr( x )

transition takes place. Yikes!

Doesn't really matter for me now because I have found a way to eliminate all 
of the memory barriers in RCU and/or SMR read-side critical regions for 
user-space applications. The generic algorithm doesn't need to count/poll 
any CPU/Thread specific OS provided information for quiescent states. It 
just relies on the user application to voluntarily follow a certain set of 
rules, and rely on some particular guarantees. Luckily, the rules are fairly 
straightforward and not that stringent; they seem to work very work well 
with many common server application architectures. Also, the algorithm puts 
a per-thread upper-bound on the number of pending objects awaiting deferred 
destruction, much like the "original" SMR algorithm; you simply can't run 
out of memory. Humm, I am not sure if I should post the algorithm. I know 
you can publish something and patent/claim it later as your own prior art, I 
am just not sure how secure that would be.




> Ditto if you're just storing NULL into a non-NULL hazard pointer.
>
>         membar  load/store, store/store
>         store hazard
>
> So that's an extra memory barrier to get rid off.  More fun.

:)

.