Another virtual threads migration story: ReentrantReadWriteLock

[David Holmes]

On 30/01/2025 11:41 am, David Holmes wrote:
> 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".

Though I meant to add that I think you will run into other scalability 
issues once you are dealing with such large numbers of threads.

David
-----

> 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.
>>
>