Another virtual threads migration story: ReentrantReadWriteLock

[Andrew Haley]

On 1/30/25 01:41, 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.

I agree. My use of "arbitrary" was perhaps careless, but the limit appears
arbitrary today.

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

Indeed.

That was that was my point, really: experimentation is needed.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671