Please no.
Singletons if you must. At least you can wrap a mutex around access if you're trying to make it thread safe.
Singletons if you must. At least you can wrap a mutex around access if you're trying to make it thread safe.
> wrap a mutex
What if my program has one thread? Or the threads have clearly defined responsibilities?
The conclusion of your argument looks like 2000s Java - throw a mutex on every property because you never know when it will need to be accessed on a thread.
Designs that spread complexity rather than encapsulate it are rarely a good idea.
If you don’t care about performance and want safety you should be using processes. Explicit shared memory is safer than implicit.
and yes. Better thread management tools are always welcome when we can get them.
Exactly, globals spread complexity.
You need to look at the implementation of each function to know if you can call it. That’s the landmine.
Singleton is a pattern to ensure that a global objects is only ever initialized once.
But singletons are still a terrible idea. The issue with global variables is not just initialization. I would argue it's one of the more minor issues.
The major issues with global variables are:
1. Action at distance (if the variable is mutable)
2. Tight coupling (global dependencies are hard-coded, you cannot use dependency injection)
3. Hidden dependency. The dependency is not only tightly-coupled, it is also hidden from the interface. Client code that calls your function doesn't know that you rely on a global variable and that you can run into conflict with other code using that variable or that you may suddenly start accessing some database it didn't even know about.
Singleton does not solve any of the above. The only thing it ensures is lazy initialization on access.
> 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.
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?
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.
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".