Several fixes to the "SWMRList" example in experimental/hazptr.
Summary: Fix a correctness bug in "SWMRList.h". Thanks to Maged for the tip! The old code omitted setting a removed node's "next" pointer to `nullptr`, which meant that if the writer removed node A and then node B = A->next while the reader was looking at B, then the reader might happily keep chasing pointers B->next, B->next->next,... without ever noticing that it was now on a "dead branch" of the linked list. (And then there's a bit of a trick: you really do have to remove the node first and *then* set its "next" pointer to null, because if you do the null assignment first, you'll truncate the list, which means that some readers will see a truncated list and return the wrong answer. I've added comments to try to explain this to future-me.) Style nit: Avoid doing multiple atomic operations on the same line of code. ---- Modernize the parameter-passing conventions in SWMRList.h. Pass `T`s by const reference, except in `add` where we're likely to want to make a copy of the `T` anyway. In that case it would be more "STL-correct" to supply two different overloads `add(T&&)` and `add(const T&)`, but this is just an example so it makes sense to keep things simple. ---- Fix an undefined behavior in SWMRList example. Searching an empty SWMRList<int> always invokes undefined behavior by comparing an uninitialized `T elem` against `val` on the final line of the `contains` function. Besides, this patch allows SWMRList to work with `T`s that aren't default-constructible or even copy-constructible. ---- Closes https://github.com/facebook/folly/pull/566 Reviewed By: djwatson Differential Revision: D4772359 Pulled By: yfeldblum fbshipit-source-id: 8f96573530800675cb56006aa91e7a5c5c1fb85d
Showing
Please register or sign in to comment