Tom Hawtin wrote On 05/25/07 10:59,:

   May I abuse your patience a little longer?  I'm
still not seeing the problem, and if one does in fact
exist I'd like to understand it at a deeper level than
"Don't Do That."

   My suggestion is (pseudocode)

    final Thing thing = new Thing();
    synchronized(thing) {
       SwingUtilities.invokeLater(new Runnable() {
           public void run() {
               // display dialog, get user input
               synchronized(thing) {
                   thing.putData(userInput);
                   thing.notify();
               }
           }
       });
       while (! thing.hasData())
           thing.wait();
    }
    Data userInput = thing.getData();
    // merrily we roll along

   It seems to me -- here's where I need help -- that
there are two different threads interested in the lock
on thing: the launching thread shown above, and the EDT.
If invokeLater() returns without waiting for the EDT to
do something, then the launching thread will proceed to
the thing.wait() call, which releases the lock.  This
will allow the EDT to acquire thing's lock in the Runnable
(it may or may not have already been waiting to do so).
Once it gets the lock, it runs through its synchronized
block and releases it again.  The launching thread can
then awaken from thing.wait(), re-acqure the lock, and
test the state of thing.  It looks like both threads
are certain to be able to make progress, so where's the
deadlock risk?

   Is there a situation in which invokeLater() waits
for the EDT to run the Runnable before returning?  That
would be a deadlock for certain, not just in prospect!