3 ms·

Idk I think it is not as difficult as it is sometimes framed. I think the key is to design your program/separation of concerns in such a way as to make it easy

by skohan 4y ago

Idk I think it is not as difficult as it is sometimes framed. I think the key is to design your program/separation of concerns in such a way as to make it easy to reason about concurrency, and minimize the need for synchronization points. I think a lot of the problems arise when you just try to write normal synchronous code, or to parallelize code which was originally synchronous, and don't realize the implicit constraints you had been relying on which no longer hold when concurrency is introduced.

ChrisMarshallNY 4y ago
FP is good for adapting to threading, but it has difficulties, when applied to things like GUI programming, async communications, or device control (places that need threading). A lot of languages are getting things like async/await/actor, etc., but even that is still too low-level for a lot of programmers. It can easily turn into a lot of single-threaded code. It needs to be completely under the surface. Swift does that with generics (I suspect other languages do it, as well). For example, you can say Array<Int>, or [Int]. They mean the same thing, but one does not have the generic syntax. If we can do similar stuff with things like mutexes and syncing, then it will go a long way towards highly performant, safe, code.
- skohan 4y ago
  It's interesting that you choose Swift as an example, because I think in some ways Swift does a poor job of accommodating async using the "bubble wrap" approach. Specifically I am talking about the default of using atomic reference counting on all references. This makes it somewhat idiot proof at least with respect to avoiding NPE's, but it comes at a huge performance cost (especially on x86 which I guess is becoming less of a concern for Swift code). I think this is a fundamental issue: a big part of the benefit of concurrency and parallelism is supposed to be increased performance. However a lot of the ways to make concurrency "generally safe" tend to hamstring performance, because you have to protect against all the different types od errors programmers can make, which basically means a lot of expensive synchronization. Maybe there is a way to hide this completely, as you say, in a performant way. To do this, I think you would almost have to have either some kind of really clever risk-free data structures, or else a very smart compiler. Another approach might be to keep concurrency at arms length from the average programmer. I.e. hide 90% of it inside of libraries, and expose safe interfaces which the programmer interacts with in a mostly synchronous way.
  - ChrisMarshallNY 4y ago
    > I think in some ways Swift does a poor job of accommodating async using the "bubble wrap" approach. I agree. Async/await has a "kludgy" feel to it (to me). It's "added on," not "embedded in." But I'm not a language writer, so I don't have alternatives to offer. I was talking about how it does generics. I think it does that quite well.
    - skohan 4y ago
      I agree with you there. Swift has some really excellent syntactic sugar.
    - dgb23 4y ago
      To me it feels like I’m folding and knotting code.
  - samsquire 4y ago
    I agree that compilers and schedulers should be enforcing partial orders of concurrency. I talk of various multiversion concurrency control ideas in my ideas4 page. As an example I think Thread yield should take an argument for a matching data structure that when the state of that data structure changes you trigger rescheduling at that point and avoid a busy wait. HTTPS://GitHub.com/samsquire/ideas4
- samsquire 4y ago
  The problem with async/await is that it doesn't use threads and is rewritten to a state machine. It's not parallel C# and Python async await and definitely JavaScript don't run asynchronous code in parallel. IO is in parallel but computation is not.
hinkley 4y ago
Based on a non-scientific study, I think the spatial thinkers do great with concurrency, the visual thinkers do okay, and everyone else is in real trouble. Which reminds me, I need to interview my developer friend with aphantasia about how he feels about concurrency. Concurrency should be the sizzle and not the steak, otherwise you're reducing the diversity of your team rather substantially. Good people are hard enough to find. Driving the people you have away doesn't generally end well.
- deleted 4y ago
  [deleted]
- toast0 4y ago
  I wouldn't say I have aphantasia, but I don't know that I think of computers in a visual way, although kind of maybe. I'm not great at writing concurrent code with locks and shared memory (messaging passing is much easier for me to do well; but message passing is almost exclusively built upon locks and shared memory, so my hands are forced). But I'm pretty good at debugging concurrency problems of either type. It's all about thinking about the sequence of events of an individual thread of execution and not making assumptions that things would necessarily stay the same between steps... and then trying to line up how another thread could make those things happen. I don't line the threads up visually, but I guess you could?

