Hi, i'm have a query about thread-safe in extension. Example, in SFSTrisGame, class MoveHandler handles each turn request from user, but i don't see any lock or synchronize in the processing. After check some condition such as gameExt.isGameStarted(), gameExt.getWhoseTurn()... , and then update logic game gameExt.increaseMoveCount(), gameExt.updateTurn()... I mean showhow(by hack or something like that) client can request simultaneously this move action, and logic on server is incorrect. Finally, in logic game such as TrisGame, is it need lock in methods gameExt.increaseMoveCount(), gameExt.updateTurn() or SFS has taken care it...
Thanks.
About thead-safe in logic game extension
The general rule is that code in an Extension must be thread safe. This is because, for example, the thread firing the server events is not the same as the one handling the client requests.
By using concurrent collections you can easily solve many of the basic synchronization issues, and depending on what your game does you might need to use locks or synchronized blocks to ensure thread safety where appropriate.
As regards the Tris game, we didn't think of all possibilities but I would say that the code there is thread safe unless someone attempts to hack it... and I am not even sure it is possible.
The fact we don't lock on the increaseMoveCount() method is due to the fact that the game is turned based and there are checks on who is entitled to make a move so there's no way that one can bypass that validation and attempt to break the server code.
Of course in a "more concurrent" situation you should at least use the volatile modifier or replace that with an AtomicInteger.
hope it helps
By using concurrent collections you can easily solve many of the basic synchronization issues, and depending on what your game does you might need to use locks or synchronized blocks to ensure thread safety where appropriate.
As regards the Tris game, we didn't think of all possibilities but I would say that the code there is thread safe unless someone attempts to hack it... and I am not even sure it is possible.
The fact we don't lock on the increaseMoveCount() method is due to the fact that the game is turned based and there are checks on who is entitled to make a move so there's no way that one can bypass that validation and attempt to break the server code.
Of course in a "more concurrent" situation you should at least use the volatile modifier or replace that with an AtomicInteger.
hope it helps