Re: SYNCHRONIZING problem
adrian.bartholomew@gmail.com wrote:
ok i cant take it anymore. i need help!
let me describe my java solution as best i could pertaining to my
problem.
it is a card game. u know, server app as the brain and fancy gui for
the applet clients that u surf via "cardgame.com" for eg.
now....
the server side of things basically consists of a "ConnectionListener"
that listens for clients wanting to play (connect to the table). each
time it detects someone trying to connect, it spins of a
"PlayListener" thread who's main purpose is to listen to that client's
"plays".
so lets say we have 4 people playing the game, we have 1
ConnectionListener and 4 PlayListeners.
thats 5 threads.
all the methods of play reside in the main program CardGameServer.
dealCards(), playCard(), shuffleAnimation(), cutPack() etc.
now i like animation. a lot. u know, like a card shuffle animation or
the cards coming off the table 1 by 1 after a round of play.
this, i achieved by having the CardGameServer implement Runnable. in
the run() method there are many if(flag) clauses that,
if( flag==true), a particular animation is run. for eg.
Wouldn't it be better to handle animation in the client applet?
[scissor happy]
so when i want an animation performed, i simply switch one of these
flags to true.
when it enters, say, cutAnim(), the 1st line of code in cutAnim()
switches the flag back to false so theres no possibility of falsely re-
entering the animation.
the run routine is in an endless while(true) loop, forever searching
for "true" flags or robot plays.
if there is a better way of performing these animations without using
up valuable thread processing time, pleeeease let me know. i cant
imagine a 100 instances of the gameserver all continuously looping.
anyway, onward.
i have also created AI robots that u can assign to the table instead
of waiting indefinitely for human players to log in.
when its their turn to play, the endless run loop simply checks to see
if the player whose "currTurn" it is, is not human
(getPlayer(......currTurn).robot!=null and a host of other checks like
gameStage etc. once these meet the criteria, it goes into the AI code
to find the best play and does it.
the difference is, the AI's play is instigated from the thread
commanding the run() method of the CardGameServer class.
whereas the human's play is instigated from the playListener Class
which calls methods residing in the CardGameServer class.
the problem for me arises when i try to put a lock on the animation.
if i dont, sometimes it gets corrupted and the animation goes awry. in
the past (b4 i learned about the synchronized keyword), i suspend
either the playListener thread or the server thread, afterward
resuming. it worked fine except under a particular circumstance, if
the human did the shuffling and a robot cut the pack, the human would
hang when trying to make a play (maybe deadlock?).
added to the fact that these keywords are now defunct, i opted for a
cleaner design using synchronized.
ive tried adding wait() and notifyAll() but nothing works. either the
human hangs ot the robot hangs.
i need the animations to complete without any interference from a
human command coming in.
but i also need the damn thing to work. from start to finish no matter
what ratio of humans to robots are on the table
help.
I can't take it anymore, either. Usenet is not a text message
repository, nor is it a chat room. Therefore, take pains to write proper
English. Also, please try not to speak in slang (i.e., do not put "u
know" every few sentences).
It sounds as if your basic problem is that you're handling animation on
the server side. If so, then simple message passing between
client/server while forcing the client to handle the animation is much
simpler. This design would also ease the robot problem by allowing you
to spawn the custom "robot" client through Process, etc.