Re: Requesting tips, comments for an EDT thread-safe game architecture

On Mar 21, 6:14 pm, Knute Johnson <nos...@xxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Oliver Wong wrote:
I recently saw a thread about the Swing EDT in the CLJP, and it made
me wonder whether my general game architecture was thread safe or not.
EDT, and threading in general, are one of my weaker points in Java. Is
this general design okay? Are there things which I've put into the EDT
which I shouldn't have? Are there things which are outside of the EDT that
should be in it?
Having played a lot with one form of animation, I would use a completely
different tack. Use a Window or JWindow and do active rendering. This
avoids the EDT altogether for any drawing. You still may have to
synchronize some parts of your code but the more you can avoid that the
better. Synchronizing can have a rather significant performance hit.

--

Knute Johnson
email s/nospam/knute/

And incorrectly avoid Synchronization can have an extreme correctness
"hit".

Generally, synchronization isn't the "bad thing" that people have
stigmatized it to be. Used incorrectly, it can lead to problems,
yes... But those generally come from a lack of understanding. If you
tell people "Avoid, Avoid, Avoid", they'll possible never learn when/
where they MUST use it.

I suggest Java Concurrency in Practice <http://jcip.net/> for anyone
who wants to know the correct way to deal with multithreaded
applications. I already understood SOME of it, but that book
clarified a lot of concepts, and solidified my understanding of multi-
threaded programming.

On Mar 21, 9:41 am, "Oliver Wong" <o...@xxxxxxxxxxxxxx> wrote:
<SSCCE>
[snip]
while (!timeToQuit) {
getPlayerInput();
processGameLogic();
EventQueue.invokeAndWait(new Runnable() {
@Override
public void run() {
synchronized (mainWindow) {
Graphics2D g = (Graphics2D) mainPanel.getGraphics();
g.setTransform(AffineTransform.getScaleInstance(
(double) mainPanel.getWidth()
/ (double) DEFAULT_RENDERING_WIDTH,
(double) mainPanel.getHeight()
/ (double) DEFAULT_RENDERING_HEIGHT));
updateScreen(g);
}
}
});
Thread.sleep(1);
}
}
[snip]

</SSCCE>

- Oliver


Oliver:
I personally think its a "Bad Thing" to have a busy wait -- a while
loop with a Thread.sleep(). Swing is design around an Event model,
you can probably refactor your code to avoid running on the main
thread, and use a javax.swing.Timer instead.

That way you don't need to have a "getPlayerInput()",
"processGameLogic()", and the strange call to invokeAndWait(). It can
all be event driven.

BTW, you should avoid "synchronize" in the EDT all together. If you
have a thread that synchronizes on an object, and then calls
"invokeAndWait" with a runnable that syncs on the same object, you
have a deadlock. And this is only the first order example.

Hope this helps,
Daniel.

P.S. Again, I suggest Java Concurrency in Practice <http://jcip.net/>

.

Relevant Pages

  • synchronizing for data visibility
    ... to avoid the performance hit that I read about everywhere. ... deadlocks I don't want to synchronize at the API level. ... a single API call to the class can internally call dozens of methods, ...
    (comp.lang.java.programmer)
  • Re: No Java 2 SDK, v1.4 support for APPLET
    ... I'm trying to avoid the SUN applet plugin if possible. ... Phil. ... Knute Johnson ...
    (comp.lang.java.programmer)
Quantcast