If item is marked as moving in ReleaseBackToAllocator just skip this item
It will be discareded by the moving thread once it realises there is no parent item. (moveChainedItem verifies the parent handle and if the parent is being evicted the handle will be NULL).
We don't actually need to to synchronize (check isMoving) for every child item in the chain when iterating
forEachChainedItem / viewAsChainedAlloc will synchronize on the chainedItemLocks_ (we don't actually do anything with the moving item until we grab exlusive lock in moveChainedItem)
popChainedItem - will synchronize on acquire(head)
replaceChainedItem - will synchronize on acquire(oldItem)
addChainItem - no problem, synchronization on chainedItemLocks_
transferChainLocked - the moving item might be transferred to a new parent. That's fine, we will notice this in moveChainedItem and return false.
Whenever head item is used in those functions, there is a handle acquired for it so it will also synchronize correctly.
I assume this will suffer from the same deadlock problem that @byrnedj solved by using tryLock on chaineItemLocks_. Probably we'll need the same approach here.
@byrnedj Regarding 3 (this might apply to your approach as well): Perhaps we could solve the deadlock by just using the same chainedItemLocks that is used to synchronize modifications to the chain? I mean, when creating a wait context for a child item, why not just use `chainedItemLocks[child.getParent().getKey()]`? (if this is possible to implement)
This is WIP, does not compile and SlabRelease logic in untouched.
Add child-item synchronization
Mark child item as moving, instead of a parent.
Assumptions/description:
We don't actually need to to synchronize (check isMoving) for every child item in the chain when iterating
Whenever head item is used in those functions, there is a handle acquired for it so it will also synchronize correctly.
@byrnedj Regarding 3 (this might apply to your approach as well): Perhaps we could solve the deadlock by just using the same chainedItemLocks that is used to synchronize modifications to the chain? I mean, when creating a wait context for a child item, why not just use `chainedItemLocks[child.getParent().getKey()]`? (if this is possible to implement)
This change is