Java Development

[marchywka]

I'd be very surprised if this really fixes anything. I can't find anything in docs about holding lock for

a request call but offhand I'd presume this would almost require NOT having the lock.

The assertion that fails in your stack trace is either not literally accurate, the stack containes a severley misleading first few methods,  or a severe bug since that stack apparently started by processing messages. Often the RIM classes show

up in the debugger and while no source code is available, members are observable and you may be able

to specifically find the logic behind this assertion. Since it probably does NOT check directly for

holding the UI lock, there is probably a flag it checks but this may or ma not be discernable from the debug info.

Presumably, someone else could get to this flag without holding the ( presumably required ) lock and damage

this assertion. The reason for requiring GUI modification while holding the lock is that other things can become inconsistent and this assertion failure could reflect that.

What probably happens is your grabbing the lock changes the timing enough to prevent the specific inconsistency.

Threading problems often look like this.

Unless someone from RIM or with more in depth knowledge of RIM implementation contradicts me ( and that would be about a 50-50 thing LOL), or I have missed something very obvious, I would assume you have not fixed the problem.

Also, you almost never want synchronized "just for the heck of it" as some early jvm implementations did this

and it was slow and prone to deadlock.

[marchywka]

I guess you could empirically determine if that request needs to be synchronized by

making a fast and simple test case where you repeatedly call it and then go

back and forth and see if you can get your original failure mode or one likely to

be caused by a lack of synchronization. If not, I'd be concerned that this call

does not require synchronization and your fix is not helping. Normally, unless

stated otherwise, I think of a "Request" as something that puts a message

into a que for later execution and shouldn't need the queue lock.

[mcmordie]

Thanks for your feedback.  I didn't figure that requestForeground should require the lock-- it certainly doesn't say so in the docs, and I would have expected RIM not to overlook such a thing.

The problem has gone away completely now on both the phones where it was reported.  I won't have clear confirmation that this was or was not it until I am able to construct a test case, but it does seem to coincide with the solution. 

Best,

Dave