Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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!

share|improve this question
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). –  Jerry Coffin Apr 16 '12 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 Apr 16 '12 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). –  Jerry Coffin Apr 16 '12 at 20:46
1  
Can this data just be stored in a database? –  Doug T. Apr 16 '12 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 Apr 17 '12 at 2:04

4 Answers 4

up vote 2 down vote accepted

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.

share|improve this answer
    
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. –  Tamás Szelei Apr 17 '12 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 Apr 17 '12 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.

share|improve this answer

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.

share|improve this answer
    
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 Apr 17 '12 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.

share|improve this answer
    
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 Apr 17 '12 at 15:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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