4 ms·

IMO thread programming via locks, mutexes and such is in the same category as assembly programming - they're necessary low level primitives that are extremely e

by m12k 9y ago

IMO thread programming via locks, mutexes and such is in the same category as assembly programming - they're necessary low level primitives that are extremely easy to get wrong, and hence they should ideally be left to specialized experts, who can use them to develop higher level abstractions (e.g. worker pools, event queues, tasks) that normal application developers can use for most of their use cases.

tr1ck5t3r 9y ago
Threaded programming is best thought of as independent programs which can interact with other programs without the hassle of dealing with unknown or to-be-learnt communication methods like pipes, DDE, COM, poke/peek and so on. Its more of an issue now a days as there are many multi-core cpu's unlike the old days where a cpu was typically single core and everything ran like clockwork. With multi-core multi threaded programs you are just picking ways for these threads or independent programs to wait for other parts to catch up and vice versa.
yashap 9y ago
Agreed. I've been programming primarily in Scala the last few years, which has great high-level concurrency abstractions, and the code honestly stays readable and easy to reason about. We get the odd concurrency-related bugs, but they're reasonably rare, no more common than people screwing up things like time, text encoding, not properly using db indexes, etc. Thread-based concurrency need not be overly scary. Any concurrency model will take some time to wrap your head around, but with the good ones, once you get comfortable with them, they should feel very safe, intuitive and deterministic. Scala's approach of "Futures + immutability when you don't need mutable state, or Actors when you do need mutable state" has worked well for every problem I've encountered in the last few years, and I've certainly heard great thing's about Go's approach too. ES6 has improved the state of concurrency in JS, it's now similarly easy to read and reason about as Scala's model, but the lack of actual parallelism is a pretty big limitation - often a deal breaker for server-side code, and still often an issue client-side.
- hannofcart 9y ago
  > but lack of actual parallelism is a pretty big limitation - often a deal breaker for... Well, in my experience, it has been a deal breaker in a select few, rare cases. But often? Do you routinely come across problems that could NOT be solved using a multiprocess approach (in Node) or webworkers on the client side? Could you share some of these scenarios?
  - throwme211345 9y ago
    All the time. Web development is a sad excuse for experience in HPC environments. But node guys always think I/O processing in an event loop must work for everything!!!! With that approach we can go back to the happy openmpi/mpich days and take the gargantuan performance hit that ended MPI clustering for any serious real time scientific processing.
    - hannofcart 9y ago
      > All the time. Again, I must press for examples/real scenarios.
      - throwme211345 9y ago
        30 arc second permutation on a TC forecast track as it impacts multiple points of interest across multiple impact models. Heavily parallel amenable and in RT not an async endeavor. Not giving you more 'hints'. You webdevs are kind of dull anyway. I/O this and I/O that and you'll accept untrusted input until the sec industry all drive ferraris on your mistakes.
  - pdpi 9y ago
    How about database access? Even node uses a thread pool under the covers for that.
asimpletune 9y ago
I like the syntax that C# provides to make the code easier to reason about.
- GordonS 9y ago
  I agree, and things like the TPL make some uses of parallelism remarkably simple
throwme211345 9y ago
Disagree. Threaded programming is not that difficult. Design matters. If you are trying to back fit threads into legacy code that has a traditional process based model with massively shared data structures it can be a little ugly. Most peoples problems come with being over clever with their per thread data/stack, priorities, affinities, attributes, etc..a simple threaded program with a couple of locks for shared data and a flat schedule is efficient and easy to understand on multi-core systems. Event loops and aio are nice but they are not a superior standalone solution as evidenced by nodes use of libuv.

by m12k 9y ago

tr1ck5t3r 9y ago

Threaded programming is best thought of as independent programs which can interact with other programs without the hassle of dealing with unknown or to-be-learnt communication methods like pipes, DDE, COM, poke/peek and so on. Its more of an issue now a days as there are many multi-core cpu's unlike the old days where a cpu was typically single core and everything ran like clockwork. With multi-core multi threaded programs you are just picking ways for these threads or independent programs to wait for other parts to catch up and vice versa.

yashap 9y ago

Agreed. I've been programming primarily in Scala the last few years, which has great high-level concurrency abstractions, and the code honestly stays readable and easy to reason about. We get the odd concurrency-related bugs, but they're reasonably rare, no more common than people screwing up things like time, text encoding, not properly using db indexes, etc. Thread-based concurrency need not be overly scary. Any concurrency model will take some time to wrap your head around, but with the good ones, once you get comfortable with them, they should feel very safe, intuitive and deterministic. Scala's approach of "Futures + immutability when you don't need mutable state, or Actors when you do need mutable state" has worked well for every problem I've encountered in the last few years, and I've certainly heard great thing's about Go's approach too. ES6 has improved the state of concurrency in JS, it's now similarly easy to read and reason about as Scala's model, but the lack of actual parallelism is a pretty big limitation - often a deal breaker for server-side code, and still often an issue client-side.

hannofcart 9y ago
> but lack of actual parallelism is a pretty big limitation - often a deal breaker for... Well, in my experience, it has been a deal breaker in a select few, rare cases. But often? Do you routinely come across problems that could NOT be solved using a multiprocess approach (in Node) or webworkers on the client side? Could you share some of these scenarios?
- throwme211345 9y ago
  All the time. Web development is a sad excuse for experience in HPC environments. But node guys always think I/O processing in an event loop must work for everything!!!! With that approach we can go back to the happy openmpi/mpich days and take the gargantuan performance hit that ended MPI clustering for any serious real time scientific processing.
  - hannofcart 9y ago
    > All the time. Again, I must press for examples/real scenarios.
    - throwme211345 9y ago
      30 arc second permutation on a TC forecast track as it impacts multiple points of interest across multiple impact models. Heavily parallel amenable and in RT not an async endeavor. Not giving you more 'hints'. You webdevs are kind of dull anyway. I/O this and I/O that and you'll accept untrusted input until the sec industry all drive ferraris on your mistakes.
- pdpi 9y ago
  How about database access? Even node uses a thread pool under the covers for that.

asimpletune 9y ago

I like the syntax that C# provides to make the code easier to reason about.

GordonS 9y ago
I agree, and things like the TPL make some uses of parallelism remarkably simple

throwme211345 9y ago

Disagree. Threaded programming is not that difficult. Design matters. If you are trying to back fit threads into legacy code that has a traditional process based model with massively shared data structures it can be a little ugly. Most peoples problems come with being over clever with their per thread data/stack, priorities, affinities, attributes, etc..a simple threaded program with a couple of locks for shared data and a flat schedule is efficient and easy to understand on multi-core systems. Event loops and aio are nice but they are not a superior standalone solution as evidenced by nodes use of libuv.