4 ms·

Wow. That made my head hurt. And, I'm more convinced than ever before that threads remain a TERRIBLE idea. Maybe Java 13 will have something like Erlang task

Wow. That made my head hurt. And, I'm more convinced than ever before that threads remain a TERRIBLE idea. Maybe Java 13 will have something like Erlang tasks with isolated memory and message queues (only) or something... Somehow I expected more on memory allocation, arrangement or whatnot, rather than concurrency access. Glad I clicked on it for the nightmarish skim, though.

chrisseaton 10y ago
This isn't what a normal programmer using threads is supposed to do. Most people using threads are expected to use locks, concurrent data structures and higher level tools. This is all about covering behaviour for very low level programs and language implementations which don't use these tools.
fpoling 10y ago
The current situation with just few cores is temporary. In future CPU with massive numbers of cores will be a norm and Erlang model will be very natural. Also things like transactional memory should make life easier.
sievebrain 10y ago
Complicated things are not inherently terrible ideas: your CPU is complex, but you have compilers to abstract you from it. Likewise the ways your multi-core machine shares memory is complicated, and the JMM partly abstracts it, but really you're meant to use much higher level constructs. The JMM matters to people writing lock libraries and compilers, not ordinary users. It's a common logical fallacy that you can simplify a complex solution by simply redefining the problem it solves as not a problem. The "Erlang model" you discuss is in fact the model the entire computing world used before threads were invented and there were only processes. But threads weren't invented for shits and giggles, they were invented for good reasons!
- pawadu 10y ago
  well said (written)!
- Roboprog 10y ago
  I seem to remember first seeing threads used to run Novell and OS/2 on the 80286. (they must of been invented long before that, but that was my initial "OMG!" exposure to them) But threads aren't just complicated, they are dangerous. E.g. - if somebody forgets and updates something in an instance variable in a Java servlet, rather than local variables, hilarity/calamity ensues. By the time you are using thread pools, vs "spawn at will", how much better off are you than using a pool of processes safely separated by explicit interprocess communication?
- e12e 10y ago
  > But threads weren't invented for shits and giggles, they were invented for good reasons! I remain unconvinced ;-) It always seemed to me, that if threads were such a great idea, operating systems should expose threads, and not processes. In a way NT and Linux took different paths here - on Windows processes are expensive, on Linux threads and processes are pretty much the same in terms of overhead (but threads obviously allow sharing memory, for better or worse). I've long suspected that if threads really could "be done right", they would've been preferred to processes. But just like people worked really hard to get hardware protected memory to be fast enough to be usable, I think working hard to get processes to be "fast enough" is more viable than "getting threads right". Amusingly, I suppose Erlang is actually an example of how mixing the two ideas can be a great idea: Don't let programmers know their "process" is a scheduled thread, force messaging over shared memory - and reap the benefit of light weight processes and strong(-ish) protection between threads...
syngrog66 10y ago
my #1 rule of multi-threaded programming: don't do it. failing that my #2 rule is to make sure you know exactly what you're doing and even then exercise extreme care. #3 is have no mutable shared memory state. #4 is to use queues of immutable messages if needed to communicate between the threads.
- Roboprog 10y ago
  And then you call something that, unbeknownst to you, updated some shared state like a singleton. I like your rule #1. (But I do Java server programming so I can put the kids through school, so, "Damn the torpedoes! Full speed ahead!")
  - syngrog66 10y ago
    > And then you call something that, unbeknownst to you, updated some shared state like a singleton. that would mean one has violated rule 1 and 2. the challenge is that it seems to be rare to find programmers who can nail rule 2 downward. (though they do exist.) thus... rule 1. agreed. :-) flashbacks to fixing dozens of race conditions and thread leaks back at a major travel ecommerce website...
    - Roboprog 10y ago
      I've had the same "flashback" for a financial account site I inherited. Offshore work done in a hurry... In fairness, though, it's hard to constantly be on your guard NOT to EVER update something that might be visible to another concurrent request. It's interesting that the MS web app model for .NET was to make a new instance of the service code for a page for each request, to at least avoid this problem the moment you "walked in the front door". TL;DR: shared.setState( "Oops!" );

