6 ms·

YES. THANK YOU. I was just ranting about this elsewhere. People go "threads are evil" with vague rationales about getting locks right and such, and insist we al

by nknight 15y ago

YES. THANK YOU. I was just ranting about this elsewhere. People go "threads are evil" with vague rationales about getting locks right and such, and insist we all use separate heavyweight processes. It's ridiculous. Selection of sane data structures and communication channels can get you virtually all of the safety and ease of separate processes WITH the performance benefits of a shared memory space. It reminds me of people that criticize C++ for allowing memory leaks. There as here, simply selecting the right primitives and development strategy in advance make the problem simply disappear.

dkersten 15y ago
People go "threads are evil" with vague rationales about getting locks right and such, and insist we all use separate heavyweight processes. It's ridiculous. Nevermind the fact that (almost) all the things that (supposedly) make threads evil are still there when you use heavyweight processes.
- masklinn 15y ago
  The one thing that makes threads evil is shared memory, especially when doing so unknowingly. You can't share memory unknowingly with processes, when you can share memory at all.
  - dkersten 15y ago
    The "unknowingly" part is the big difference then. Besides that, you still have to deal with synchronization and mutual exclusion. Or you use a message passing model, which you can do with threads too, though your points in your other comment apply there, of course.
  - aufreak3 15y ago
    It's shared mutable memory that's the problem. Shared constants are alright.
    - masklinn 15y ago
      Sure, but semantically constants are about sharing values not memory, so they don't fall under "sharing memory" as far as I'm concerned.
      - aufreak3 15y ago
        That is a good abstraction for thinking about code. In the meanwhile, machines still have "one memory, many cores" architecture, in which inter-proc communication is about references is a practical optimization (like ref counting of binaries in Erlang). Some of those design decisions will have to change when machine archs move to "many (core, memory)" form.
  - jws 15y ago
    unknowing is key. Assume you are a programmer that can reliably code threaded, shared, mutable memory code… and you have to make a library call. Is it safe? Does it say it's safe? Do you believe it? What about the next release? If you single thread all calls to the library to be safe, is your program still provably deadlock free? The unknowns eat up a lot of thinking.
    - fauigerzigerk 15y ago
      They certainly do, but I'm very skeptical when I'm told that a language/runtime cannot do X because in 95% of all cases X is the wrong thing to do. What about the other 5%? Working around the lack of threads in those remaining instances takes orders of magnitude more work. Anyone who has ever implemented complex data structures in shared memory or memory mapped files knows that. No pointers, no new/delete/malloc/free, no garbage collector, just a big blob. It's definitely more difficult than using only a few well documented, high quality, libraries in the parts of the code where it matters.
    - wisty 15y ago
      If you are building an OS kernel, database kernel, or writing high-performance computational code (after having prototyped a low-performance version, and made sure that the high-level algorithmic design is sound) then must be picky about the libraries you use anyway. If you are writing a quick script, then you don't want to be picking through your libraries source code for thread safety. But 99% of people who use threads are just looking to keep a GUI looking responsive, which only takes a couple of processes anyway. Sand-boxing different components into their own process seems to be the way players like Google (Chrome) and Apple (Lion) are going anyway. While threads have their place, I think it's the same kind of place that inlined assembly should be considered.
    - nknight 15y ago
      Except deadlocks have nothing to do with sharing memory, and everything to do with sharing state. Shared state is necessary whether your address space is shared or not, and deadlocks will always be a risk in complex systems, whether the components involved are in the same or different processes. Anyway, I'm mostly a server-side engineer, so I can't speak well to the disastrous mess of GUI libraries and such, but the libraries I use are, indeed, thread-safe, and I'm quite confident that they will remain so. Their state is maintained through handles, not global variables.
masklinn 15y ago
> People go "threads are evil" with vague rationales about getting locks right and such, and insist we all use separate heavyweight processes. Insisting processes be used != insisting OS processes be used. Although most language don't give any choice in the matter. > Selection of sane data structures and communication channels can get you virtually all of the safety and ease of separate processes It gives you none of the safety, as you have to be very careful in ensuring no mutable datastructure is ever shared unknowingly. When using processes, you can't share memory implicitly, which is safe. > There as here, simply selecting the right primitives and development strategy in advance make the problem simply disappear. That's bullshit. It may make the problem less prominent, but it can not make the problem disappear.
- nknight 15y ago
  So you go from distinguishing between processes on the language and OS levels, to categorically declaring you can't share memory implicitly with processes. A facsimile of a process that isn't implemented as an actual process is going to be in a shared address space. Your pet bondage-and-discipline language might work to prevent one pseudo-process from interfering with another, but I don't see it being equal to full-blown processes, nor do I see it being substantively more trustworthy than making a few simple, easy decisions about how to structure your programs.
  - masklinn 15y ago
    > categorically declaring you can't share memory implicitly with processes. That's kind-of the whole point, and difference between threads and processes. If you have implicitly shared mutable memory with processes, your processes are broken and you have threads. > I don't see it being equal to full-blown processes Really? > nor do I see it being substantively more trustworthy That's interesting. So you don't see how the language enforcing a share-less discipline would be more trustworthy than people trying to do so informally? > than making a few simple, easy decisions about how to structure your programs. Such as not using any third-party code which has not been fully audited to the statement? What a simple and easy decision that is.
