Top Mud Sites Forum - View Single Post - Event-based with threads instead of game loop

Viriato · 11-17-2012, 07:35 AM

In Java there are static and synchronized methods

For instance, about entering and leaving rooms, the core method is static and synchronized meaning that noone really moves at the same time. Also, some actions are done by iterating collections - an operation that can also be synchronized.

This may or may not cover all troubling situations, but how I idealized each of my systems there is no need for extra cautions (that I can think of).

Example: if someone says something in a room, it iterates the synchronized list of all players and NPC there. If in middle of that command one wants to leave the room, it will try to make a parallel remove in such list. As both operations are inside of a "synchronized" block in both threads, only when the first block ends the second will perform. With this logic, there won't exist inconsistencies that I can think of.

Of course one can say that this synchronization is inneficient. You can gain extra ms if you make your own semaphores... But I am 99% sure it is scalable enough for current avg mud players and current computer components

Ignoring some overheads, a threaded engine in the worst case will behave as non threaded. Plus the benefits of having threads controlling each system, debugging, and isolating errors.

11-17-2012, 07:35 AM	#11
Viriato New Member Join Date: Jul 2007 Location: Lisbon, Portugal Home MUD: Iberia MUD Posts: 22	Re: Event-based with threads instead of game loop In Java there are static and synchronized methods For instance, about entering and leaving rooms, the core method is static and synchronized meaning that noone really moves at the same time. Also, some actions are done by iterating collections - an operation that can also be synchronized. This may or may not cover all troubling situations, but how I idealized each of my systems there is no need for extra cautions (that I can think of). Example: if someone says something in a room, it iterates the synchronized list of all players and NPC there. If in middle of that command one wants to leave the room, it will try to make a parallel remove in such list. As both operations are inside of a "synchronized" block in both threads, only when the first block ends the second will perform. With this logic, there won't exist inconsistencies that I can think of. Of course one can say that this synchronization is inneficient. You can gain extra ms if you make your own semaphores... But I am 99% sure it is scalable enough for current avg mud players and current computer components Ignoring some overheads, a threaded engine in the worst case will behave as non threaded. Plus the benefits of having threads controlling each system, debugging, and isolating errors.