8 ms·

Java Concurrency – Understanding the Basics of Threads

142 points by turkogluc 6y ago

itsmemattchung 6y ago
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 and synchronization barriers — and how they help facilitate concurrency.
- selimthegrim 6y ago
  What books are used in your program?
  - dbsmith83 6y ago
    Idk about GP, but one book I highly recommend is Java Concurrency in Practice - https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601 https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz... It's old, but the material holds up well since it covers a lot of fundamentals
    - johnnycerberus 6y ago
      I also recommend it, a little bit old because it doesn't cover new features but the fundamentals are strong, Brian Goetz really did a great job.
    - robto 6y ago
      We were an all-Java shop and we were considering how to make our application a SAAS cloud application. Our senior engineers read this book. They all agreed that it was very educational, but the conclusion was that Java concurrency in practice has too many footguns, and so we ended up adopting Clojure. I think modern Java has better support for it, but if you've got mutable state spread throughout your application you're going to have a hard time no matter what.
      - secondcoming 6y ago
        > senior engineers read this book How does one become a senior engineer if you don't understand concurrency? Mutable state is most easily solved by having cpoies of everything, but then that's a tradeoff between performance and infrastructure/resource costs, but I guess that if you're in an all-Java shop that isn't much of an issue.
        flqn 6y ago
        Reading a book on the basics doesn't mean you don't have a grasp of them. I'd argue that refreshing your knowledge on things is a mark of a good engineer, regardless of seniority.
      - wging 6y ago
        Rich Hickey is supposed to have said that he created Clojure because he was tired of telling people to read that book. Best I can find as a source for now is https://www.youtube.com/watch?v=2y5Pv4yN0b0 https://www.youtube.com/watch?v=2y5Pv4yN0b0 -- I thought there was a link somewhere to Hickey himself saying this, but can't find it.
    - nobleach 6y ago
      I have the book. I've tried reading it several times. I just can't get into it. My major complaint is that it gives a ton of code examples and then "don't do this" is written under it. So one has to be extremely alert at all times while reading through the book. It dives right into the subject as if one has already been writing threaded code. Perhaps that's the target audience.
- derefr 6y ago
  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, there are only OS processes and memory regions. To learn about threads, you should just learn about OS processes; and then learn that distinct OS processes can share memory regions between them, often via subprocess-spawn-time inheritance. Learn what fork(2) does on POSIX, and how it manages to be fast. Starting with that intuition, it’s simple to then absorb what “threads” actually are: a usage pattern for spawning and managing OS processes that share memory; and a set of convenience APIs (that may be in-kernel, as in Windows; or purely in userland, as in Linux) for setting up this usage pattern. Everything these “threading” APIs can do, you can do yourself directly using the process-management and memory-mapping APIs. And those same calls are all that e.g. libpthread is doing.
  - rusk 6y ago
    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!
  - formerly_proven 6y ago
    This strikes me as rather focused on Linux kernel implementation details, since in Windows processes and threads are actually distinct concepts (as opposed to the Linux kernel, which really only knows about tasks), where every live process has n>1 threads and the address space of threads is afaik strictly defined through the process it is part of.
  - djeiasbsbo 6y ago
    I know about unix/linux processes, ipc and the relevant system calls (exec*, fork, clone, ...) but where do I continue from there? Studying C, I haven't really come across threads other than trying out the things in `pthread.h`. Would you recommend just reading the source code of that header for a better understanding?
yetkin 6y ago
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
- agumonkey 6y ago
  Do you use other paradigm / languages ? (clojure comes to mind, but maybe others)
  - itronitron 6y ago
    For Java at least, the Java Concurrency API is preferred.
  - mrjoelkemp 6y ago
    Actor model with Elixir/Erlang and the BEAM VM.
  - abhishekjha 6y ago
    Akka actor framework comes to mind. I am in the process of learning it and it is definitely simpler to wrap your head around it.
  - rowls66 6y ago
    I'll add Pony to the list. This language uses the actor model like Akka and Erlang, but allows for the safe sharing of data between actors enforced by an an ingenious use of the type system. The result is an actor programming model with better performance than Erlang because mutable data can be safely shared. I have been a long time Java developer, and I have worked a lot with highly concurrent code. Pony really opened my eyes to what was possible. Unfortunately, the language, standard library and runtime is still pretty immature. It does however have very good 'C' interop. So for some problems it would be a very good fit.
