Hello everyone. I'm currently using IOCP with threads to handle both networking and message processing. Since I do not have a fixed main loop I'm creating a thread whenever I need some system updated periodically.

Due to that, I'm using locks to synchronize entirety of the shared data(which is the majority of the data since it's a game server). Though, I've been told, this could result in a slower overall performance than a single threaded application and a higher chance of ending up with deadlocks.

I would like to get rid of majority of these locks by changing my message processing and game updating design. I'm not experienced enough to know possible message processing/game loop designs which lead me to creating this kind of awful system in the first place. That is why I would very much appreciate if someone could explain me how it's done in industry.

Tasks which the server is responsible with(Pretty much what any MMORPG server would need to do):

- Keeping track of players surroundings and updating them properly(Currently using a fixed node system and a thread for updating.)

- Handling user specific data(Such as items, skills, etc.)

- Combat systems(Casting skills, normal attacks, etc.)

- Handling global data(Guilds, auction, etc.)

- Other small/big systems such as trading, party, other MMORPG elements.

Thanks for the answers.

I'm creating a thread whenever I need some system updated periodically.

Separately, do you actually need multiple threads?
Have you written a networked game before?
Did it run out of CPU in a single thread?
If so, where did the profiler say that you were spending your time?

- That's something which I didn't ask myself when I started writing my server. Should have.

- Not necessarily. This was initially way out of my league, though, I've been working on it for a considerably long time and learnt a lot along the way.

- Again, it's always been multi-threaded.

One of the recent thoughts I had was using IOCP threads only for networking and using a single consumer work queue for all other jobs. Then I could create new single consumer queues for tasks which can be run independantly, if it seemed necessary.

That is independant groupings of processings like network processing(client sessions) and decoding inbound commands, actioning and arbitrating game mechanics events, outbound data to clients, etc... With the 'turns' pipelining (internet delays mean the game probably can be processed in steps without affecting perceived timing). When each thread finishes wuth its turn data (and is waiting for its next turn to start) it might do some secondary less time dependant tasks as filler...

I do like the idea very much, though, it might be too difficult to group the systems I have since they often require information from other systems during processing.

Tasks which the server is responsible with(Pretty much what any MMORPG server would need to do):
- Keeping track of players surroundings and updating them properly(Currently using a fixed node system and a thread for updating.)
- Handling user specific data(Such as items, skills, etc.)
- Combat systems(Casting skills, normal attacks, etc.)
- Handling global data(Guilds, auction, etc.)
- Other small/big systems such as trading, party, other MMORPG elements.

Thanks for the answer. I couldn't agree more. Having whole game logic run in multiple threads is adding nothing but complication due to synchronization at the moment.

What I like to push out to other threads (or processes, preferably) are network reads/writes and buffer handling (if necessary - the OS covers a lot of this for you automatically), and AI (eg. A* pathfinding, influence map updates, decision making). But even AI is tricky to manage since it usually needs to read the world and character state. One way I've dealt with this is for state changes to all be done by update messages, meaning the AI thread/process can have its own copy of the world state based on the messages it receives. But it does require handling your game updates in a careful way, one that doesn't fit well with the traditional "anything can modify anything" approach most games still use.

I'm still using IOCP threads for networking. Which includes receiving/sending/deserializing network data.I will first adjust my game systems to single threaded update approach. Then if it appears to be a performance issue, will try to implement solutions which you guys suggested.