I'm coding in C++. I have a server that will have clients connect to it, and each client gets spun off into its own thread for communication. This server is hosting a game, so there is information that must be shared between all client threads, as well as any other threads I choose to spawn off. This data is like level data, players online, etc, so all threads might possible have to access any of the data at any time. When I was doing this in C#, I just had a static static with all static fields. Is there a superior way to do this? I really don't want to have to deal with passing a reference to a specific object everywhere, but I figure my current implementation goes against OOP etc. Would this be a good case for using a singleton design pattern? Any other ideas are welcomed!

  • 2
    Spinning each client off into a thread scales poorly. The central repository is usually called the model, and each client's view of it is a...view (with a controller to deal with input from the user that might affect the data in the model). Commented Apr 16, 2012 at 20:38
  • 1
    What is an alternative method for the communication, to get information, then determine who it is and go from there?
    – will
    Commented Apr 16, 2012 at 20:42
  • usually a thread pool, where you have tasks to execute, and threads to execute them, but any thread can run any task (and put it back into the process pool when it doesn't need immediate attention). Commented Apr 16, 2012 at 20:46
  • 1
    Can this data just be stored in a database?
    – Doug T.
    Commented Apr 16, 2012 at 21:47
  • well, I imagine that would take more time than having it accessible in memory. I'm liking the Inversion of Control design pattern a lot from gbjbaanb
    – will
    Commented Apr 17, 2012 at 2:04

4 Answers 4


3 main ways of doing this:

  1. Use a global static object, its gets constructed at startup and can be a good pattern as it is very simple. Simple can often = good.

  2. Use a singleton. You now have the object created later, and its still a single object. you fetch this object as needed. This is a "step-up" as you have more control about initialisation of the object compared to the global.

  3. Use an 'Inversion of Control' object. This is basically passing the object into each class in the constructor, so each object has its private member pointer to the object. This is another step-up as it allows much easier access to the 'global', and also allows you to switch the injected object on a class by class basis.

Ultimately it depends, the IoC pattern is very fashionable at the moment, but I tend to prefer the global TBH. It depends as well what data you're putting into it, and if its a read-only or a read-write object.

  • 2. not only allows for finer control of initialization but also access (it can be made thread safe, unlike a global variable). 3. also allows to switch the injected object per instance, not only per class. Commented Apr 17, 2012 at 6:13
  • yes, the latter piece is as you say: you can pass a different config class in to each instance of your application object. A global object can be just as thread safe as a singleton though.
    – gbjbaanb
    Commented Apr 17, 2012 at 14:57

I really don't want to have to deal with passing a reference to a specific object everywhere

Why not? Is passing a single reference so much effort? You'll kick yourself tomorrow when you use a global variable just because you were too lazy today to implement it properly.

Just send the reference and get it done.


each client gets spun off into its own thread for communication

Not a fan of Boost.Asio?

there is information that must be shared between all client threads

Sounds like you just want a giant global table that any client instance (whether a thread or an Asio implementation) can read and write.

  • Not so much -not a fan-, just never heard of it. It looks very interesting, and a lot better than burning time re-inventing the wheel :D
    – will
    Commented Apr 17, 2012 at 3:19

There are a couple of other options not mentioned yet:-

Shared memory. Use the POSIX Interprocess Communication and Shared Memory APIs to allocate and control a piece of shared memory. The advantage is that you can now share the data between processes which will scale well within a single machine.

Use a mini server process, which can be accessed via the technology of your choice (RPC, CORBA, plain TCP/IP sockets). This will scale well over multiple machines, but, you need to write a fairly complex API to manage updates etc.

Use a database. Sounds like overkill but this is exactly what database management systems were written for. This scales up to almost Facebook/Amazon size provided you are careful with your SQL, and, you don't need to write much code to implement this.

  • sometimes known as the blackboard design pattern, the problem is that these will scale better but will also perform much worse if you don't need the scalability.
    – gbjbaanb
    Commented Apr 17, 2012 at 15:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.