7 ms·

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++

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?

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?