How about:


         /** Paints an image to the screen either buffered or
unbuffered.  If buffered, the
             buffer is returned for your convenience.   This method is
called from Swing
             when the window is resized or scrolled or whatnot, but it's
also called as
             a result of the underlying model thread advancing a tick so
we can see
             what happened.  In the second case, the method could
conceivably be
             called both from the Swing event thread (if making a movie,
or if in MacOS X)
             or from the underlying model thread (if in Windows or X
Windows -- to change
             this, see Display2D.step).  This is important because this
if we're being called
             from the Swing event thread (repaint/movie/MacOS X), we
must ensure that we're
             not updating the model at the same time the model is
changing, and to do that
             we lock on the simulation's schedule so we know the model
is done with step()
             methods and nothing's moving.  But because we're blocking
on the schedule,
             a deadlock opportunity arises.  For example, what if some
foolish person writes
             a step() method in the model which calls some blocking item
in the Swing event
             thread?  Then they're blocking waiting for the Swing event
thread to come
             available again, but the event thread is blocking because
we're waiting for them
             to get out of the model.  A similar problem could arise if
in implementing a
             portrayal's draw method the user decides to call some
blocking item in Swing,
             because this paint() method could conceivably be called
from the model itself
             (in Windows/XWindows), and it's possible that at the very
same time the user
             has pressed the stop button or done some operation in Swing
which is blocking
             waiting for the schedule.  Long story short, try not to
call a blocking method
             on Swing from inside this method. */


On Nov 11, 2004, at 6:47 AM, Rob Alexander wrote:

> Hi,
>
> The comment for the method paint() in Display2D.InnerDisplay2D is
> unfinished:
>
>         /** Paints an image to the screen either buffered or
> unbuffered.  If buffered, the
>             buffer is returned for your convenience.   Synchronizes on
> the schedule; since we know
>             that the schedule's step() method is synchronized on the
> schedule as well, this
>             gives us a way to block this method from reading from the
> model until we know
>             the model isn't being updated any more.  However as you
> might guess, this also
>             presents a deadlock opportunity if a scheduled */
>
>
> I'm quite interested to hear the rest of it, because I'm currently
> developing my own Controller and have run into some threading issues.
> Currently, I'm avoiding deadlocks by always calling Display2D.step() in
> using invokeLater(), but I've not done much Swing before and I don't
> have a good grasp of the situation.
>
>
> rob
> --
> Rob Alexander                   (E-mail:
> [log in to unmask])
> Research Associate, Dept of Computer Science, The University of York,
> York, YO10 5DD, UK
> Tel: 01904 432792       Fax: 01904 432708