ConcurrentHashMap: Fix cloning of non-copyable items
Summary: Fix an algorithm bug that occurs when the Key or Value types are not nothrow copy constructible. - Nodes (the entities protectable by iterators) may be cloned as a result of rehashing. - Key-value item objects are unique (because they are not copyable). - Multiple nodes may point to the same key-value item. - In the incorrect algorithm, each node has a bool member that indicates if it owns the key-value item or not (i.e., if it is responsible for deleting it). - When a node is cloned, its bool member is cleared. - The problem is that if the key is erased and the clone (or descendant clone) may be reclaimed (because it is unprotected by iterators) then the key value item will be reclaimed, even if a cloned-from node is still protected by iterators. - The failure happens when an iterator holder to a cloned-from node tries to access the already-reclaimed key-value, expecting it (correctly) to be still protected. The fix: - Eliminate the bool owned member in the node structure. - Add a link counter to the key-value item structure. - Increment (atomically) the link counter when the (latest) node to the key-value item is cloned. - Decrement (atomically) the link counter when a node pointing to the item is reclaimed. - Reclaim the item only when its last link is released. - Note that atomic increments and decrements are used only if the node pointing to an item is cloned. Added a test to detect the incorrect behavior. This change fixes only the regular (non-SIMD) version. Currently, the SIMD version fails the added test, therefore (for now) the test is enabled only for the regular version. Reviewed By: davidtgoldblatt Differential Revision: D30371519 fbshipit-source-id: 29e143712afb3ef794f9f6f4d99919d5b4688416
Showing
Please register or sign in to comment