CancellableQueueSynchronizer and ReadWriteMutex

[ndkoval]

Introduce SegmentQueueSynchronizer abstraction for synchronization primitives and ReadWriteMutex. Please follow the provided documentation and the test suite for details.

[ndkoval]

Here is a link to a successful nightly build with these changes: https://teamcity.jetbrains.com/buildConfiguration/KotlinTools_KotlinxCoroutines_NightlyStress/3009472

[dkhalanskyjb]

A small problem here. I believe this should be cur <= parties.toLong(), but I think it's interesting why so and, more importantly, why it didn't cause any problems.

parties - 1 calls happen and go to sleep; then comes the call that is about to wake everyone up but doesn't yet do anything after incrementing the counter; then, 1000 new calls happen, and a == parties + 1000. Then, every thread is cancelled, performs onCancellation and, since arrived is much bigger than parties.toLong(), successfully decrements arrived. Then the resumer comes, sees parties - 1 CANCELLED marks and proceeds to wake up parties - 1 more cells.

This works only because this behavior, while not optimal, doesn't break anything: after the cells are all woken up, this SQS is never used again. However, if resumeMode was set to SYNC, everything would hang in this scenario, but it seems that with the change above it would work fine in this case too.

It should be noted though that without the check for cur == parties.toLong() the code would not be linearizable: as is, it guarantees that once the barrier is broken, it can't be accidentally "un-broken" no matter how many cancellations happen, and so the subsequent calls to arrive all return false in any case.

[ndkoval]

It should be either >= or ==. In my opinion, it is always better to decrement the counter if possible, so that the number of resume invocations is decreased. We should also add a check that the barrier is completed at the beginning of arrive. Thus, the last arrive() works in O(T+K) where K is the number of parties and T is the number of threads (not coroutines).

[dkhalanskyjb]

Comments about the first comment.

[ndkoval]

We should add a comment here once the PR is merged

[dkhalanskyjb]

A small batch of suggestions for now.

[ndkoval]

It's important not to forget about #2401 when introducing RWMutex

[GavinRay97]

Just out of curiosity, why did this die?

It seems well-written/documented (can't comment on the implementation)

[qwwdfsad]

There were unresolved questions about public API shape and how to expose read/write parts.
We may return to it after #3103

[Tmpod]

We may return to it after #3103

That was merged earlier this year (congrats to all btw, big PR!). Has there been any internal progress on this since then?

[qwwdfsad]

@Tmpod we are evaluating this change on IDEA codebase.
Could you please elaborate on your interest in this primitive? E.g. what use-cases are you aiming to solve with it?

[Tmpod]

Could you please elaborate on your interest in this primitive? E.g. what use-cases are you aiming to solve with it?

I am looking to improve the performance of some datastructures which are temporarily using just a single mutex both for reading and writing. Using a readers-writer lock seems like a good option.[1] I've seen a lot of other people, in issues and the likes, asking for this type of synchronization primitive as well. I may end up writing my own primitive, based on code shared around here, for the time being, but having a high-quality implementation in the library would be really useful (though quite hard, I know!). [1]: It should be noted that updating this datastructure cannot be done atomically since it's quite non-trivial.