chrisseaton 10y ago

This isn't what a normal programmer using threads is supposed to do. Most people using threads are expected to use locks, concurrent data structures and higher level tools. This is all about covering behaviour for very low level programs and language implementations which don't use these tools.

fpoling 10y ago

The current situation with just few cores is temporary. In future CPU with massive numbers of cores will be a norm and Erlang model will be very natural. Also things like transactional memory should make life easier.

sievebrain 10y ago

Complicated things are not inherently terrible ideas: your CPU is complex, but you have compilers to abstract you from it. Likewise the ways your multi-core machine shares memory is complicated, and the JMM partly abstracts it, but really you're meant to use much higher level constructs. The JMM matters to people writing lock libraries and compilers, not ordinary users. It's a common logical fallacy that you can simplify a complex solution by simply redefining the problem it solves as not a problem. The "Erlang model" you discuss is in fact the model the entire computing world used before threads were invented and there were only processes. But threads weren't invented for shits and giggles, they were invented for good reasons!

pawadu 10y ago
well said (written)!
Roboprog 10y ago
I seem to remember first seeing threads used to run Novell and OS/2 on the 80286. (they must of been invented long before that, but that was my initial "OMG!" exposure to them) But threads aren't just complicated, they are dangerous. E.g. - if somebody forgets and updates something in an instance variable in a Java servlet, rather than local variables, hilarity/calamity ensues. By the time you are using thread pools, vs "spawn at will", how much better off are you than using a pool of processes safely separated by explicit interprocess communication?
e12e 10y ago
> But threads weren't invented for shits and giggles, they were invented for good reasons! I remain unconvinced ;-) It always seemed to me, that if threads were such a great idea, operating systems should expose threads, and not processes. In a way NT and Linux took different paths here - on Windows processes are expensive, on Linux threads and processes are pretty much the same in terms of overhead (but threads obviously allow sharing memory, for better or worse). I've long suspected that if threads really could "be done right", they would've been preferred to processes. But just like people worked really hard to get hardware protected memory to be fast enough to be usable, I think working hard to get processes to be "fast enough" is more viable than "getting threads right". Amusingly, I suppose Erlang is actually an example of how mixing the two ideas can be a great idea: Don't let programmers know their "process" is a scheduled thread, force messaging over shared memory - and reap the benefit of light weight processes and strong(-ish) protection between threads...

syngrog66 10y ago

my #1 rule of multi-threaded programming: don't do it. failing that my #2 rule is to make sure you know exactly what you're doing and even then exercise extreme care. #3 is have no mutable shared memory state. #4 is to use queues of immutable messages if needed to communicate between the threads.

Roboprog 10y ago
And then you call something that, unbeknownst to you, updated some shared state like a singleton. I like your rule #1. (But I do Java server programming so I can put the kids through school, so, "Damn the torpedoes! Full speed ahead!")
- syngrog66 10y ago
  > And then you call something that, unbeknownst to you, updated some shared state like a singleton. that would mean one has violated rule 1 and 2. the challenge is that it seems to be rare to find programmers who can nail rule 2 downward. (though they do exist.) thus... rule 1. agreed. :-) flashbacks to fixing dozens of race conditions and thread leaks back at a major travel ecommerce website...
  - Roboprog 10y ago
    I've had the same "flashback" for a financial account site I inherited. Offshore work done in a hurry... In fairness, though, it's hard to constantly be on your guard NOT to EVER update something that might be visible to another concurrent request. It's interesting that the MS web app model for .NET was to make a new instance of the service code for a page for each request, to at least avoid this problem the moment you "walked in the front door". TL;DR: shared.setState( "Oops!" );