5 ms·

I am curious. Generally basic structures like map are not thread safe and care has to be taken while modifying it. This is pretty well documented in go spec. In

I am curious. Generally basic structures like map are not thread safe and care has to be taken while modifying it. This is pretty well documented in go spec. In your case in dropbox, what was essentially going on?

maxlybbert 1y ago
I thought the same thing. Maybe the point of the story isn’t “we were surprised to learn you had to synchronize access” but instead “we all thought we were careful, but each of us made this mistake no matter how careful we tried to be.”
nine_k 1y ago
In Java, there are separate synchronized collections, because acquiring a lock takes time. Normally one uses thread-unsafe collections. Java also gives a very ergonomic way to run any fragment under a lock (the `synchronized` operator). Rust avoids all this entirely, by using its type system.
- noisem4ker 1y ago
  Golang has a synchronized map: https://pkg.go.dev/sync#Map https://pkg.go.dev/sync#Map
- layer8 1y ago
  Java has separate synchronized collections only because that was initially the default, until people realized that it doesn’t help for the common cases of check-and-modify operations or of having consistency invariants with state outside a single collections (besides the performance impact). In practice, synchronized collections are rarely useful, and instead accesses are synchronized externally.
tsimionescu 1y ago
I think the surprise here is that failing to synchronize writes leads to a SEGFAULT, not a panic or an error. This is the point GP was making, that Go is not fully memory safe in the presence of unsynchronized concurrent writes. By contrast, in Java or C#, unsynchronized writes will either throw an exception (if you're lucky and they get detected) or let the program continue with some unexpected values (possibly ones that violate some invariants). Getting a SEGFAULT can only happen if you're explicitly using native code, raw memory access APIs, or found a bug in the runtime.
- elcritch 1y ago
  Segfault sounds better than running with inconsistent data.
  - qcnguy 1y ago
    Go/C programs that race can also run with inconsistent data. Nothing guarantees you a segfault under torn writes. In practice, Java programs tend to pick up on data races very quickly because they mutate some collection and the collections framework has safety checks for this.
  - foldr 1y ago
    The inconsistent data thing could happen in Go too. A segfault is not guaranteed, it’s just one of the more likely possibilities.
    - Someone 1y ago
      > A segfault is not guaranteed, it’s just one of the more likely possibilities. Is it? It will depend on the code, but my gut feeling is that you typically would get a few (if not lot of) unnoticed non-segfaulting issues before you get the segfaulting one that tells you straight in your face that you have a problem.
      - foldr 1y ago
        It probably depends on how exactly the corruption happens. If you overwrite a pointer with an integer value, then the integer is statistically unlikely to correspond to a valid memory address. On the other hand, if you overwrite a pointer with a pointer, or an integer with an integer, all bets are off.
        Someone 1y ago
        > If you overwrite a pointer with an integer value, then the integer is statistically unlikely to correspond to a valid memory address On 64-bit systems, and even then, it depends on the system’s memory layout (I think most integer values in programs are < 2³²)

maxlybbert 1y ago

I thought the same thing. Maybe the point of the story isn’t “we were surprised to learn you had to synchronize access” but instead “we all thought we were careful, but each of us made this mistake no matter how careful we tried to be.”

nine_k 1y ago

In Java, there are separate synchronized collections, because acquiring a lock takes time. Normally one uses thread-unsafe collections. Java also gives a very ergonomic way to run any fragment under a lock (the `synchronized` operator). Rust avoids all this entirely, by using its type system.

noisem4ker 1y ago
Golang has a synchronized map: https://pkg.go.dev/sync#Map https://pkg.go.dev/sync#Map
layer8 1y ago
Java has separate synchronized collections only because that was initially the default, until people realized that it doesn’t help for the common cases of check-and-modify operations or of having consistency invariants with state outside a single collections (besides the performance impact). In practice, synchronized collections are rarely useful, and instead accesses are synchronized externally.

tsimionescu 1y ago

I think the surprise here is that failing to synchronize writes leads to a SEGFAULT, not a panic or an error. This is the point GP was making, that Go is not fully memory safe in the presence of unsynchronized concurrent writes. By contrast, in Java or C#, unsynchronized writes will either throw an exception (if you're lucky and they get detected) or let the program continue with some unexpected values (possibly ones that violate some invariants). Getting a SEGFAULT can only happen if you're explicitly using native code, raw memory access APIs, or found a bug in the runtime.

elcritch 1y ago
Segfault sounds better than running with inconsistent data.
- qcnguy 1y ago
  Go/C programs that race can also run with inconsistent data. Nothing guarantees you a segfault under torn writes. In practice, Java programs tend to pick up on data races very quickly because they mutate some collection and the collections framework has safety checks for this.
- foldr 1y ago
  The inconsistent data thing could happen in Go too. A segfault is not guaranteed, it’s just one of the more likely possibilities.
  - Someone 1y ago
    > A segfault is not guaranteed, it’s just one of the more likely possibilities. Is it? It will depend on the code, but my gut feeling is that you typically would get a few (if not lot of) unnoticed non-segfaulting issues before you get the segfaulting one that tells you straight in your face that you have a problem.
    - foldr 1y ago
      It probably depends on how exactly the corruption happens. If you overwrite a pointer with an integer value, then the integer is statistically unlikely to correspond to a valid memory address. On the other hand, if you overwrite a pointer with a pointer, or an integer with an integer, all bets are off.
      - Someone 1y ago
        > If you overwrite a pointer with an integer value, then the integer is statistically unlikely to correspond to a valid memory address On 64-bit systems, and even then, it depends on the system’s memory layout (I think most integer values in programs are < 2³²)