aspose file tools*
The moose likes Threads and Synchronization and the fly likes Why are two diff. Tasks/Threads ending up on the same thread? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Why are two diff. Tasks/Threads ending up on the same thread?" Watch "Why are two diff. Tasks/Threads ending up on the same thread?" New topic
Author

Why are two diff. Tasks/Threads ending up on the same thread?

Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
I am using a thread pool which takes scheduled tasks. These tasks interact through a socket with the user (via a GUI app). Each task is on a diff. thread in a pool. If one task is already working with the GUI, the second one is supposed to wait (via lockObject.wait() ). However, when I call wait on that object, the GUI becomes unusable. After some checking i discovered it's because somehow those DIFFERENT threads become the SAME thread: "AWT-EventQueue-0". How/why is this? How do I stop them from being run on the same thread so i can do wait/notify?

(I am running these tests/dev on one computer with loopback)
Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
I solved the problem but it seems kind of "stupid" (?) and unclean.

Each task had registered itself with a GUIWindow (my class which extends Window) and when a mouse was clicked on the window, an GUIEvent was sent to the task. Since it was sent from within mouseClicked(MouseEvent), apparently Swing uses the same thread as it does for EVERY gui action (e.g. painting), event, etc. So there's no way my task can wait on anything as it causes the same thread (AWT-EventQueue-0) that the other task was running in to also wait (since they're the same thread). To solve it, I simply create a new thread to handle notifying listeners.



This seems like it shouldn't be required, but there's no other way around it. I tried sending the event in SwingUtilities.invokeLater and invokeAndWait and neither one worked.
Ben Rowland
Greenhorn

Joined: Jan 26, 2005
Posts: 6
<p>
Both invokeLater() and invokeAndWait() cause the Runnable instance to be executed by the Swing event dispatching thread, regardless of which thread calls the method.
</p>
<p>
These methods are used if you want to update a Swing GUI from (e.g.) the Main thread. Quote from the Sun 'How to Use Threads' tutorial:
<blockquote>
To avoid the possibility of deadlock, you must take extreme care that Swing components and models are created, modified, and queried only from the event-dispatching thread.
</blockquote>
</p>
<p>
By the way I'd recommend that Sun tutorial.
</p>
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24168
    
  30

Dan --

It's neither stupid nor unclean; it's just how things are supposed to work. It's (supposed to be) well-known that all GUI events are handled on a special event-handler thread, and also that you should never do any long-running processes on the event thread, but rather spawn threads to do them on. Now, you said you are using a Thread pool; your event handlers could, of course, use that pool to run their tasks.


[Jess in Action][AskingGoodQuestions]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why are two diff. Tasks/Threads ending up on the same thread?
 
Similar Threads
Multiple Thread Pool Framework - HowTo
thread pooling
Join in a pool thread
Thread.start() or thread.stop()
using Thread.activeCount to monitor the end of work by the threads