- FpUser 6y ago
  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 program but someone still has to program such layer.
deleted 6y ago
[deleted]
LgWoodenBadger 6y ago
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.
- alyandon 6y ago
  Pretty much. I can't even recall the last time I've had to touch a low level threading class in Java since the executors cover so many of the common use cases.
- Nursie 6y ago
  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!
  - thaumasiotes 6y ago
    But compare this very recent submission: https://news.ycombinator.com/item?id=24921657 https://news.ycombinator.com/item?id=24921657 which presents threads as the solution to the pain of using futures.
    - jaen 6y ago
      STM is not a solution to the pain of futures, STM is a "solution" to the pain of properly using locks, in particular when the concurrency is very fine-grained. A future internally is just a value or a set of waiters. Whether they are "colored" (ie. can you wait on a future in a non-future context), or based on threads or cooperative concurrency (ie. async) etc. is entirely an implementation detail, with significantly differing trade-offs. In that sense, you can really only compare future implementations with other concurrency systems.
- exabrial 6y ago
  I was going to comment that as well. Futures, Managed Executors, tasks, runnables, are more higher level structures that are better suited for general use. Those constructs are often implemented using threads though, so it's worth knowing what's happening one layer below the abstraction layer.
danielhlockard 6y ago
The font colors in the code examples are quite hard to read on my machine. `public class Main {` is so dark that I have to highlight to read
cultus 6y ago
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/ https://openjdk.java.net/projects/loom/
- cle 6y ago
  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.
  - cultus 6y ago
    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.
  - an_opabinia 6y ago
    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.
- mrkeen 6y ago
  > Delimited continuations can be used to implement algebraic effects, which is exciting for functional programming. How-so? I thought the type system was the precluding factor for algebraic effects, not the threading model.
JSavageOne 6y ago
I'm not a Java developer, but isn't RxJava the current best practice around managing concurrency in Java? I thought the consensus was that manually dealing with thread creation is too error-prone and unmanagable.
- sk5t 6y ago
  RxJava has some nice tools for async buffering, debounce, etc., but it pays to understand CountdownLatch, Semaphore, Mutex, ExecutorService, etc., and I would definitely not consider RxJava a substitute for other things. Do avoid anything related to the hoary old Java "Future" class, though. CompletionStage or get out!
- abhishekjha 6y ago
  We are using the Akka framework so as to not to have to deal with threads directly. Message passing and immutable objects simplify a lot while adding one more abstraction layer.
- vips7L 6y ago
  No, ExecutorServices are the current best practice around managing concurrency in Java. RxJava is only something you should use if you have specific performance requirements (with data to back it up), and you need the Observable pattern.
- pjmlp 6y ago
  RxJava got hyped in Android before Google went with Kotlt first, now they are into co-routines and depending on the Jetpack project, Java developers might still be able to use it, or be forced into Kotlin.
- bassman9000 6y ago
  Not quite. There were plenty and simpler abstractions to easily manage concurrency before, without even touching Thread. As someone has mentioned, Executors, ExecutorService, ThreadPools, ... RxJava feels like an unnatural port from single-threaded mindsets.
abhishekjha 6y ago
What a strange coincidence! I have started learning Java concurrency from the book[1]. I am on the synchronization chapter and it looks like managing threads via Runnable directly is going to be painful. I am hoping I get a good intro to Eecutors somewhere down the road. Adding the OP tutorial to go through once I have a better hold on writing concurrent programs. 1. https://www.amazon.in/Java-Threads-Concurrency-Utilities-Friesen/dp/1484216997 https://www.amazon.in/Java-Threads-Concurrency-Utilities-Fri...
edem 6y ago
I wouldn't accept anyone's PR with explicit Thread usage in them. You should either use some high-level construct like CompletableFuture or a concurrent data structure instead.
rurban 6y ago
And understand it's limitations: https://news.ycombinator.com/item?id=24955376 https://news.ycombinator.com/item?id=24955376 Java's insecure parallelism

