Live data from Hacker News

Java Concurrency – Understanding the Basics of Threads

turkogluc.com

21–30 of 86 posts

Re: Java Concurrency – Understanding the Basics of Threads

#21
post #19

Years ago, I tried learning how to use threads by following tutorials similar to this one, where you are taught how to implement threads from {python, java, c++}. However, it wasn't until I studied operating systems (when I returned to graduate school for computer science) was I able to wrap my mind around threads — from a language agnostic view point, how and what lightweight processes are, how to implement locks an…

Seconded. It’s silly to learn threads “from the outside in” — thinking of them as an opaque abstraction and trying to understand the API they present. There’s no coherent abstraction there; you’ll only learn to cargo-cult the API, without gaining an intuition for what threads “are” or when and where you’d want to use those APIs. The key thing to know, is that threads aren’t a first-class kernel object. In OS kernels,…

I just visualise it as different instruction pointers with their own stack and shared heap. But I’m coming from Java so that might be an oversimplification!

Re: Java Concurrency – Understanding the Basics of Threads

#22
Project Loom[0] is going to be coming out at some point. That brings direct JVM support for delimited continuations and fibers.

That's really going to change and simplify JVM concurrency and I think many other things. Delimited continuations can be used to implement algebraic effects, which is exciting for functional programming.

[0] https://openjdk.java.net/projects/loom/

Re: Java Concurrency – Understanding the Basics of Threads

#23

With Futures and Executors/ExecutorServices I find that I rarely ever need to use raw Threads these days. Most of the thread-safety issues commonly encountered are eliminated with this approach as well.

Likewise, with futures and executors I haven't had to touch threads directly for some time.

They give you the tools to just say "go away and do these things", which after years of dealing directly with pthreads in C was a breath of fresh air!

Re: Java Concurrency – Understanding the Basics of Threads

#24
post #17
post #6

Earlier quoted context omitted.

The concepts of threads and concurrent data access is simple enough for any decent programmer to comprehend. There is no hell here. Sure there are some complex cases but complex cases will arise in many situations when programming things. And achieving concurrency without shared memory is impossible in general case. Sure it is possible to isolate such access to a separate layer and make it transparent for the rest of…

The problem for novices is that a program that behaves correctly looks a lot like a correct program. Until one day it doesn’t. And because you’re in production and getting random spurious failures, the panicked (but common) reaction is to wrap every shared resource in a synchronized block. Which makes an incorrect implementation worse but possibly correct.

If the resource is shared and being accessed from many threads and is both written to and read from then it is the correct behavior to to lock it with the proper type of lock at access time. Depending on resource it might be possible to split it into few with more granular access.

As for novices: they are called that for reason and supposed to be under supervision rather than allowed running wild.

Re: Java Concurrency – Understanding the Basics of Threads

#25
post #4

The problem is not the threads, it is the mutations of variables which boost the complexity of the code. So a tutorial on creation of theads actually an invitation to hell. Nothing is cool about it. Cool thing is achieving concurrency without threads/race conditions/shared memory

There's a lot cool about threads, and you can learn to implement them well.

Threads handled well do not need to have race conditions, and race conditions/deadlocks are also very possible in distributed, message-passing systems.

Re: Java Concurrency – Understanding the Basics of Threads

#26
post #22

Project Loom[0] is going to be coming out at some point. That brings direct JVM support for delimited continuations and fibers. That's really going to change and simplify JVM concurrency and I think many other things. Delimited continuations can be used to implement algebraic effects, which is exciting for functional programming. [0] https://openjdk.java.net/projects/loom/

I honestly don’t think it will, not for a long time. It’s going to make things more complicated, because now we have to figure out how to move the entire ecosystem to it incrementally, while operating and maintaining systems during the long transition period, and making technical decisions at every step about how best to do concurrency with all those extra constraints.

Re: Java Concurrency – Understanding the Basics of Threads

#27
post #26
post #22

Project Loom[0] is going to be coming out at some point. That brings direct JVM support for delimited continuations and fibers. That's really going to change and simplify JVM concurrency and I think many other things. Delimited continuations can be used to implement algebraic effects, which is exciting for functional programming. [0] https://openjdk.java.net/projects/loom/

I honestly don’t think it will, not for a long time. It’s going to make things more complicated, because now we have to figure out how to move the entire ecosystem to it incrementally, while operating and maintaining systems during the long transition period, and making technical decisions at every step about how best to do concurrency with all those extra constraints.

I don't see it used much in legacy systems, but the benefits are large enough that I could see new Akka-ish libraries built on it.

Re: Java Concurrency – Understanding the Basics of Threads

#28
post #26
post #22

Project Loom[0] is going to be coming out at some point. That brings direct JVM support for delimited continuations and fibers. That's really going to change and simplify JVM concurrency and I think many other things. Delimited continuations can be used to implement algebraic effects, which is exciting for functional programming. [0] https://openjdk.java.net/projects/loom/

I honestly don’t think it will, not for a long time. It’s going to make things more complicated, because now we have to figure out how to move the entire ecosystem to it incrementally, while operating and maintaining systems during the long transition period, and making technical decisions at every step about how best to do concurrency with all those extra constraints.

Their compatibility story is alright though, at least they are trying to make "Thread" forward-compatible with the new runtime. And they are working on getting Netty to work, which will immediately get things compiling (not working) for a lot of projects.

The biggest challenge will be reconciling Futures, Netty and ThreadLocal (FiberLocal) patterns. Think defining a SQL transaction lifetime, a distributed lock, or a OpenTracing span. For Spring Framework people, no big deal. For everyone else, lots of complex decisions to make.

Re: Java Concurrency – Understanding the Basics of Threads

#29
post #4

The problem is not the threads, it is the mutations of variables which boost the complexity of the code. So a tutorial on creation of theads actually an invitation to hell. Nothing is cool about it. Cool thing is achieving concurrency without threads/race conditions/shared memory

A computer is a mutation machine, you cannot escape mutation by hand-waving it away. If you are writing programs in which you can achieve concurrency without threads and shared memory, it’s because you’re building on the shoulders of all the engineers who didn’t hand-wave it away. Many of us, due to product requirements, don’t have the luxury of using higher level abstractions like that.

Re: Java Concurrency – Understanding the Basics of Threads

#30
post #4

The problem is not the threads, it is the mutations of variables which boost the complexity of the code. So a tutorial on creation of theads actually an invitation to hell. Nothing is cool about it. Cool thing is achieving concurrency without threads/race conditions/shared memory

All the cool people are in Hell. Only go to Heaven for the climate.
Post reply on HN