Thread Livelock

A livelock is a recursive situation where two or more threads would keep repeating a particular code logic. The intended logic is typically giving opportunity to the other threads to proceed in favor of ‘this’ thread.

A real-world example of livelock occurs when two people meet in a narrow corridor, and each tries to be polite by moving aside to let the other pass, but they end up swaying from side to side without making any progress because they both repeatedly move the same way at the same time.
From Oracle reference docs:

 A thread often acts in response to the action of another thread. If the other thread’s action is also a response to the action of another thread, then livelock may result. As with deadlock, livelocked threads are unable to make further progress. However, the threads are not blocked – they are simply too busy responding to each other to resume work.

For example consider a situation where two threads want to access a shared common resource via a Worker object but when they see that other Worker (invoked on another thread) is also ‘active’, they attempt to hand over the resource to other worker and wait for it to finish. If initially we make both workers active they will suffer from livelock.
main

The Common Resource Class

public class CommonResource {
    private Worker owner;

    public CommonResource (Worker d) {
        owner = d;
    }

    public Worker getOwner () {
        return owner;
    }

    public synchronized void setOwner (Worker d) {
        owner = d;
    }
}

The Worker Class

public class Worker {
    private String name;
    private boolean active;

    public Worker (String name, boolean active) {
        this.name = name;
        this.active = active;
    }

    public String getName () {
        return name;
    }

    public boolean isActive () {
        return active;
    }

    public synchronized void work (CommonResource commonResource, Worker otherWorker) {
        while (active) {
            // wait for the resource to become available.
            if (commonResource.getOwner() != this) {
                try {
                    wait(10);
                } catch (InterruptedException e) {
                   //ignore
                }
                continue;
            }

            // If other worker is also active let it do it's work first
            if (otherWorker.isActive()) {
                System.out.println(getName() +
                            " : handover the resource to the worker " +
                                                       otherWorker.getName());
                commonResource.setOwner(otherWorker);
                continue;
            }

            //now use the commonResource
            System.out.println(getName() + ": working on the common resource");
            active = false;
            commonResource.setOwner(otherWorker);
        }
    }
}

The main class

public class Livelock {

    public static void main (String[] args) {
        final Worker worker1 = new Worker("Worker 1 ", true);
        final Worker worker2 = new Worker("Worker 2", true);

        final CommonResource s = new CommonResource(worker1);

        new Thread(() -> {
            worker1.work(s, worker2);
        }).start();

        new Thread(() -> {
            worker2.work(s, worker1);
        }).start();
    }
}

Output:

There will be never ending recursion of the following output:

Worker 1  : handing over the resource to the worker: Worker 2
Worker 2 : handing over the resource to the worker: Worker 1
Worker 1  : handing over the resource to the worker: Worker 2
Worker 2 : handing over the resource to the worker: Worker 1
Worker 1  : handing over the resource to the worker: Worker 2
Worker 2 : handing over the resource to the worker: Worker 1
    ........

Avoiding Livelock

In above example we can fix the issue by processing the common resource sequentially rather than in different threads simultaneously.

Just like deadlock, there’s no general guideline to avoid livelock, but we have to be careful in scenarios where we change the state of common objects also being used by other threads, for example in above scenario. the Worker object.

How To Stop A Thread In Java?

How do you stop a thread in java? now-a-days, this has been the popular question in the java interviews. Because, stop() method has been deprecated for some safety reasons. As stop() method has been deprecated, interviewer will be interested in what logic you will be using to stop a thread. There are two ways through which you can stop a thread in java. One is using boolean variable and second one is using interrupt() method. In this post, we will discuss both of these methods.

How To Stop A Thread In Java Using A boolean Variable?

In this method, we declare one boolean variable called flag in a thread. Initially we set this flag as true. Keep the task to be performed in while loop inside the run() method by passing this flag. This will make thread continue to run until flag becomes false. We have defined stopRunning() method. This method will set the flag as false and stops the thread. Whenever you want to stop the thread, just call this method. Also notice that we have declared flag as volatile. This will make thread to read its value from the main memory, thus making sure that thread always gets its updated value.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
class MyThread extends Thread
{
    //Initially setting the flag as true
    
    private volatile boolean flag = true;
    
    //This method will set flag as false
    
    public void stopRunning()
    {
        flag = false;
    }
    
    @Override
    public void run()
    {
        //Keep the task in while loop
        
        //This will make thread continue to run until flag becomes false
        
        while (flag)
        {
            System.out.println("I am running....");
        }
        
        System.out.println("Stopped Running....");
    }
}
public class MainClass
{  
    public static void main(String[] args)
    {
        MyThread thread = new MyThread();
        
        thread.start();
        
        try
        {
            Thread.sleep(100);
        }
        catch (InterruptedException e)
        {
            e.printStackTrace();
        }
        
        //call stopRunning() method whenever you want to stop a thread
        
        thread.stopRunning();
    }   
}

Output :

I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
Stopped Running….

How To Stop A Thread In Java Using interrupt() Method?

In this method, we use interrupt() method to stop a thread. Whenever you call interrupt() method on a thread, it sets the interrupted status of a thread. This status can be obtained by interrupted() method. This status is used in a whileloop to stop a thread.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
class MyThread extends Thread
{   
    @Override
    public void run()
    {
        while (!Thread.interrupted())
        {
            System.out.println("I am running....");
        }
        
        System.out.println("Stopped Running.....");
    }
}
public class MainClass
{  
    public static void main(String[] args)
    {
        MyThread thread = new MyThread();
        
        thread.start();
        
        try
        {
            Thread.sleep(100);
        }
        catch (InterruptedException e)
        {
            e.printStackTrace();
        }
        
        //interrupting the thread
        
        thread.interrupt();
    }   
}

Output :

