This might sound similar to some of the other questions but it does not deal with wait or notify.

I have two threads which do two different things
The first forms a process in the background and changes behavior when it receives an input from the other thread that interacts with the user.

  • look up "semaphore". Jul 14, 2016 at 6:22
  • With a semaphore, the second thread will have to wait until the first thread triggers it. Apparently this is not the desired behaviour.
    – mgoeminne
    Jul 15, 2016 at 7:35

3 Answers 3


There's a simple way to do this: You set up an object with the synchronized data and share it between the threads. You can then write the data or check for it from each thread.

So, you'd have an instance of a class that looks like this:

public class Shared {
    private boolean signalSent = false;

    public synchronized boolean isSignalSent(){
        return this.signalSent;

    public synchronized void setSignalSent(boolean signal){
       this.signalSent = signal;  

You may want to consider, if the signal can be re-sent, to have a method that reads and resets the value.

In any case, the instance of that class should be passed to both threads, and will be able to do something like

    // behave a certain way
} else {
    // behave another way
  • It should definitively do the job, but the second thread will have to wait for a mutex each time it wants to synchronise the shared object, even after the signal has been sent (and taken into account). What about a State/Strategy DP: the initial state consists in checking the shared object, and to switch to the second state as soon as the signal has been sent. The second state consists in "behave an other way" without checking the shared object.
    – mgoeminne
    Jul 15, 2016 at 7:40

If this is Java, first have a good long look at java.util.concurrent. Trying to reinvent what was already solved creates so many subtle problems. It seems simple, but it's incredibly hard to get it just right.

Be careful to think about what you are doing. You seem to be asking for one thread to produce data, and the other thread to consume data. You don't want to block, so you have no choice but to make the second thread repeatedly poll. There are all sorts of established design patterns for this. Ask yourself: (1) does the first thread produce a boolean "event" (like "it happened"); (2) will the event have to get reset and occur again; (3) will you combine the event with data (like a boolean plus a string); and so forth. Each of these considerations adds complexity for synchronization between threads.

A common flaw for (3) above, is a synchronized method or mutex block to ask "is there data", then unblock, then the 2nd thread thinks it now wants the data, and asks "give me that data". In between the "is there data" and "give me that data", the first thread can reset the state to no event present and reset the data to nothing. The second thread is now asking for something that doesn't exist.

Rather than hunt down all these subtle interactions, look to reuse a design pattern and use a well-established concurrent utility.


i think you can do this using common method in both the thread ,

for example

1 thread can get the input from the user and process on that and successfully processed than it update the common method and

2 thread continuously check the common method if it is updated or not

if it is updated than it start process on that.

  • Methods cannot be updated in Java. Plus, active waiting is a very bad idea if you don't have dedicated resources. Plus, if your "update" is not atomic, the waiting thread could read an inconsistent state since your are not locking it.
    – mgoeminne
    Jul 15, 2016 at 7:34
  • you can use the synchronized shared thing in both the thread one thread can update it and another thread can check and process if updated.
    – Mowgli
    Jul 15, 2016 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.