3 ms·

What is a "correct synchronization"?

by f_gergo 3y ago

kccqzy 3y ago
Synchronization such as the whole program is well-defined according to some memory model.
- Thaxll 3y ago
  Which is the case for Go: https://go.dev/ref/mem https://go.dev/ref/mem
  - kccqzy 3y ago
    A quote from your link: > programmers are strongly encouraged to use appropriate synchronization to avoid data races Any time you need to "encourage" programmers to do the right thing, you have already failed in your language design. And I think OP agrees with me here. OP says "static checking of correct synchronization" which is irresponsibly absent from Go.
    - Thaxll 3y ago
      So it's absent from every language but Rust?
      - sapiogram 3y ago
        Javascript is even better, by not having multithreading at all. I am not joking, Go is much worse than Java and C#, but Javascript and Rust are the only mainstream languages where I've seen non-experts reliably write correct concurrent code. Maybe it's true for langauges like Elixir as well, but I haven't tried.
        pdimitar 3y ago
        It's 95% true for Elixir as well; it's very difficult to mess up parallelization or just leave a system in an incoherent state with it. Immutability and message passing help a lot.
        masklinn 3y ago
        My experience of JavaScript is nowhere near that good. While it does not have parallelism, the concurrency is as unrestricted as it is in go, forgetting awaits is a very common issue leading to wild tasks running unbounded and unchecked, and when you need any other synchronisation mechanism you have to write them yourself and they’re tricky indeed. $dayjob’s JS team keeps chasing concurrency issues, and breaking builds because of them.
      - kccqzy 3y ago
        Alternatively a language can choose not to expose anything low level enough to cause synchronization issues and only make available high level APIs that are correct by construction. Go does neither. That's why there's this thread on HN that I bookmarked: https://news.ycombinator.com/item?id=31698503 https://news.ycombinator.com/item?id=31698503
      - hedora 3y ago
        I don't know of any other multithreaded systems programming languages that check for data race freedom at compile time. Single threaded languages are usually data race free. I imagine some multithreaded, purely functional languages are too (everything is immutable, and therefore cannot be modified in race with reads). Of course, SQL running in strictly serializable mode is too. Of those, the only one of those that's an appropriate choice for systems software development is Rust. The Core C++ Guidelines are a runner up in my opinion: They dictate a subset of C++ that is safer, with the goal of backporting the Rust memory safety properties to C++. Swift has also done a lot in this space.

What is a "correct synchronization"?

kccqzy 3y ago

Synchronization such as the whole program is well-defined according to some memory model.

Thaxll 3y ago
Which is the case for Go: https://go.dev/ref/mem https://go.dev/ref/mem
- kccqzy 3y ago
  A quote from your link: > programmers are strongly encouraged to use appropriate synchronization to avoid data races Any time you need to "encourage" programmers to do the right thing, you have already failed in your language design. And I think OP agrees with me here. OP says "static checking of correct synchronization" which is irresponsibly absent from Go.
  - Thaxll 3y ago
    So it's absent from every language but Rust?
    - sapiogram 3y ago
      Javascript is even better, by not having multithreading at all. I am not joking, Go is much worse than Java and C#, but Javascript and Rust are the only mainstream languages where I've seen non-experts reliably write correct concurrent code. Maybe it's true for langauges like Elixir as well, but I haven't tried.
      - pdimitar 3y ago
        It's 95% true for Elixir as well; it's very difficult to mess up parallelization or just leave a system in an incoherent state with it. Immutability and message passing help a lot.
      - masklinn 3y ago
        My experience of JavaScript is nowhere near that good. While it does not have parallelism, the concurrency is as unrestricted as it is in go, forgetting awaits is a very common issue leading to wild tasks running unbounded and unchecked, and when you need any other synchronisation mechanism you have to write them yourself and they’re tricky indeed. $dayjob’s JS team keeps chasing concurrency issues, and breaking builds because of them.
    - kccqzy 3y ago
      Alternatively a language can choose not to expose anything low level enough to cause synchronization issues and only make available high level APIs that are correct by construction. Go does neither. That's why there's this thread on HN that I bookmarked: https://news.ycombinator.com/item?id=31698503 https://news.ycombinator.com/item?id=31698503
    - hedora 3y ago
      I don't know of any other multithreaded systems programming languages that check for data race freedom at compile time. Single threaded languages are usually data race free. I imagine some multithreaded, purely functional languages are too (everything is immutable, and therefore cannot be modified in race with reads). Of course, SQL running in strictly serializable mode is too. Of those, the only one of those that's an appropriate choice for systems software development is Rust. The Core C++ Guidelines are a runner up in my opinion: They dictate a subset of C++ that is safer, with the goal of backporting the Rust memory safety properties to C++. Swift has also done a lot in this space.