You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We sometimes need to directly use the protect_raw function in HazardPointer, especially to implement some data structures where protection is validated in a different way. Michael-Scott queue or DoubleLink Queue are good examples. To implement those with plain hazard pointers, after protecting the next node of the head node, its validation must be done by checking the entry pointer to the head node again. This is because the next pointer on the head node won't be changed even after the nodes are dequeued and retired.
However, as the internal light barrier implementation is not public, we cannot synchronize the reading thread with the reclaiming thread. Of course, using fence(Ordering::SeqCst) might be enough, because the current implementation of the light barrier is just a sequential normal barrier. Nonetheless, It would be good to allow users to call the light barrier functionality and explain its usage in a document.
In conclusion, I think that someone(or me) should do the following jobs:
Make asymmetric_light_barrier public and explain its usage.
In the document of protect_raw, suggest an example using with asymmetric_light_barrier.
The text was updated successfully, but these errors were encountered:
We sometimes need to directly use the
protect_raw
function inHazardPointer
, especially to implement some data structures where protection is validated in a different way. Michael-Scott queue or DoubleLink Queue are good examples. To implement those with plain hazard pointers, after protecting the next node of the head node, its validation must be done by checking the entry pointer to the head node again. This is because the next pointer on the head node won't be changed even after the nodes are dequeued and retired.However, as the internal light barrier implementation is not public, we cannot synchronize the reading thread with the reclaiming thread. Of course, using
fence(Ordering::SeqCst)
might be enough, because the current implementation of the light barrier is just a sequential normal barrier. Nonetheless, It would be good to allow users to call the light barrier functionality and explain its usage in a document.In conclusion, I think that someone(or me) should do the following jobs:
asymmetric_light_barrier
public and explain its usage.protect_raw
, suggest an example using withasymmetric_light_barrier
.The text was updated successfully, but these errors were encountered: