4 ms·

> Confused concurrency. I’m not sure I know what you mean by that. > If you take a certain view on concurrency, which is "do it as simply as possible, don't b

> Confused concurrency. I’m not sure I know what you mean by that. > If you take a certain view on concurrency, which is "do it as simply as possible, don't break certain rules, don't try to be too clever," Is there a list of those rules?

klodolph 6y ago
> Is there a list of those rules? Several different lists. You have to pick a concurrency model. Within that concurrency model, you pick some set of rules to follow which has the guarantees you want.
- chii 6y ago
  so how do you know which model to use? How do you know what rules guarentee what outcome? How do you compare them against each other? All of those things mentioned in the original reply is vague, and can only come from having experience in the subject matter. That's why concurrency is hard.
  - klodolph 6y ago
    > so how do you know which model to use? That's like asking, "How do you know what algorithm to use?" You can come up with a justification for why a particular algorithm may be suitable for your purposes, but you'd be hard-pressed to explain how you go about choosing an algorithm. It's the same way with rules for a codebase... you can justify why you are using a specific set of rules, but explaining the decision process that led you to choose those rules is much more difficult. That's why tech leads don't grow on trees. I'll add to what the original comment (about "confused concurrency") was saying, because it matches with my experiences. The good lead developers are the ones who are able to get the job done (design systems) and keep the concurrency model simple. It's often possible to keep concurrency mostly simple and mostly safe.
    - hedora 6y ago
      I worked on a large extremely high performance system (dozens of developers) that’s almost entirely lock free, and constantly mutates shared state. Concurrency issues weren’t really a big problem in that code base. Developers took a long time to ramp up, but that’s an OK tradeoff in my book. None of this would have been possible without lead developers that designed and continuously refined the guard rails that our internal “standard library” implemented. Oddly, I now find it easier to reason about lock free algorithms than mutex based code (and I wrote the latter for 15 years before working on the lock free system)
      - RcouF1uZ4gsC 6y ago
        >Oddly, I now find it easier to reason about lock free algorithms than mutex based code That is because lock free code composes. Mutex based code does not compose. With lock free code, I can freely call another function, knowing I cannot deadlock. With mutex based code, I have to be really careful about the state of my mutexes and think if the code I am calling will attempt to lock one of the mutexes I am holding, thereby causing a deadlock.
        jbn 6y ago
        lock-free code is free of deadlocks, but it is not free of livelocks and usually there's no guarantee of progress... In mutex-based code, usually you want only open calls (i.e. calls with no mutex held, so you only ever hold one mutex at a time).
        RcouF1uZ4gsC 6y ago
        > usually there's no guarantee of progress I think lock free guarantees that at least 1 thread will make progress. https://en.wikipedia.org/wiki/Non-blocking_algorithm#Lock-freedom https://en.wikipedia.org/wiki/Non-blocking_algorithm#Lock-fr...
        jbn 6y ago

klodolph 6y ago

> Is there a list of those rules? Several different lists. You have to pick a concurrency model. Within that concurrency model, you pick some set of rules to follow which has the guarantees you want.

chii 6y ago
so how do you know which model to use? How do you know what rules guarentee what outcome? How do you compare them against each other? All of those things mentioned in the original reply is vague, and can only come from having experience in the subject matter. That's why concurrency is hard.
- klodolph 6y ago
  > so how do you know which model to use? That's like asking, "How do you know what algorithm to use?" You can come up with a justification for why a particular algorithm may be suitable for your purposes, but you'd be hard-pressed to explain how you go about choosing an algorithm. It's the same way with rules for a codebase... you can justify why you are using a specific set of rules, but explaining the decision process that led you to choose those rules is much more difficult. That's why tech leads don't grow on trees. I'll add to what the original comment (about "confused concurrency") was saying, because it matches with my experiences. The good lead developers are the ones who are able to get the job done (design systems) and keep the concurrency model simple. It's often possible to keep concurrency mostly simple and mostly safe.
  - hedora 6y ago
    I worked on a large extremely high performance system (dozens of developers) that’s almost entirely lock free, and constantly mutates shared state. Concurrency issues weren’t really a big problem in that code base. Developers took a long time to ramp up, but that’s an OK tradeoff in my book. None of this would have been possible without lead developers that designed and continuously refined the guard rails that our internal “standard library” implemented. Oddly, I now find it easier to reason about lock free algorithms than mutex based code (and I wrote the latter for 15 years before working on the lock free system)
    - RcouF1uZ4gsC 6y ago
      >Oddly, I now find it easier to reason about lock free algorithms than mutex based code That is because lock free code composes. Mutex based code does not compose. With lock free code, I can freely call another function, knowing I cannot deadlock. With mutex based code, I have to be really careful about the state of my mutexes and think if the code I am calling will attempt to lock one of the mutexes I am holding, thereby causing a deadlock.
      - jbn 6y ago
        lock-free code is free of deadlocks, but it is not free of livelocks and usually there's no guarantee of progress... In mutex-based code, usually you want only open calls (i.e. calls with no mutex held, so you only ever hold one mutex at a time).
        RcouF1uZ4gsC 6y ago
        > usually there's no guarantee of progress I think lock free guarantees that at least 1 thread will make progress. https://en.wikipedia.org/wiki/Non-blocking_algorithm#Lock-freedom https://en.wikipedia.org/wiki/Non-blocking_algorithm#Lock-fr...
        jbn 6y ago