by skohan 4y ago

ChrisMarshallNY 4y ago

FP is good for adapting to threading, but it has difficulties, when applied to things like GUI programming, async communications, or device control (places that need threading). A lot of languages are getting things like async/await/actor, etc., but even that is still too low-level for a lot of programmers. It can easily turn into a lot of single-threaded code. It needs to be completely under the surface. Swift does that with generics (I suspect other languages do it, as well). For example, you can say Array<Int>, or [Int]. They mean the same thing, but one does not have the generic syntax. If we can do similar stuff with things like mutexes and syncing, then it will go a long way towards highly performant, safe, code.

skohan 4y ago
It's interesting that you choose Swift as an example, because I think in some ways Swift does a poor job of accommodating async using the "bubble wrap" approach. Specifically I am talking about the default of using atomic reference counting on all references. This makes it somewhat idiot proof at least with respect to avoiding NPE's, but it comes at a huge performance cost (especially on x86 which I guess is becoming less of a concern for Swift code). I think this is a fundamental issue: a big part of the benefit of concurrency and parallelism is supposed to be increased performance. However a lot of the ways to make concurrency "generally safe" tend to hamstring performance, because you have to protect against all the different types od errors programmers can make, which basically means a lot of expensive synchronization. Maybe there is a way to hide this completely, as you say, in a performant way. To do this, I think you would almost have to have either some kind of really clever risk-free data structures, or else a very smart compiler. Another approach might be to keep concurrency at arms length from the average programmer. I.e. hide 90% of it inside of libraries, and expose safe interfaces which the programmer interacts with in a mostly synchronous way.
- ChrisMarshallNY 4y ago
  > I think in some ways Swift does a poor job of accommodating async using the "bubble wrap" approach. I agree. Async/await has a "kludgy" feel to it (to me). It's "added on," not "embedded in." But I'm not a language writer, so I don't have alternatives to offer. I was talking about how it does generics. I think it does that quite well.
  - skohan 4y ago
    I agree with you there. Swift has some really excellent syntactic sugar.
  - dgb23 4y ago
    To me it feels like I’m folding and knotting code.
- samsquire 4y ago
  I agree that compilers and schedulers should be enforcing partial orders of concurrency. I talk of various multiversion concurrency control ideas in my ideas4 page. As an example I think Thread yield should take an argument for a matching data structure that when the state of that data structure changes you trigger rescheduling at that point and avoid a busy wait. HTTPS://GitHub.com/samsquire/ideas4
samsquire 4y ago
The problem with async/await is that it doesn't use threads and is rewritten to a state machine. It's not parallel C# and Python async await and definitely JavaScript don't run asynchronous code in parallel. IO is in parallel but computation is not.

hinkley 4y ago

Based on a non-scientific study, I think the spatial thinkers do great with concurrency, the visual thinkers do okay, and everyone else is in real trouble. Which reminds me, I need to interview my developer friend with aphantasia about how he feels about concurrency. Concurrency should be the sizzle and not the steak, otherwise you're reducing the diversity of your team rather substantially. Good people are hard enough to find. Driving the people you have away doesn't generally end well.

deleted 4y ago
[deleted]
toast0 4y ago
I wouldn't say I have aphantasia, but I don't know that I think of computers in a visual way, although kind of maybe. I'm not great at writing concurrent code with locks and shared memory (messaging passing is much easier for me to do well; but message passing is almost exclusively built upon locks and shared memory, so my hands are forced). But I'm pretty good at debugging concurrency problems of either type. It's all about thinking about the sequence of events of an individual thread of execution and not making assumptions that things would necessarily stay the same between steps... and then trying to line up how another thread could make those things happen. I don't line the threads up visually, but I guess you could?