An good answer on that would solve my problems too (just to show the
interest on the thread safety topic)!
Thanx, Andrew.
Bruno
-----Original Message-----
From: Discussion list for Java 3D API
[mailto:[EMAIL PROTECTED]]On Behalf Of Andrew Moulden
Sent: Sonntag, 7. November 1999 12:18
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Using behaviors... Behavior.postId() example
Doug Gehringer wrote:
>To review:
> -- If you are making a single change to the scene graph, you can >just
> make your change from your UI event handling code.
> -- If you are making several changes, then you may want to use
> Behavior.postId() to group your changes into a single frame.
Doug,
I'm not sure I understand you on this. Could you explain in more detail
how J3D is synchronizing data between J3D's behavior thread and other
threads (primarily the AWT event thread) ?
In the example you've given and in messages you've made in the past
you've been speaking about 'synchronizing' the J3D renderer to avoid any
frame discontinuities i.e. it's *preferable* (but not mandatory) to
handle scene graph changes in J3Ds behavior thread so that all scene
graph updates are handled inter-frame and no visual anomalies will occur
due to a Canvas3D being rendered before all input events have been
processed.
You seem to be advocating that it's okay to directly update a scene
graph from a UI (and presumably therefore from a network) providing it's
a single operation. However, I can't see how this can be so unless it
can be guaranteed that the operation is atomic. Surely it's a
*requisite* if you want a J3D app to be thread safe to post scene graph
changes as either a behavior or into some sort of synchronized event
queue (accessed in the postSwap() method of Canvas3D for example)?
By the same token surely it's not possible on thread safety grounds to
simply update a GUI control (even a simple JLabel) directly from the J3D
behavior thread as you have done in your code? The Java Tutorial and
Swing documentation go to great lengths to explain why such operations
should be handled from within the AWT event despatching thread, so I
would have thought that UI updates need to be handled either by using
the rather awkward SwingUtilities.invokeLater() protocol, or by writing
your own event class which extends AWTEvent and implements ActiveEvent
so that the event will be processed through the dispatch() call (equally
messy unfortunately).
J3D is unusual in that it uses it's own event thread rather than the AWT
event thread for input handling. Granted, the AWT event thread was
originally designed for UI purposes, but practically every Java API now
sees it as the core event thread (the Java API docs now call it 'the
event thread'). So in writing Java3D apps, the synchronizing of data
between these two main input threads becomes a core issue, though I
can't find any mention of it in the official literature.
It may be of course that you've got some underlying mechanism which is
guaranteeing thread safety. If you were somehow locking on the AWT event
thread (a very dubious solution I ought to add) during behavior
processing then we'd be okay, but a simple test shows this isn't
happening. Alternatively, you could be synchronizing data (transforms
etc.) inside J3D in ways we can't see, but this would be very expensive
computationally and may subvert JIT optimization.
In short, it's very easy to write test examples which either crash the
VM or corrupt scene graphs/GUI displays by allowing code running in the
AWT thread to directly call into J3D, or vice versa. I'm sure there will
be many who will say 'well, we've been making scene changes from button
presses for months now and have never had a problem' but this isn't the
point. Computers are so fast that the chances of two unsynchronized
threads occupying the same method block and modifying data in an
unpredictable way can be millions to one. The fact is however that such
code is inherently flawed, and I know from bitter experience that the
bugs it introduces are the most insidious you'll ever come across.
Andrew Moulden
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
