6 ms·

Please no. Singletons if you must. At least you can wrap a mutex around access if you're trying to make it thread safe.

• bknight1983 2y ago
  For every example of a bug caused by not using a global variable I’m sure could find 10 caused by a global variable
• grandempire 2y ago
  Why are singletons better? That's just a global object. > wrap a mutex What if my program has one thread? Or the threads have clearly defined responsibilities?
  • rileymat2 2y ago
    You know it is /currently/ accessed on one thread. These are little landmines that add up over time.
    • grandempire 2y ago
      The burden is on the programmer adding a new thread to know what they can safely access. 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.
      • catlifeonmars 2y ago
        That’s sounds more like a weakness of the language: that preventing data races is not automatically tracked for you, no?
        • liontwist 2y ago
          If you care about performance, many locks across many pieces of shared state is always a bad 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.
      • rileymat2 2y ago
        > Designs that spread complexity rather than encapsulate it are rarely a good idea. 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.
        • grandempire 2y ago
          I agree that dependent sequences of events, coordinated through a global are bad. But there are other usages which are not error prone. For example an allocation, logger, readonly settings, or a cache.
  • dragontamer 2y ago
    Global objects need to be initialized. And if two are ever initialized you run into problems like the above. Singleton is a pattern to ensure that a global objects is only ever initialized once.
    • unscaled 2y ago
      Most programming languages written after 1990 let you initialize global variables lazily. The main problem is that the initialization order might be unexpected or you may run into conflicts. Singletons make the order slightly more predictable (based on first variable access), although it is till implicit (lazy). 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.
  • zabzonk 2y ago
    how do you know that? just about every serious bug i have ever written was when i thought i understood multi-threaded code, but didn't.
    • grandempire 2y ago
      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.
  • bb88 2y ago
    In complex systems trying to hunt down intractable bugs on global variables is a terrible developer experience. I've done it before.
• levodelellis 2y ago
  You may hate my article next week, it's meant to replace this article. If you want you can email me for early access and tell me how I can improve the article. Lets say you can guess my email if you're emailing the right domain
• mrkeen 2y ago
  You say "thread safe", I say "dead lock".