4 ms·

Because as a programmer I have responsibility for the technical soundness of the program, and I don't create threads haphazardly. > when i thought i understood

Because as a programmer I have responsibility for the technical soundness of the program, and I don't create threads haphazardly. > when i thought i understood multi-threaded code, but didn't. All the more reason to carefully plan and limit shared state among threads. It's hard enough to get right when you know where the problems are and impossible if you spray and pray with mutexes.

catlifeonmars 2y ago
Yeah but just because you do the right thing doesn’t mean that others will. That one person that creates threads haphazardly will wreak havoc and at scale this will happen. It’s an unstable equilibrium to put the onus of program soundness on the contributors to a program.
- grandempire 2y ago
  > That one person that creates threads haphazardly will wreak havoc What if someone comes along and starts adding threads and doesn't check what they are accessing? And doesn't read the documented invariants of the design? Well I don't think any project can succeed if that's the level disorganization. Are there certain kinds of bugs that are easy to regress last minute? Yes. A brand new thread without limited state is not one of them. > put the onus of program soundness on the contributors to a program. Who then is responsible for making sure the program is correct?
  - catlifeonmars 2y ago
    > Who then is responsible for making sure the program is correct? I’d say this is mostly a function of the language or framework. After that, it’s up to the tech leads to provide access patterns/examples that align with the needs of a particular project. My point is not so much that you shouldn’t ever think about the implications of your code, just that contributors are humans and any project with enough contributors will have a mix of contributors with different knowledge, experience and skill sets. If you are leading one of those, it would behoove you to make doing the right thing easy for later contributors.
    - grandempire 2y ago
      > I’d say this is mostly a function of the language or framework. frameworks cannot ensure your program does what it's supposed to. People are responsible, not tools. > contributors are humans Yes - which is why I would discourage haphazard thread usage, and document existing thread architecture. That's safer than "hey I threw on a mutex because who knows where this is accessed from".

catlifeonmars 2y ago

Yeah but just because you do the right thing doesn’t mean that others will. That one person that creates threads haphazardly will wreak havoc and at scale this will happen. It’s an unstable equilibrium to put the onus of program soundness on the contributors to a program.

grandempire 2y ago
> That one person that creates threads haphazardly will wreak havoc What if someone comes along and starts adding threads and doesn't check what they are accessing? And doesn't read the documented invariants of the design? Well I don't think any project can succeed if that's the level disorganization. Are there certain kinds of bugs that are easy to regress last minute? Yes. A brand new thread without limited state is not one of them. > put the onus of program soundness on the contributors to a program. Who then is responsible for making sure the program is correct?
- catlifeonmars 2y ago
  > Who then is responsible for making sure the program is correct? I’d say this is mostly a function of the language or framework. After that, it’s up to the tech leads to provide access patterns/examples that align with the needs of a particular project. My point is not so much that you shouldn’t ever think about the implications of your code, just that contributors are humans and any project with enough contributors will have a mix of contributors with different knowledge, experience and skill sets. If you are leading one of those, it would behoove you to make doing the right thing easy for later contributors.
  - grandempire 2y ago
    > I’d say this is mostly a function of the language or framework. frameworks cannot ensure your program does what it's supposed to. People are responsible, not tools. > contributors are humans Yes - which is why I would discourage haphazard thread usage, and document existing thread architecture. That's safer than "hey I threw on a mutex because who knows where this is accessed from".