Open trivigy opened 1 month ago
Thanks for the feedback! Let me have look. I'll come back to this as soon as possible.
Maybe there is a misunderstanding, which might be caused by a refactorization of the algorithms to better fit into the paper:
I hope, this makes things clearer.
Best, JPS
I followed that same logic for the store function and in full agreement. Algorithm 3 in the paper is correct. Algorithm 4 is the one where I believe the mistake is.
I assumed the exchange method (line 1230) works almost exactly the same as store (1215), with the one exception that it does not drop the temporary shared_ptr. Compared to the way the store method does (line 1215 after returning from the R-value version).
Therefore, I thought, in the paper algorithm 4 line 4 should say old_cptr = a.cptr.exchange({ 0, s.cptr.pctrl })
but it instead says old_cptr = a.cptr.exchange({ 1, s.cptr.pctrl })
. Looking at the code at 1235, when return shared_ptr<T>{ cptr_hdr_.exchange( hdr_ptr_type{ desired_ptr }, order ) };
is called, a new hdr_ptr_type{ desired_ptr }
is created. Is that not equivalent to { 0, s.cptr.pctrl }
? Which seems to disagree with algo4/line4 and agree with my assumption of the error.
I hope I make sense and that my thinking is sound. Apologies if I am missing a critical detail in my understanding.
My bad. You talked about algorithm 4 in the paper ^^ I'll have a look again asap.
It seems that you are right. Thank you very much!
Indeed, even the proof claims that the exchange
function works mostly the same as the store
function.
Let me have a look with a sharpened mind after my vacation again. Then I'll also fix the paper. I'll come back to you ;)
@frygge In algorithm 3 line 4 the pointer exchange is done with local temp count being set to 0. However, in algorithm 4 line 4 the exchange is done with local temp count is being set to 1. Looking through the code LINK it seems that the number in the paper should be 0?!