4 ms·

Java 21 Virtual Threads – Dude, Where's My Lock?

35 points by ecliptik 2y ago

exabrial 2y ago
That was a fascinating read. Kinda cool to see a "big" company use the same humble toolset I do.
deleted 2y ago
[deleted]
anonymousDan 2y ago
This tallies with my experience of user space threading libraries. It breaks a lot of the existing tooling around concurrency debugging and can make it really tricky to figure out subtle issues. At least in many cases I guess it's not fundamental and just requires improved runtime support.
- readthenotes1 2y ago
  I remember having similar problems with green threads as they were called back before they were removed from the language. (https://en.m.wikipedia.org/wiki/Green_thread https://en.m.wikipedia.org/wiki/Green_thread) In our case, it was because of developer failed to use a finely block to close the socket on our side.
krackers 2y ago
What was the solution? If you are creating many virtual threads which might indirectly end up using locks/synchronized, it seems like this is a solution that one could easily encounter
- rezonant 2y ago
  The solution isn't stated specifically, but either the underlying lock primitives need to be changed to address the synchronization block pinning of virtual threads in their selection of which lock requester wins, or the application developer needs to avoid obtaining a contentious lock within a synchronized block.
  - krackers 2y ago
    >the application developer needs to avoid obtaining a contentious lock within a synchronized block. The promise of virtual threads was that you could use existing libraries and mostly have things "just work", so relying on the developer to know about the internal synchronization behavior of all transitive libraries used seems risky. Is the former something that is being worked on for jdk23 (the article only vaguely suggests that they will "hopefully addresses the integration between virtual threads and locking primitives.")
    - sitta 2y ago
      Yeah, currently you have to be really careful about what you do in virtual threads. However, they are actively working on a solution to the issue with synchronized blocks. Once that's been solved, they should be a lot easier to use. Unfortunately, many of us will be stuck on 21 for some time now, and will need to continue to worry about synchronized blocks.

35 points by ecliptik 2y ago

exabrial 2y ago

That was a fascinating read. Kinda cool to see a "big" company use the same humble toolset I do.

deleted 2y ago

[deleted]

anonymousDan 2y ago

This tallies with my experience of user space threading libraries. It breaks a lot of the existing tooling around concurrency debugging and can make it really tricky to figure out subtle issues. At least in many cases I guess it's not fundamental and just requires improved runtime support.

readthenotes1 2y ago
I remember having similar problems with green threads as they were called back before they were removed from the language. (https://en.m.wikipedia.org/wiki/Green_thread https://en.m.wikipedia.org/wiki/Green_thread) In our case, it was because of developer failed to use a finely block to close the socket on our side.

krackers 2y ago

What was the solution? If you are creating many virtual threads which might indirectly end up using locks/synchronized, it seems like this is a solution that one could easily encounter

rezonant 2y ago
The solution isn't stated specifically, but either the underlying lock primitives need to be changed to address the synchronization block pinning of virtual threads in their selection of which lock requester wins, or the application developer needs to avoid obtaining a contentious lock within a synchronized block.
- krackers 2y ago
  >the application developer needs to avoid obtaining a contentious lock within a synchronized block. The promise of virtual threads was that you could use existing libraries and mostly have things "just work", so relying on the developer to know about the internal synchronization behavior of all transitive libraries used seems risky. Is the former something that is being worked on for jdk23 (the article only vaguely suggests that they will "hopefully addresses the integration between virtual threads and locking primitives.")
  - sitta 2y ago
    Yeah, currently you have to be really careful about what you do in virtual threads. However, they are actively working on a solution to the issue with synchronized blocks. Once that's been solved, they should be a lot easier to use. Unfortunately, many of us will be stuck on 21 for some time now, and will need to continue to worry about synchronized blocks.