No, it would be lock-free, and not wait-free (since it's a compare and exchange loop that can fail, therefore getting rid of any guarantee of per-thread progress). However, there are different levels of abstraction that you could classify something as (i.e., a SW algorithm is wait-free, but the platform-specific implementation is lock-free)
It’s not a bug, I think. 1st argument of cmpexhange is an lvalue reference, so in case of failure it will contain current sink value (this implicit pass-by-reference is the worst design choice ever, tbh)
![[LIVE] : ONE ลุมพินี 88 | คู่เอก "ป้อมเพชร vs อัสลามจอน"](http://i.ytimg.com/vi/1ZqTVVbMgbo/mqdefault.jpg)
Really useful video, thank you Nick!
Thanks! Glad you enjoyed it! :^)
Love this series!
Glad to hear it! :^)
Is wait-free example actually wait-free on arches with ll/sc atomics (like arm)?
No, it would be lock-free, and not wait-free (since it's a compare and exchange loop that can fail, therefore getting rid of any guarantee of per-thread progress).
However, there are different levels of abstraction that you could classify something as (i.e., a SW algorithm is wait-free, but the platform-specific implementation is lock-free)
Shouldn’t you need to do expected = sink.load() in the do while loop of the first program for it to work?
I agree. I think it's a bug. I went into the comments to see if anybody would have spotted it.
It’s not a bug, I think. 1st argument of cmpexhange is an lvalue reference, so in case of failure it will contain current sink value
(this implicit pass-by-reference is the worst design choice ever, tbh)