I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
I am running….
Stopped Running…..

Difference between wait(), yield() and sleep()

It all eventually makes its way down to the OS’s scheduler, which hands out timeslices to processes and threads.

sleep(n) says “I’m done with my timeslice, and please don’t give me another one for at least n milliseconds.” The OS doesn’t even try to schedule the sleeping thread until requested time has passed.

yield() says “I’m done with my timeslice, but I still have work to do.” The OS is free to immediately give the thread another timeslice, or to give some other thread or process the CPU the yielding thread just gave up.

.wait() says “I’m done with my timeslice. Don’t give me another timeslice until someone calls notify().” As with sleep(), the OS won’t even try to schedule your task unless someone calls notify() (or one of a few other wakeup scenarios occurs).

Threads also lose the remainder of their timeslice when they perform blocking IO and under a few other circumstances. If a thread works through the entire timeslice, the OS forcibly takes control roughly as if yield() had been called, so that other processes can run.

You rarely need yield(), but if you have a compute-heavy app with logical task boundaries, inserting a yield() might improve system responsiveness (at the expense of time — context switches, even just to the OS and back, aren’t free). Measure and test against goals you care about, as always.

Java Threads Important Points.

Defining and instantiating and Starting Threads:

  • Threads can be created by extending Thread and overriding the public void run () method.
  • Thread objects can also be created by call the thread class constructor that takes a Runnable argument, the Runnable object is said to be the target of the thread.
  • You can call start () on a thread only once. If start() is called more than once on a thread object it will throw Runtime exception
  • It is legal to create many thread objects using the same Runnable object as the target.
  • When a thread object is created, it does not become a thread of until its start () method is invoked. When a thread object exists but hasn’t been started. It is in the new state and is not considered alive.

Transitioning between the Thread States:

  • Once a new thread is started, it will always enter the Runnable state.
  • The thread scheduler ca move thread back and forth between the Runnable state and the running state.
  • For a typical single-processer machine, only one thread can be running at a time, although many threads may be in Runnable state.
  • There is no guarantee that the order in which threads were stated determines the order in which they’ll run.
  • There’s no guarantee threads will take turns in any fair way. It’s up to the thread scheduler, as determined by the particular virtual machine implementation. If you want a guarantee that your threads will take turns regardless of the underlying JVM. You can use the sleep () method.
  • This prevents one thread from hanging the running process while another thread serves. (In most cases though yield () works well enough to encourage your threads to play together nicely).
  • A running thread may enter a blocked / waiting state because it can’t acquire the lock for a synchronized block of code.
  • When the sleep or wait is over, or an objects lock become available, the thread can only reenter the Runnable state. It will go directly from waiting to running (well, for all practical purpose only).
  • A dead thread cannot be started again.

Sleep, Yield and join:

  • Sleeping is used to delay execution fo a period of time, and no locks are released when a thread goes to sleep.
  • A sleeping thread guaranteed to sleep for at least the time specified in argument to the sleep () method (unless it is interrupted), but there is no guarantee as to when the newly awakened thread will actually return to running.
  • The sleep () method is static method that sleeps the currently executing thread’s state. One thread cannot tell another thread to sleep.
  • The set priority() method is used on thread objects to give threads a priority of between 1(low) and 10(high), although priorities are not guaranteed, and not all JVMs recognize 10 distinct priority levels, some levels may be treated as effectively
  • If not explicitly set, a thread’s priority will have the same priority as priority of the thread created it.
  • The yield () method may cause a running thread to blackout if there are Runnable threads of same priority.
  • There is no guarantee that those will happen, and there is no guarantee that the thread selected to run. A thread might yield and then immediately renter the running state.
  • The closest thing to guarantee is that at any given time when the thread is running it will usually not have a lower priority than a thread in the Runnable state.
  • If a low-priority thread running and a high-priority thread enter Runnable, the JVM will usually preempt the running low-priority thread and put the high-priority thread in.
  • When one thread calls join () method of another thread, the currently running thread will wait the thread it joins which has completed.
  • Think the join () method as saying “Hay thread, I want to join on to the end of you, let me know when you are done so I can enter the Runnable state.”

Concurrent Access Problems and Synchronized Threads:

  • Synchronized methods prevent more than one thread from accessing an object’s critical method code simultaneously.
  • You can use the synchronized keyword as a method modifier, or to start a synchronized block of code.
  • To synchronize a block of code ( in other words, a scope smaller than the whole method) you must specify an argument that is the object whose lock you what to synchronize code.
  • While only one thread can be accessing synchronized code of a particular instance multiple threads can still access same objects unsynchronized code.
  • When a thread gets to sleep, its locks will be unavailable to other threads.
  • Static methods can be synchronized, using the local from java.lang.Class instance representing the class.

Communicating with Objects by Waiting and Notifying:

  • The wait() method lets a thread say, “there is nothing for me to do now, so out me in your out pool and notify me when something happens that I care about”. Basically a wait () call means “wait me in your pool” or “add me to your waiting pool”.
  • The notify () method is used to send a signal to one and only one of the threads that are waiting in that same object’s waiting pool.
  • The notify method can NOT specify which waiting thread to notify.
  • The method notifyAll () works in the same way as notify (), only it sends the signal to all of the threads waiting on the object.
  • All three methods wait (), notify (), notifyAll () must be called for within a synchronized context. A thread invokes wait () or notify () on a particular object, and the thread must currently hold the lock on the object.

Deadlocked Threads:

  • Deadlocking is when thread execution grinds to a halt because the code is waitng for locks to be removed from objects.
  • Deadlocking can occur when a locked object attempts to access another locked object that is trying to access the first locked object.
  • In other words, both threads are waiting for each other’s locks to be released; therefore, locks will never released
  • Deadlocking is bad, don’t do it.