Another virtual threads migration story: ReentrantReadWriteLock

[David Holmes]

On 30/01/2025 4:20 am, Andrew Haley wrote:
> On 1/29/25 16:58, Matthew Swift wrote:
>>
>> Given that scaling IO to millions of concurrent IO bound tasks was one 
>> of the key motivations for vthreads, it seems a bit surprising to me 
>> that a basic concurrency building block of many applications is 
>> constrained to 64K concurrent accesses. Are you aware of this 
>> limitation and its implications?
> 
>           * Lock state is logically divided into two unsigned shorts:
>           * The lower one representing the exclusive (writer) lock hold 
> count,
>           * and the upper the shared (reader) hold count.
> 
> I have no love at all for arbitrary limits, and this certainly sounds like
> one. And you may be right that these days it's something that might happen
> in real-world deployments.

More of a practical limit than an "arbitrary" one.  Noone was going to 
hit 64K contending platform threads. And requiring general 64-bit atomic 
operations back when 32-bit was still very much mainstream, would not 
have produced an efficient implementation.

> Here's a suggestion: it shouldn't be madly difficult to rewrite the code so
> that instead of an int split into two unsigned shorts, it uses a long split
> into two unsigned ints. Why not give that a try, and see what happens?
> Building OpenJDK on most platforms is fairly straightforward these days.

Simply rebasing to extend AbstractLongQueuedSynchronizer instead of AQS, 
as others have suggested, may "just work".

Cheers,
David

> Once you have some information about how well it works in practice, it may
> be appropriate to talk to Doug Lea, the author, about removing the 
> limitation.
>