Hacker News Reader

Hacker News

Comment by re-thc | Hacker News Reader

Full thread

re-thc

Finally no pinning for virtual threads!

View on HN

Yes!

I will compare my NIO multiplayer system to SVTwP (Sync. Virt. Threads without Pinning) and report back!

Looking forward to hearing about it.

I look forward to that. When you say, NIO, what specific changes would you make to use virtual threads instead? Could you give a small code example?

What will be the implications of this? e.g. Can we now handle more req/sec on I/O blocking services, because more requests can be serviced by VTs and they will not be blocked waiting for IO, so kinda like Node.js async model (for free) but with multiple threads?

That was always possible and the whole point of virtual threads. This concerns reliability. So far there was this annoying papercut of virtual threads not freeing up their carrier thread when they were waiting to enter a `synchronized` lock. That could easily lead to reduced throughput or even deadlocks when all carrier threads got pinned.

Yeah, I mean now we can start using VTs on any system / lib without being worried of pinning. Isn't this a "huge" deal? Why is the community not shouting from the rooftops about this?

Theoretically it means, Java has now bettered Node.js "async / await" approach and that too without the two colored function approach. One process can now spawn thousands of threads to service IO and none of those threads are blocking / waiting (and with this release there is no gotcha / pitfall remaining).

Not mention all the Netty / reactive libraries have no use now (not that I am complaining).

Indeed, the relief is great. However, there are relatively few users of virtual threads yet. Even fewer are keeping up with the releases. Those using it in production already managed to work around the issues or have given up on it. We will hear more when Java 25 is released (which will be an Oracle LTS version) or if a backport to LTS 21 happens.

> Not mention all the Netty / reactive libraries have no use now (not that I am complaining).

Netty uses an eventloop/async paradigm. The benefit of that style is you do not need any locking (within the same eventloop). How does virtual threads make that of no use?

No need for complex async / event loop stuff. VTs can be spawned by millions and they will not block the thread (/CPU) while doing IO, in this (win-win) scenario there is no value in doing complex (and 2 colored) async programming.

You didn't answer the question though. When I use a single threaded event loop with async style, I don't need to use any locks. It isn't about efficiency, it is about low complexity because I don't need to reason about shared state.

Is it good practice or not to use locking semantics if you use virtual threads?

It is totally fine to use locking with virtual threads. Of course you don't need it if you don't have to restrict access to shared resources in the first place (for example a connection pool or a datastructure with internal invariants that have to be maintained) or if lockless alternatives are available.

You can now safely use virtual threads to run code that uses "synchronized".

As someone coming from Node.js: virtual threads are amazing. Async behaviour without the async/await headaches.

My first experience with virtual threads was way less memory used.

> My first experience with virtual threads was way less memory used.

understandable. Normal java threads have underlying OS threads, which have their own stack and memory overhead. virtual threads are much lighter in this sense.

Reply on news.ycombinator.com