3 ms·

>shared mutability Sure but this goes against "Don't communicate by sharing memory", no?

by konart 5y ago

scottlamb 5y ago
> Sure but this goes against "Don't communicate by sharing memory", no? Yes, but that's advice rather than something Go requires. It's reasonable to say it's outweighed by the desire to avoid significantly restructuring the existing logic. The author is explicitly choosing to match the upstream program's structure to limit the project scope, and whether that structure is good or not is almost besides the point. btw: especially in the Rust community, shared mutability doesn't always mean shared between threads/tasks. It's also a concern in single-threaded/non-concurrent code due to aliasing. This case does actually seem to be involving multithreading given that the author mentioned "using 8 threads".
- newlisp 5y ago
  Curious, can you elaborate on what are the issues of mutability in single-threaded code?
  - scottlamb 5y ago
    It comes down to how a language construct allocates freedom to the programmer vs the optimizing compiler. * Rust references are strict. &mut references guarantee that nothing else can access the backing memory while the &mut is valid. & references guarantee that nothing (including &mut by the rule above, or unsafe code with raw pointers by programmer's pinkie swear) can change the backing memory while the &mut is valid. This allows the compiler to perform more optimizations behind the scene, like assuming a value loaded into a register is still up-to-date, even if there's been a function call between. * Rust raw pointers make no guarantees (but require the programmer to type "unsafe" to use). * C pointers are IMHO weirder. iirc, two pointers of the same type may alias (unless you use the rare "restrict" keyword), but two pointers of different type can't, unless one is "char*". * AFAIK, Go pointers are at least as permissive as C's. They might not make any aliasing guarantees at all. * Other languages vary...
  - steveklabnik 5y ago
    https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ https://manishearth.github.io/blog/2015/05/17/the-problem-wi...

>shared mutability Sure but this goes against "Don't communicate by sharing memory", no?

by konart 5y ago

>shared mutability Sure but this goes against "Don't communicate by sharing memory", no?

> Sure but this goes against "Don't communicate by sharing memory", no? Yes, but that's advice rather than something Go requires. It's reasonable to say it's outweighed by the desire to avoid significantly restructuring the existing logic. The author is explicitly choosing to match the upstream program's structure to limit the project scope, and whether that structure is good or not is almost besides the point. btw: especially in the Rust community, shared mutability doesn't always mean shared between threads/tasks. It's also a concern in single-threaded/non-concurrent code due to aliasing. This case does actually seem to be involving multithreading given that the author mentioned "using 8 threads".

newlisp 5y ago
Curious, can you elaborate on what are the issues of mutability in single-threaded code?
- scottlamb 5y ago
  It comes down to how a language construct allocates freedom to the programmer vs the optimizing compiler. * Rust references are strict. &mut references guarantee that nothing else can access the backing memory while the &mut is valid. & references guarantee that nothing (including &mut by the rule above, or unsafe code with raw pointers by programmer's pinkie swear) can change the backing memory while the &mut is valid. This allows the compiler to perform more optimizations behind the scene, like assuming a value loaded into a register is still up-to-date, even if there's been a function call between. * Rust raw pointers make no guarantees (but require the programmer to type "unsafe" to use). * C pointers are IMHO weirder. iirc, two pointers of the same type may alias (unless you use the rare "restrict" keyword), but two pointers of different type can't, unless one is "char*". * AFAIK, Go pointers are at least as permissive as C's. They might not make any aliasing guarantees at all. * Other languages vary...
- steveklabnik 5y ago
  https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ https://manishearth.github.io/blog/2015/05/17/the-problem-wi...