use ReentrantLock in LockUtil (Switch)

[pjfanning]

an example change for #1089

[He-Pin]

lgtm

[laglangyue]

lgtm

[pjfanning]

I won't merge this yet but I'd appreciate some feedback. With Loom in mind, there doesn't appear to be a big reason not to start changing synchronized blocks to ReentrantLocks. There is a fair amount of documentation online encouraging this change.

[He-Pin]

I think we should only do this where io is involved.

The only issue of the current implementation is it introduce some allocation with the by name parameter.

And a user can keep tracking where the pin happens with -Djdk.tracePinnedThreads=short.

I have changed mostly of my $Work code, to ReentrantLocks :)

[pjfanning]

I'm open to abandoning this. But if we abandon this, I think that #1089 should be changed to not be a 'good first issue'. It isn't a good first issue if it needs serious expertise to decide on which 'synchronized' blocks need to be changed.

To flip this on it's head, maybe we need to get people to use Pekko with virtual threads and to report to us the pinned thread issues that they hit.

[He-Pin]

I will back my hometown tomorrow, I will try to work on the virtual thread support.

[mdedetrich]

I'm open to abandoning this. But if we abandon this, I think that #1089 should be changed to not be a 'good first issue'. It isn't a good first issue if it needs serious expertise to decide on which 'synchronized' blocks need to be changed.

To flip this on it's head, maybe we need to get people to use Pekko with virtual threads and to report to us the pinned thread issues that they hit.

Completely agree with this, VirtualThread support is not a good first issue not only due to it deceptively easy but also because since its a JDK 21 feature as is well known we are having issues on whats the best way to integrate this into Pekko.

I am still heavily in the "lets just document how JDK 21 users can create their own VirtualThreadPool" camp rather than pushing these kind of changes in.

[pjfanning]

@mdedetrich this change does not use any new classes - it uses existing classes. synchronized has not been improved in Java 21 but locks like ReentrantLock have been. ReentrantLock does not block the carrier thread and other virtual threads can use the carrier thread while the lock is waiting. synchronized does block the carrier thread and other virtual threads will not get a chance to use the carrier thread during the synchronized blocking is waiting (known as pinning).

See https://softwaremill.com/what-is-blocking-in-loom/#retrofitting-blocking

[mdedetrich]

@mdedetrich this change does not use any new classes - it uses existing classes. synchronized has not been improved in Java 21 but locks like ReentrantLock have been. ReentrantLock does not block the carrier thread and other virtual threads can use the carrier thread while the lock is waiting. synchronized does block the carrier thread and other virtual threads will not get a chance to use the carrier thread during the synchronized blocking is waiting (known as pinning).

See https://softwaremill.com/what-is-blocking-in-loom/#retrofitting-blocking

I wasn't talking about this PR but the other one with VirtualThreadPool.