The finished member in the AbstractGame implementation probably should be marked as volatile.
(I've been told to ok code changes here on the forums before committing anything… so here you go.)
Why should it be marked volatile?
For multithreading I guess.
Anyway, changing it to volatile has absolutly no impact on performance since it's only used for shutting down (or it sounds like that anyway). You don't have to ask for changes this small really.
I still don't understand the reasoning even in a multithreaded scenario as volatile makes sure the change is real-time across multiple threads, multiple processors, and multiple cores. This isn't necessary as even if you have many threads running, and one of those many threads calls finish() it won't cause any problems because when it does propagate across to the single thread doing graphical rendering it will shutdown properly. The only gain you may get is a few nanoseconds sooner that the shutdown process begins after a call to finish from another thread occurs.
I think we should be careful what we make volatile as it takes more processing power to maintain than a normal variable.
It's only checked once per frame, so we'll live.
A non volatile variable is in an undefined value for an unknown period of time in any other thread than the one you changed it from. Might be a few nanoseconds, might not be. It's not a big performance hit either (it just reads from main memory instead of local thread memory), since you don't seem to care about nanoseconds I doubt that will make you very sad.
I can see how it cause cause some weird situations, with threads waking up other threads cause they think they're finished, and those other threads starting some new task cause they know nothing about that. Escp. if you set some other volatile variables for these threads that assume you'll shut down, that might give you one of those weird shutdown behaviours where you have one of those "I guess the developers didn't care much for when you want to STOP playing their game" moments.
Far fetched, maybe… but who knows what Guurk is cooking up. 
edit; In the near future I think you can have situations where the of time it takes for a volatile variable to be updated will actually be noticable. Server systems already let different processors have their own dedicated memory (allowing them to use their own memory controller directly without syncing with the other one, escp. for AMD systems with their on die memory controllers this is nice, in some cases you're actually talking about seperate DIMMs here). With Vista (which I think supports this type of memory addressing now) and AMD's 4x4 platform these things are starting to trickle into the gaming world…
Do you think perhaps guurk was just trying to pick the absolute smallest change he could find to show his dissatisfaction with okaying code changes? :?
…maybe that's just something I would do.
i had no clue we were more than 6 developers until yesterday, so i'm still in chock…
MrCoder said:
i had no clue we were more than 6 developers until yesterday, so i'm still in chock...
After doing the math we end up with less than six....after all, I count as like -2. ;)
MrCoder said:
i had no clue we were more than 6 developers until yesterday, so i'm still in chock...
well, I noticed quite a while ago that guurk had developer status and wondered a little that nobody talked about it, and wondered why, because I thought he left jME quite some time before, but hey...
..welcome back :D
I've never really ever been gone, I just got a life too. 
My big work way back when was on gui stuff. With the Swing integration now implemented I'm not really needed much since I'm not really that good at opengl (thus the reason I need JME :)).
Most of my recent work has been on a couple of my own projects, so updates to JME are only within the world of what I personally need and would be useful to others; at least I hope so.
Honestly, I really wasn't trying to make some political point. I just figure that since I'm not a consistent contributer I'd be sure to run everything past y'all before doing anything.
cool. even if you are not that good at opengl i suppose you could help out with the 1.0 release we are aiming to get out as soon as possible. like writing javadocs, checking code consistancy, fixing bugs or writing unit tests?
I'm happy to help out where needed. Just point. I'm pretty good at CM and release coordination as well.