142 points by turkogluc 6y ago

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 and synchronization barriers — and how they help facilitate concurrency.

selimthegrim 6y ago
What books are used in your program?
- dbsmith83 6y ago
  Idk about GP, but one book I highly recommend is Java Concurrency in Practice - https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601 https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz... It's old, but the material holds up well since it covers a lot of fundamentals
  - johnnycerberus 6y ago
    I also recommend it, a little bit old because it doesn't cover new features but the fundamentals are strong, Brian Goetz really did a great job.
  - robto 6y ago
    We were an all-Java shop and we were considering how to make our application a SAAS cloud application. Our senior engineers read this book. They all agreed that it was very educational, but the conclusion was that Java concurrency in practice has too many footguns, and so we ended up adopting Clojure. I think modern Java has better support for it, but if you've got mutable state spread throughout your application you're going to have a hard time no matter what.
    - secondcoming 6y ago
      > senior engineers read this book How does one become a senior engineer if you don't understand concurrency? Mutable state is most easily solved by having cpoies of everything, but then that's a tradeoff between performance and infrastructure/resource costs, but I guess that if you're in an all-Java shop that isn't much of an issue.
      - flqn 6y ago
        Reading a book on the basics doesn't mean you don't have a grasp of them. I'd argue that refreshing your knowledge on things is a mark of a good engineer, regardless of seniority.
    - wging 6y ago
      Rich Hickey is supposed to have said that he created Clojure because he was tired of telling people to read that book. Best I can find as a source for now is https://www.youtube.com/watch?v=2y5Pv4yN0b0 https://www.youtube.com/watch?v=2y5Pv4yN0b0 -- I thought there was a link somewhere to Hickey himself saying this, but can't find it.
  - nobleach 6y ago
    I have the book. I've tried reading it several times. I just can't get into it. My major complaint is that it gives a ton of code examples and then "don't do this" is written under it. So one has to be extremely alert at all times while reading through the book. It dives right into the subject as if one has already been writing threaded code. Perhaps that's the target audience.
derefr 6y ago
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, there are only OS processes and memory regions. To learn about threads, you should just learn about OS processes; and then learn that distinct OS processes can share memory regions between them, often via subprocess-spawn-time inheritance. Learn what fork(2) does on POSIX, and how it manages to be fast. Starting with that intuition, it’s simple to then absorb what “threads” actually are: a usage pattern for spawning and managing OS processes that share memory; and a set of convenience APIs (that may be in-kernel, as in Windows; or purely in userland, as in Linux) for setting up this usage pattern. Everything these “threading” APIs can do, you can do yourself directly using the process-management and memory-mapping APIs. And those same calls are all that e.g. libpthread is doing.
- rusk 6y ago
  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!
- formerly_proven 6y ago
  This strikes me as rather focused on Linux kernel implementation details, since in Windows processes and threads are actually distinct concepts (as opposed to the Linux kernel, which really only knows about tasks), where every live process has n>1 threads and the address space of threads is afaik strictly defined through the process it is part of.
- djeiasbsbo 6y ago
  I know about unix/linux processes, ipc and the relevant system calls (exec*, fork, clone, ...) but where do I continue from there? Studying C, I haven't really come across threads other than trying out the things in `pthread.h`. Would you recommend just reading the source code of that header for a better understanding?

yetkin 6y ago

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

agumonkey 6y ago
Do you use other paradigm / languages ? (clojure comes to mind, but maybe others)
- itronitron 6y ago
  For Java at least, the Java Concurrency API is preferred.
- mrjoelkemp 6y ago
  Actor model with Elixir/Erlang and the BEAM VM.
- abhishekjha 6y ago
  Akka actor framework comes to mind. I am in the process of learning it and it is definitely simpler to wrap your head around it.
- rowls66 6y ago
  I'll add Pony to the list. This language uses the actor model like Akka and Erlang, but allows for the safe sharing of data between actors enforced by an an ingenious use of the type system. The result is an actor programming model with better performance than Erlang because mutable data can be safely shared. I have been a long time Java developer, and I have worked a lot with highly concurrent code. Pony really opened my eyes to what was possible. Unfortunately, the language, standard library and runtime is still pretty immature. It does however have very good 'C' interop. So for some problems it would be a very good fit.
