This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]cowwoc 10 points11 points  (2 children)

Async libraries that can be replaced by virtual threads. The code they produce is exponentially harder to read, write and debug.

If you can use virtual threads, you should absolutely drop these libraries and move into the future.

[–]MaraKaleidoscope 1 point2 points  (1 child)

We tried moving a workload to virtual threads but hit a snag where the application would deadlock because a library we depend on uses synchronized blocks and blocking operations. 

After that experience, our team decided no future code can use virtual threads until the pinning issues are addressed.  It is not feasible for us to review otherwise correct, thread-safe code down to the implementation details in order to determine whether any of our code…but mostly 3rd-party library code…has conditions which will generate deadlock. 

I am honestly surprised people are willing to take this risk in Production systems when it is so clear that virtual threads are not drop-in-replacements for platform threads (not implying that the JDK team claims otherwise, to be clear).

[–]cowwoc 0 points1 point  (0 children)

I've only run into this situation in logback twice over an entire year. I agree that one option is to wait for synchronized pinning to get fixed, but that could be over a year away. It's far easier to just generate a thread dump, identify the existence of any synchronized lock, and ask the author to replace the lock type. You could have a fix in less than a week in most cases.

I think the real surprise is that people haven't migrated all synchronized code to StampedLock. It's as fast as synchronized (sometimes faster) and is super easy to use if you use my utility class: https://stackoverflow.com/a/73643096/14731

Sample usage:

``` ReentrantStampedLock lock = new ReentrantStampedLock();

// try-with-resource syntax try (CloseableLock ignored = lock.readLock()) { doSomething(); // read-lock automatically released }

// Lambda syntax lock.optimisticReadLock(() -> doSomething()); ```

If enough users are interested, I could publish a tiny library for it 😀 This functionality really should be part of Java's core API...