I have experienced something similar, with my application apparently deadlocking without an obvious cause. System threads should not acquire any object-locks, unless an event-handler method you write - like paint() - acquires any. I fixed my problem by changing the design to use one thread instead of two. I appreciate that this may not be possible in your case!
The MIDP specification says that you "should not hold any locks when serviceRepaints() is called". serviceRepaints() might call paint() with the same thread, or a different thread, so you should certainly not hold locks that paint() needs. But the spec seems to say that the entire program should not hold any locks on anything!
As you have a cut-down version of your game, it might be worth trying some different design approaches with it. For example, what if you create a new drawing thread when needed, and let it die, rather than keeping the same one asleep? That would avoid the synchronization issue, at the cost of a small amount of garbage.
I'm afraid that's about as much help as I can be!!
i can't that i have any locks, but maybe im not looking for the right thing.
can you give me an example..
i have some synch. blocks for the wait statement, but thats all.
i have a thread for the draw loop, and it dosent do anything else. i use the wait() on it, every time around, and them wake it up with a notify() from my function loop when there is an update to the screen.
every time my paint loop runs , the mem free size goes down, i put a Runtime.getRuntime().gc(); in my loop and i stops the mem from going down , but at the expence of speed...
i cant se that i use any new mem in my loop...
i only have the main exec thread + one for my draw loop.
When I got rid of the need for synchronization, the deadlocks disappeared completely. I don't use any animation, so I don't get any "ticks", though I do sometimes get slight delays if I choose a command quickly after a screen appears. I'm blaming these on garbage collection; I've added a System.gc() to the end of another time-consuming task so that this gets done when the user isn't expecting to be able to do anything anyway, and so far the software seems more responsive.
I have no experience with games, but plenty here do, so it's probably worth your while to post a new question in the graphics forum about your animation problem. (If you haven't already!!)
i use Runtime.getRuntime().gc(); , because System.gc(); has no effect om my phone and emulator.
but i still cant get rid of the little ticks, they show on both the emulator and the phone. i use Nokia UI API so i cant use the profiler thats comes with sun's WTK. are there any other means of profiling.
my game is wery responsive, all that runs perfect and i get allmost 20fps. i have used 2 months streamlining my code, and that has paid off. the only thing i need is to get rid of the ticks.