FpUser 6y ago
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 program but someone still has to program such layer.

deleted 6y ago

[deleted]

LgWoodenBadger 6y ago

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.

alyandon 6y ago
Pretty much. I can't even recall the last time I've had to touch a low level threading class in Java since the executors cover so many of the common use cases.
Nursie 6y ago
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!
- thaumasiotes 6y ago
  But compare this very recent submission: https://news.ycombinator.com/item?id=24921657 https://news.ycombinator.com/item?id=24921657 which presents threads as the solution to the pain of using futures.
  - jaen 6y ago
    STM is not a solution to the pain of futures, STM is a "solution" to the pain of properly using locks, in particular when the concurrency is very fine-grained. A future internally is just a value or a set of waiters. Whether they are "colored" (ie. can you wait on a future in a non-future context), or based on threads or cooperative concurrency (ie. async) etc. is entirely an implementation detail, with significantly differing trade-offs. In that sense, you can really only compare future implementations with other concurrency systems.
exabrial 6y ago
I was going to comment that as well. Futures, Managed Executors, tasks, runnables, are more higher level structures that are better suited for general use. Those constructs are often implemented using threads though, so it's worth knowing what's happening one layer below the abstraction layer.

danielhlockard 6y ago

The font colors in the code examples are quite hard to read on my machine. `public class Main {` is so dark that I have to highlight to read

cultus 6y ago

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/ https://openjdk.java.net/projects/loom/

cle 6y ago
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.
- cultus 6y ago
  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.
- an_opabinia 6y ago
  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.
mrkeen 6y ago
> Delimited continuations can be used to implement algebraic effects, which is exciting for functional programming. How-so? I thought the type system was the precluding factor for algebraic effects, not the threading model.

JSavageOne 6y ago

I'm not a Java developer, but isn't RxJava the current best practice around managing concurrency in Java? I thought the consensus was that manually dealing with thread creation is too error-prone and unmanagable.

sk5t 6y ago
RxJava has some nice tools for async buffering, debounce, etc., but it pays to understand CountdownLatch, Semaphore, Mutex, ExecutorService, etc., and I would definitely not consider RxJava a substitute for other things. Do avoid anything related to the hoary old Java "Future" class, though. CompletionStage or get out!
abhishekjha 6y ago
We are using the Akka framework so as to not to have to deal with threads directly. Message passing and immutable objects simplify a lot while adding one more abstraction layer.
vips7L 6y ago
No, ExecutorServices are the current best practice around managing concurrency in Java. RxJava is only something you should use if you have specific performance requirements (with data to back it up), and you need the Observable pattern.
pjmlp 6y ago
RxJava got hyped in Android before Google went with Kotlt first, now they are into co-routines and depending on the Jetpack project, Java developers might still be able to use it, or be forced into Kotlin.
bassman9000 6y ago
Not quite. There were plenty and simpler abstractions to easily manage concurrency before, without even touching Thread. As someone has mentioned, Executors, ExecutorService, ThreadPools, ... RxJava feels like an unnatural port from single-threaded mindsets.

abhishekjha 6y ago

What a strange coincidence! I have started learning Java concurrency from the book[1]. I am on the synchronization chapter and it looks like managing threads via Runnable directly is going to be painful. I am hoping I get a good intro to Eecutors somewhere down the road. Adding the OP tutorial to go through once I have a better hold on writing concurrent programs. 1. https://www.amazon.in/Java-Threads-Concurrency-Utilities-Friesen/dp/1484216997 https://www.amazon.in/Java-Threads-Concurrency-Utilities-Fri...

edem 6y ago

I wouldn't accept anyone's PR with explicit Thread usage in them. You should either use some high-level construct like CompletableFuture or a concurrent data structure instead.

rurban 6y ago

And understand it's limitations: https://news.ycombinator.com/item?id=24955376 https://news.ycombinator.com/item?id=24955376 Java's insecure parallelism