Lock Contention issue

[PedroMPagani]

Expected behavior

Have almost no lock overhead that would trigger a possible lag source due to lock await across multiple regions.

I don't know exactly how this could even sort of work, but I feel like this a very bad limitation for the design of Folia currently. if not the most limiting issue. outside just making sure that code is optimized in here, I wonder what other sort of design could be approached.

Observed/Actual behavior

Ok, to start off, the current lock is acquired when it seems that there's not an available section, this shouldn't be an issue if there is one, because that would avoid the contention. But otherwise, the lock is global for the entire design of the system, and if it's within processes end-up costing a lot more, this is basically creating a contention across multiple regions that could potentially for example, be loading a chunk.
since this method is acquired by the addChunk( method.
now let's say that this process for some reason takes 10 milliseconds. that would mean every single region that is also trying to touch the lock, would have to wait 10 millis, and this lock contention happens across the Region Threads, so you could sort of consider this lock a database call in the "main-thread" of Paper to some point.

Another issue

This locker is also used for the markTicking and markNotTicking, which could increase extreme delays, including sort of "lag" delays that people might not be able to visualize fully if they don't have a lot of players which is the focus of Folia, so let's say that a single acquire end-up costing 200ms, this would cause lag on every single region that is also trying to tick, even though the contention on the markTick is just await time, not processing itself.

Steps/models to reproduce

Region merging, players loading chunks, things like this.

Plugin and Datapack List

.

Folia version

Latest 1.21.1 branch

Other

No response

[PedroMPagani]

Here are some examples of the issue, which will lead to those regions that were locking the lock,to instead take 400ms lag spike each

[PedroMPagani]

I'm trying to help improve the software. but Since some people seem to care too much about every detail of the pattern, i'll close this.

[Kadeluxe]

Why would you care about random users comments? If some "maintainer" closes an issue then OK, that's their business. Otherwise I don't see why you would want to close own issues if there were valid reasons to open them at the first place.

[PedroMPagani]

Why would you care about random users comments? If some "maintainer" closes an issue then OK, that's their business. Otherwise I don't see why you would want to close own issues if there were valid reasons to open them at the first place.

Because that's from the Paper team.

[clrxbl]

Why would you care about random users comments? If some "maintainer" closes an issue then OK, that's their business. Otherwise I don't see why you would want to close own issues if there were valid reasons to open them at the first place.

Because that's from the Paper team.

The person who has replied to you on both Discord & previous Github issues, is in fact, not part of the Paper team.

[Spottedleaf]

Yeah there is some potential gain to be made by using something like ReentrantAreaLock here, however using that would greatly complicate the implementation. It's sort of on my TODO list, but not very high.

You can alleviate some of this overhead by using a larger grid exponent (like 4 or 5).