[PluginsKers]

The multi-section ReentrantAreaLock.lock(fromX, fromY, toX, toY) overload rolls back a conflicting acquisition and immediately retries, repeatedly updating the concurrent hash table while the owner is still holding the area. Wait on the conflicting node's notifier after rolling back the partial acquisition, matching the single-section path.

Permanently notify and retire each partially acquired node before retrying. A contender can observe that node before rollback and start waiting afterwards; resetting its notifier with notifyThreadsAndBlock() can miss the notification and leave overlapping acquisitions waiting indefinitely. A fresh node keeps notifications associated with their original acquisition attempt.

This path appeared during a Folia profile using concurrentutil 1.2.4: one roughly 862 ms stall had 22 region threads waiting in ThreadedTicketLevelPropagator$UpdateQueue.await, while 435 of 438 execution samples from the other 22 region threads were in ReentrantAreaLock.lock and the concurrent table's putIfAbsent path. The same retry loop is present on master.

[R00tB33rMan]

Can confirm that this patch does in fact resolve what it claims. Tried against squaremap, where it derives from

[PluginsKers]

Can confirm that this patch does in fact resolve what it claims. Tried against squaremap, where it derives from

Thanks for confirming the fix with squaremap

[Spottedleaf]

0528d66

I noticed that another issue with the acquire logic is that the break logic was incorrectly done, it incorrectly only broke out of the coordinate x loop - allowing it to acquire more nodes even when contended.

I also don't think that the node needs to be created again, the node can be re-used by simply re-blocking it before acquiring more nodes (after waiting for a notification from the contended node).

b9a6efe