Hacker News Reader

Comment by karmakaze | Hacker News Reader

Using "synchronized" by itself and calling anything has the potential thread starvation or deadlocks. Virtual threads only makes it worse.

Kotlin has mutexes that presumably are compatible with coroutines:

  kotlinx.coroutines.sync.Mutex

Until Java sorts this out, it could be its "Rust async" watershed moment.

View on HN

I think this one's weird because the language puts so much effort into making it hard to hit this that you won't notice until it's a gigantic problem. For me, this was enough of a problem that I wrote a Java agent which patches the method which blocks the carrier thread to just throw (ByteBuddy makes it easy!).

Like, it makes sense that when you synchronized on an object, there's room for contention. It seems weird that synchronizing on an _uncontended_ object can cause contention. But that's what this is. The behaviour is that you have target numCores carrier threads, and if someone synchronizes on an object and then does a non-blocking sleep, it's now blocking, because synchronizing upgraded the non-blocking I/O to blocking.

So basically when you hit this issue, it's because not only has the bad thing been happening, it's also been happening badly enough that all the compensation mechanisms have failed.

It's just weird that a whole language level keyword behaves this badly.

You can use Concurrent Locks from the standard library. And it has been communicated that you should not be using low level concurrency constructs for years.

But people just… don’t.

> And it has been communicated that you should not be using low level concurrency constructs for years.

Where has this been communicated? The first I heard that you shouldn't use synchronized statements or blocks was in these virtual threads discussions; and the popular IDE I use for Java at work doesn't flag synchronized methods or blocks as something to be avoided. The only thing I had heard about it was that you should avoid synchronizing on objects exposed to users of your library, since it would make it possible for code outside your control to also synchronize on that same object (but IMO synchronizing on arbitrary objects you got from somewhere is itself a bad practice, you should only synchronize on objects you control). And obviously, synchronized methods or blocks do not have the "fair" mode, which might be necessary (or good) in some cases.

(And before Java 9, stack overflows within the implementation of some concurrency constructs could lead to unexpected behavior, see https://openjdk.org/jeps/270 for details; this was never a problem with synchronized methods or blocks.)

I started Java over a decade ago and by then no one was writing synchronized blocks when doing multithreaded code.

You’re being downvoted, but I haven’t done Java programming in over twenty years and even I knew that!

I've been coding in Java for a bit longer than that, and in my memory it's always been known that ReentrantLock is _faster_, but synchronized has better language level support (as in, the language won't let you forget to unlock, whereas with locks you need to remember your finally statement). And then, unlike ReentrantLock, synchronized uses no extra memory, which is good for things that end up being uncontended, and then in both cases, the performance doesn't matter if the lock is uncontended, which most of mine were.

There of course are things like ErrorProne that statically check that you unlocked your lock, but there's still bugs possible.

I hope anyone who learned the horrible construction of double-checked locking would have used an alternative.

Reply on news.ycombinator.com