- 15y ago
tszming 15y ago
I believe most people are actually complaining "threads are hard to use", evil is just a possible outcome if they are used by incompetent programmers.

by nknight 15y ago

dkersten 15y ago

People go "threads are evil" with vague rationales about getting locks right and such, and insist we all use separate heavyweight processes. It's ridiculous. Nevermind the fact that (almost) all the things that (supposedly) make threads evil are still there when you use heavyweight processes.

masklinn 15y ago
The one thing that makes threads evil is shared memory, especially when doing so unknowingly. You can't share memory unknowingly with processes, when you can share memory at all.
- dkersten 15y ago
  The "unknowingly" part is the big difference then. Besides that, you still have to deal with synchronization and mutual exclusion. Or you use a message passing model, which you can do with threads too, though your points in your other comment apply there, of course.
- aufreak3 15y ago
  It's shared mutable memory that's the problem. Shared constants are alright.
  - masklinn 15y ago
    Sure, but semantically constants are about sharing values not memory, so they don't fall under "sharing memory" as far as I'm concerned.
    - aufreak3 15y ago
      That is a good abstraction for thinking about code. In the meanwhile, machines still have "one memory, many cores" architecture, in which inter-proc communication is about references is a practical optimization (like ref counting of binaries in Erlang). Some of those design decisions will have to change when machine archs move to "many (core, memory)" form.
- jws 15y ago
  unknowing is key. Assume you are a programmer that can reliably code threaded, shared, mutable memory code… and you have to make a library call. Is it safe? Does it say it's safe? Do you believe it? What about the next release? If you single thread all calls to the library to be safe, is your program still provably deadlock free? The unknowns eat up a lot of thinking.
  - fauigerzigerk 15y ago
    They certainly do, but I'm very skeptical when I'm told that a language/runtime cannot do X because in 95% of all cases X is the wrong thing to do. What about the other 5%? Working around the lack of threads in those remaining instances takes orders of magnitude more work. Anyone who has ever implemented complex data structures in shared memory or memory mapped files knows that. No pointers, no new/delete/malloc/free, no garbage collector, just a big blob. It's definitely more difficult than using only a few well documented, high quality, libraries in the parts of the code where it matters.
  - wisty 15y ago
    If you are building an OS kernel, database kernel, or writing high-performance computational code (after having prototyped a low-performance version, and made sure that the high-level algorithmic design is sound) then must be picky about the libraries you use anyway. If you are writing a quick script, then you don't want to be picking through your libraries source code for thread safety. But 99% of people who use threads are just looking to keep a GUI looking responsive, which only takes a couple of processes anyway. Sand-boxing different components into their own process seems to be the way players like Google (Chrome) and Apple (Lion) are going anyway. While threads have their place, I think it's the same kind of place that inlined assembly should be considered.
  - nknight 15y ago
    Except deadlocks have nothing to do with sharing memory, and everything to do with sharing state. Shared state is necessary whether your address space is shared or not, and deadlocks will always be a risk in complex systems, whether the components involved are in the same or different processes. Anyway, I'm mostly a server-side engineer, so I can't speak well to the disastrous mess of GUI libraries and such, but the libraries I use are, indeed, thread-safe, and I'm quite confident that they will remain so. Their state is maintained through handles, not global variables.

masklinn 15y ago

> People go "threads are evil" with vague rationales about getting locks right and such, and insist we all use separate heavyweight processes. Insisting processes be used != insisting OS processes be used. Although most language don't give any choice in the matter. > Selection of sane data structures and communication channels can get you virtually all of the safety and ease of separate processes It gives you none of the safety, as you have to be very careful in ensuring no mutable datastructure is ever shared unknowingly. When using processes, you can't share memory implicitly, which is safe. > There as here, simply selecting the right primitives and development strategy in advance make the problem simply disappear. That's bullshit. It may make the problem less prominent, but it can not make the problem disappear.

nknight 15y ago
So you go from distinguishing between processes on the language and OS levels, to categorically declaring you can't share memory implicitly with processes. A facsimile of a process that isn't implemented as an actual process is going to be in a shared address space. Your pet bondage-and-discipline language might work to prevent one pseudo-process from interfering with another, but I don't see it being equal to full-blown processes, nor do I see it being substantively more trustworthy than making a few simple, easy decisions about how to structure your programs.
- masklinn 15y ago
  > categorically declaring you can't share memory implicitly with processes. That's kind-of the whole point, and difference between threads and processes. If you have implicitly shared mutable memory with processes, your processes are broken and you have threads. > I don't see it being equal to full-blown processes Really? > nor do I see it being substantively more trustworthy That's interesting. So you don't see how the language enforcing a share-less discipline would be more trustworthy than people trying to do so informally? > than making a few simple, easy decisions about how to structure your programs. Such as not using any third-party code which has not been fully audited to the statement? What a simple and easy decision that is.
15y ago

tszming 15y ago

I believe most people are actually complaining "threads are hard to use", evil is just a possible outcome if they are used by incompetent programmers.