1

I am trying to switch back to an existing thread from a spawned child interface callback. Does anyone know how? The callback implementation always runs from the child thread where where it was called, not the implementing class...

Pshemo
  • 122,468
  • 25
  • 185
  • 269
Kevin Parker
  • 16,975
  • 20
  • 76
  • 105
  • 2
    Can you provide some more information? The right answer depends on how your classes are implemented, and how the threads in your application are currently being dispatched. – Daniel Pryden Jul 30 '12 at 00:09

4 Answers4

5

What do you mean switch back?
Cause a context switch that will return you to "original" thread that spawned the child thread?
If so, this is not possible. It contradicts Multi-threading concepts.
If you want to have some work done on the "original" thread, while the "child" thread is running,
You can consider having a queue between the child and the original thread (i.e - Producer/Consumer).
The child thread will put a "job" on the queue, and the "original" thread will consume it.
However,the "original" thread will have to block on the the "child" thread.

Another way to implement this is using wait and notify, (child thread will notify) - but once again, original thread will have to wait.

Last approach will be to simply wait on the child thread execution to end, if you want to return to the original thread at the end of execution of child thread. The question is - is waiting at the original thread is acceptable at your scenario?

Yair Zaslavsky
  • 4,091
  • 4
  • 20
  • 27
2

You simply have the calling thread wait() on an object, and have the child thread notify() the same object.

When wait() is called, the calling thread will halt.
When notify() is called, the waiting thread will wake up and continue on.

These calls must be made within a synchronized block/method.

Bohemian
  • 412,405
  • 93
  • 575
  • 722
  • The use of `wait()` and `notify()` is generally discouraged these days, in favour of higher level constructs such as `Semaphore` and `CountDownLatch`. – Muel Jul 30 '12 at 04:50
0

Swing uses the concept of an Event Dispatch Loop (EDL), and all Swing component interaction must run on the the EDL's thread. This sounds analogous to what you want to do, and to what zaske proposed in his response.

You might find the following helpful in formulating your solution:

Richard Sitze
  • 8,262
  • 3
  • 36
  • 48
0

Since this is also tagged java-ee I'll mention that you are not allowed to start threads in any Java EE app server. It introduces several issues:

  • Easy to bleed the server of thread resources
  • Can prevent undeployment of the application
  • Can prevent server shutdown if threads are not marked as daemons
  • Loss of functionality such as JNDI, Transactions, Security

It's generally a no-no. You might instead look into the @Asynchronous annotation which allows you to easily do fork/join kinds of logic safely with the cooperation of the container.

This answer has a very complete explanation of how @Asynchronous methods work including example code https://stackoverflow.com/a/6158773/190816

Community
  • 1
  • 1
David Blevins
  • 19,178
  • 3
  • 53
  • 68