This contrived project will eventually deadlock, won't it?
Two methods are synchronized in a shared object. The two threads will eventually find themselves in one of those methods and trying to invoke the other method. I think.
package main;
import java.util.ArrayList;
import java.util.List;
import myThread.MyThread;
import sharedObject.SharedObject;
import uncooperativeThread.UncooperativeThread;
public class Main {
public static void main(String[] args) {
competingThreads();
//uncooperativeThreads();
}
private static void competingThreads() {
List<MyThread> myThreads = new ArrayList<MyThread>();
SharedObject sharedObject = new SharedObject();
int threads = 2;
for (int i = 0; i < threads; i++) {
myThreads.add(new MyThread(i, sharedObject));
}
for (MyThread t : myThreads) {
t.start();
}
for (MyThread t : myThreads) {
try {t.join();} catch (Exception ex) {}
}
}
/**
* We will try to call SharedObject.methodC from two threads. The first one will get in, the second will have to wait.
*/
private static void uncooperativeThreads() {
SharedObject sharedObject = new SharedObject();
UncooperativeThread t1 = new UncooperativeThread(1, sharedObject);
UncooperativeThread t2 = new UncooperativeThread(2, sharedObject);
t1.start();
t2.start();
try {t1.join();} catch (Exception ex) {}
try {t2.join();} catch (Exception ex) {}
}
}
package myThread;
import sharedObject.SharedObject;
public class MyThread extends Thread {
private int id;
SharedObject sharedObject;
public MyThread(int id, SharedObject sharedObject) {
this.id = id;
this.sharedObject = sharedObject; // Reference
}
public void run() {
doStuff();
}
private void doStuff() {
int counter = 0;
while (true) {
System.out.println(++counter);
if (id % 2 == 1) {
sharedObject.methodA(id);
} else {
sharedObject.methodB(id);
}
}
}
}
package sharedObject;
import java.util.Random;
public class SharedObject {
public synchronized void methodA(int id) {
//System.out.println("methodA(): Thread " + id);
try {Thread.sleep((new Random()).nextInt(1000));} catch(Exception ex) {}
if (id == 0) {return;}
// What I want is for one thread to try to call methodB() while the *other* thread is in methodB() trying to call methodA().
methodB(id);
}
public synchronized void methodB(int id) {
//System.out.println("methodB(): Thread " + id);
try {Thread.sleep((new Random()).nextInt(1000));} catch(Exception ex) {}
if (id == 1) {return;}
methodA(id);
}
}
// What I want is for one thread to try to call methodB() while the other thread is in methodB() trying to call methodA().
That's not a deadlock. The thread that's trying to call methodB() simply will be forced to wait until the other thread releases the lock by returning from its methodB() call.
To get a classic deadlock, you need to have two locks. Your program has only one lock—the intrinsic lock belonging to the single instance of SharedObject that your program creates.
A classic deadlock is when one thread has already acquired lock A and is waiting to acquire lock B while the other thread has acquired lock B, and it's waiting to acquire lock A. In that case, neither thread can make progress until the other thread releases its lock. But, neither thread will release its lock because neither thread can make progress.
You need two locks. You have two methods (methodA() and methodB()), but they both lock the same lock.
Related
So I implanted Mutex to pause and resume thread but when I start the thread with the implemented Mutex outer thread stop executing till the inner thread finish. I am not sure where I am wrong. I create an interface to get the lock value and use it as boolean for if statement. So basically when the custom thread run the inner thread freeze till the inner thread is not finished. I need to not stop.In two words, I need to pause the thread and resume it later. In // do my code here comment field I am using function which have a loop inside, I am not sure if this is the problem.
Interface:
public interface Thread {
Mutex getMutex();
void run();
}
Thread example:
public class CustomThread extends Thread implements ThreadInterface{
private final Mutex mutex;
public CustomeThread() {
this.mutex = new Mutex(false);
}
public Mutex getMutex() {
return this.mutex;
}
#Override
public void run() {
while (!isInterrupted()) {
mutex.step();
// Do my code here
}
}
}
Starting the thread in another thread:
public class ThreadingUtil {
public void threadRunner(List<CustomThread> threadList) throws InterruptedException {
if (threadList.size() > 1) {
Random random = new Random();
while(threadList.size() > 0) {
int index = random.nextInt(threadList.size());
CustomThread thread = threadList.get(0);
if(thread.getMutex().isLock().get()) {
thread.getMutex().unlock();
} else {
thread.run();
}
// Code stop here after run the thread
Thread.sleep(20000);
thread.getMutex().lock();
System.out.println("thread mus be locked next thread");
}
}
}
Running outer thread:
thread = new Thread(new Runnable() {
#Override
public void run() {
try {
threadingUtil.threadRunner(threadList);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
}
});
thread.start();
Mutex:
public class Mutex {
private final AtomicBoolean lock;
private final Object mutex;
public Mutex(boolean lock) {
this.lock = new AtomicBoolean(lock);
this.mutex = new Object();
}
public void step() {
if (lock.get()) synchronized (mutex) {
try {
mutex.wait();
} catch (InterruptedException ex) {
}
}
}
public void lock() {
lock.set(true);
}
public AtomicBoolean isLock() {
return this.lock;
}
public void unlock() {
lock.set(false);
synchronized (mutex) {
mutex.notify();
}
}
}
EDIT: I start the thread with implementing start() method in the Thread interface now its not blocking the thread but the getMutex().lock() is not stopping the thread now.
EDIT: in run method make sure to not place inner loop i the while loop since is not pausing the inner loop
I have two synchronized methods and I'm using the mediator design pattern.
I'm trying to avoid deadlocks, which is (from what I understand) for example when a thread has a lock on a variable res1 but needs a lock on variable res2. The other thread needs the lock for res1 but has the lock for res2 - resulting in a deadlock, right?
Assuming my understanding of deadlocks are correct, then my question is whether or not I have solved the issue of deadlock in this code?
I have two synchronized methods and two threads.
public class Producer extends Thread {
private Mediator med;
private int id;
private static int count = 1;
public Producer(Mediator m) {
med = m;
id = count++;
}
public void run() {
int num;
while(true) {
num = (int)(Math.random()*100);
med.storeMessage(num);
System.out.println("P-" + id + ": " + num);
}
}
}
public class Consumer extends Thread {
private Mediator med;
private int id;
private static int count = 1;
// laver kopling over til mediator
public Consumer(Mediator m) {
med = m;
id = count++;
}
public void run() {
int num;
while(true) {
num = med.retrieveMessage();
System.out.println("C" + id + ": " + num);
}
}
}
public class Mediator {
private int number;
private boolean slotFull = false;
public synchronized void storeMessage(int num) {
while(slotFull == true) {
try {
wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
slotFull = true;
number = num;
notifyAll();
}
public synchronized int retrieveMessage() {
while(slotFull == false) {
try {
wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
slotFull = false;
notifyAll();
return number;
}
}
public class MediatorTest {
public static void main(String[] args) {
Mediator mb = new Mediator();
new Producer(mb).start();
new Producer(mb).start();
new Producer(mb).start();
new Consumer(mb).start();
new Consumer(mb).start();
}
}
for example when a thread has a lock on a variable res1 but needs a lock on variable res2
What matters is not that there are two variables, what matters is that there must be two (or more) locks.
The names "res1" and "res2" are meant to suggest two resources each of which may have one or more variables, and each of which has its own lock. Here's where you get into trouble:
final Object lock1 = new Object();
final Object lock2 = new Object();
public void method1() {
synchronized (lock1) {
// Call Thread.sleep(1000) here to simulate the thread losing its time slice.
synchronized(lock2) {
doSomethingThatRequiresBothLocks
}
}
}
public void method2() {
synchronized (lock2) {
// Do the same here 'cause you can't know which thread will get to run first.
synchronized(lock1) {
doSomethingElseThatRequiresBothLocks()
}
}
}
If thread A calls method1(), there is a very small chance that it could lose its time slice (i.e., turn to run) just after it successfully locks lock1, but before it locks lock2.
Then, while thread A is waiting its turn to run again, thread B calls method2(). Thread B will be able to lock lock2, but then it gets stuck because lock1 is locked by thread A. Furthermore, when thread A gets to run again, it will immediately be blocked when it tries to lock lock2 which is owned by thread B. Neither thread will ever be able to continue from that point.
In real code, it's never so obvious. When it happens in real-life, it usually is because of some unforseen interaction between code from two or more different modules that may not even be aware of each other, but which access the same common resources.
Your understanding of the basic deadlock problem is correct. With your second question about validity of your solution to the deadlock problem, you've only got 1 lock, so I'd say "yes" by default, since the deadlock you described isn't possible in this situation
I agree with what #ControlAltDel has said. And your understanding of a deadlock matches mine. Whereas there are a few different ways in which a deadlock can manifest itself, the way you describe -- inconsistently acquiring multiple monitors by involved threads (methods) causes deadlock.
Another way would be to (for example,) sleep while holding a lock. As you coded correctly, when the producer finds that slotFull = true, it waits, giving up the lock, so the other thread (consumer, which is sharing the same instance of Mediator with producer) can make progress potentially causing this thread also to make progress after it gets a notification. If you had chosen to call Thread.sleep() instead (naively hoping that someone will cause the sleep to end when the condition would be false), then it would cause a deadlock because this thread is sleeping, still holding the lock, denying access to the other thread.
Every object has one lock which restrict multiple threads to access same block of code or method when you use synchronized keyword.
Coming to your problem, it will not deadlock.
If you have two independent attribute in a class shared by multiple threads, you must synchronized the access to each variable, but there is no problem if one thread is accessing one of the attribute and another thread accessing the other at the same time.
class Cinema {
private long vacanciesCinema1; private long vacanciesCinema2;
private final Object controlCinema1, controlCinema2;
public Cinema() {
controlCinema1 = new Object();
controlCinema2 = new Object();
vacanciesCinema1 = 20;
vacanciesCinema2 = 20;
}
public boolean sellTickets1(int number) {
synchronized (controlCinema1) {
if (number < vacanciesCinema1) {
vacanciesCinema1 -= number;
return true;
} else {
return false;
}
}
}
public boolean sellTickets2(int number) {
synchronized (controlCinema2) {
if (number < vacanciesCinema2) {
vacanciesCinema2 -= number;
return true;
} else {
return false;
}
}
}
public boolean returnTickets1(int number) {
synchronized (controlCinema1) {
vacanciesCinema1 += number;
return true;
}
}
public boolean returnTickets2(int number) {
synchronized (controlCinema2) {
vacanciesCinema2 += number;
return true;
}
}
public long getVacanciesCinema1() {
return vacanciesCinema1;
}
public long getVacanciesCinema2() {
return vacanciesCinema2;
}
}
class TicketOffice1 implements Runnable {
private final Cinema cinema;
public TicketOffice1(Cinema cinema) {
this.cinema = cinema;
}
#Override
public void run() {
cinema.sellTickets1(3);
cinema.sellTickets1(2);
cinema.sellTickets2(2);
cinema.returnTickets1(3);
cinema.sellTickets1(5);
cinema.sellTickets2(2);
cinema.sellTickets2(2);
cinema.sellTickets2(2);
}
}
public class CinemaMain {
public static void main(String[] args) {
Cinema cinema = new Cinema();
TicketOffice1 ticketOffice1 = new TicketOffice1(cinema);
Thread thread1 = new Thread(ticketOffice1, "TicketOffice1");
TicketOffice2 ticketOffice2 = new TicketOffice2(cinema);
Thread thread2 = new Thread(ticketOffice2, "TicketOffice2");
thread1.start();
thread2.start();
try {
thread1.join();
thread2.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.printf("Room 1 Vacancies: %d\n", cinema.getVacanciesCinema1());
System.out.printf("Room 2 Vacancies: %d\n", cinema.getVacanciesCinema2());
}
}
Consider the following piece of code -
class MyThread extends Thread {
private int x = 5;
public void run() {
synchronized (this) // <-- what does it mean?
{
for (int i = 0; i < x; i++) {
System.out.println(i);
}
notify();
}
}
}
class Test {
public static void main(String[] args) {
MyThread m = new MyThread();
m.start();
synchronized (m) {
try {
m.wait();
} catch (InterruptedException e) {
}
}
}
}
In the above example, does Thread m acquire the lock on itself?
The current thread acquires the lock on the associated instance of the MyThread class.
The synchronized(this) is locking the same object as synchronized(m) in main().
Finally,
public void run() {
synchronized (this) {
is exactly equivalent to
public synchronized void run() {
Yes, that's exactly what it means. The thread acquires a lock on the instance of the class (MyThread).
You have to see it as any other java object. what you have typed means that other threads can't access this java object (independently if it was a thread instance or not because it doesn't make difference.
public class ThreadTest
{
public static Integer i = new Integer(0);
public static void main(String[] args) throws InterruptedException
{
ThreadTest threadTest = new ThreadTest();
Runnable odd = threadTest.new Numbers(1, "thread1");
Runnable even = threadTest.new Numbers(0, "thread2");
((Thread) odd).start();
((Thread) even).start();
}
class Numbers extends Thread
{
int reminder;
String threadName;
Numbers(int reminder, String threadName)
{
this.reminder = reminder;
this.threadName = threadName;
}
#Override
public void run()
{
while (i < 20)
{
synchronized (i)
{
if (i % 2 == reminder)
{
System.out.println(threadName + " : " + i);
i++;
i.notify();
}
else
{
try
{
i.wait();
}
catch (InterruptedException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}
}
}
}
You can't synchronize on i because it changes during execution of your program.
Since Integer in Java is immutable, after executing i++ i will contain a reference to another object, not the object you have synchronized on. So, you can't call wait()/notify() on this new object, because these methods may be only called on the object you are synchronized on, otherwise you get IllegalMonitorStateException.
You need to synchronize on some other object that doesn't change during execution. For example, you may create a separate object for this purpose:
public class ThreadTest {
public static Integer i = new Integer(0);
public static Object lock = new Object();
...
class Numbers extends Thread {
...
#Override
public void run() {
...
synchronized (lock) {
...
lock.notify();
...
lock.wait();
...
}
}
}
}
This line:
i++;
is equivalent to:
i = i + 1;
which (due to autoboxing) becomes something like:
i = new Integer(i.intValue() + 1);
So, when you call i.notify() you are synchronized on the old i, not the new one.
I'd suggest changing i into an ordinary int variable, and create a separate object to synchronize on:
static int i = 0;
static Object iMonitor = new Object();
As documentation states the exception is thrown when
the current thread is not the owner of the object's monitor
It also states that
This method should only be called by a thread that is the owner of this object's monitor.
And this condition can be obtained by
By executing a synchronized instance method of that object.
By executing the body of a synchronized statement that synchronizes on the object.
For objects of type Class, by executing a synchronized static method of that class.
You could try calling the wait method from inside the class that uses i. This could be done by extending the class and writing two new methods for notify and wait..
You cannot put wait() and notify() in the same synchronized block because that will just cause a deadlock. Make sure only the wait and notify functions are wrapped with a synchronized block like this:
synchronized (i) {
i.wait(); // or i.notify();
}
How thread-safe is enum in java?
I am implementing a Singleton using enum (as per Bloch's Effective Java),
should I worry at all about thread safety for my singleton enum?
Is there a way to prove or disprove that it is thread safe?
// Enum singleton - the preferred approach
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}
Thanks
As #Mike is saying, creation of enum is guaranteed to be thread safe. However, methods that you add to an enum class do not carry any thread safety guarantee. In particular, the method leaveTheBuilding may be executed, concurrently, by multiple threads. If this method has side effects (changes the state of some variable) then you need to think about protecting it (i.e., make it synchronized) or parts thereof.
Customized Enum Definition may be not thread safe. For example,
RoleEnum.java:
package com.threadsafe.bad;
public enum RoleEnum {
ADMIN(1),
DEV(2),
HEAD(3);
private Integer value;
private RoleEnum(Integer role){
this.value=role;
}
public static RoleEnum fromIntegerValue(Integer role){
for(RoleEnum x : values()){
if(x.value == role ){
return x;
}
}
return RoleEnum.HEAD;
}
Class<?> buildFromClass;
public void setBuildFromClass(Class<?> classType){
buildFromClass=classType;
}
public Class<?> getBuildFromClass(){
return this.buildFromClass;
}
}
Main.java:
package com.threadsafe.bad;
public class Main {
public static void main(String[] args) {
// TODO Auto-generated method stub
Thread threadA = new Thread(){
public void run(){
System.out.println("A started");
RoleEnum role;
role=RoleEnum.fromIntegerValue(1);
System.out.println("A called fromIntegerValue");
role.setBuildFromClass(String.class);
System.out.println("A called setBuildFromClass and start to sleep");
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("Thread A: "+role.getBuildFromClass());
}
};
Thread threadB = new Thread(){
public void run(){
System.out.println("B started");
RoleEnum role;
role=RoleEnum.fromIntegerValue(1);
role.setBuildFromClass(Integer.class);
System.out.println("B called fromIntegerValue&setBuildFromClass and Start to sleep");
try {
Thread.sleep(20000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("B waked up!");
System.out.println("Thread B: "+ role.getBuildFromClass());
}
};
threadA.start();
threadB.start();
}
}
Sometimes the output will be:
B started
B called fromIntegerValue&setBuildFromClass and Start to sleep
A started
A called fromIntegerValue
A called setBuildFromClass and start to sleep
Thread A: class java.lang.String
B waked up!
Thread B: class java.lang.String <-We expect java.lang.Integer
Sometimes the output will be:
A started
A called fromIntegerValue
A called setBuildFromClass and start to sleep
B started
B called fromIntegerValue&setBuildFromClass and Start to sleep
Thread A: class java.lang.Integer <-We expect java.lang.String
B waked up!
Thread B: class java.lang.Integer
This technique is absolutely thread-safe. An enum value is guaranteed to only be initialized once, ever, by a single thread, before it is used. However, I'm not sure whether it is when the enum class is loaded or the first time the enum value itself is accessed. Using this technique is actually a bit safer than other techniques, because there is not even a way with reflection to get a second copy of your enum-based singleton.
Adding synchronized avoids inconsistent state with enums.
Code below will run will lock nicely alway printing "One". However when you comment out synchronized there will be other values printed too.
import java.util.Random;
import java.util.concurrent.atomic.AtomicInteger;
public class TestEnum
{
public static AtomicInteger count = new AtomicInteger(1);
public static enum E
{
One("One"),
Two("Two");
String s;
E(final String s)
{
this.s = s;
}
public void set(final String s)
{
this.s = s;
}
public String get()
{
return this.s;
}
}
public static void main(final String[] args)
{
doit().start();
doit().start();
doit().start();
}
static Thread doit()
{
return new Thread()
{
#Override
public void run()
{
String name = "MyThread_" + count.getAndIncrement();
System.out.println(name + " started");
try
{
int i = 100;
while (--i >= 0)
{
synchronized (E.One)
{
System.out.println(E.One.get());
E.One.set("A");
Thread.sleep(new Random().nextInt(100));
E.One.set("B");
Thread.sleep(new Random().nextInt(100));
E.One.set("C");
Thread.sleep(new Random().nextInt(100));
E.One.set("One");
System.out.println(E.One.get());
}
}
}
catch (InterruptedException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println(name + " ended");
}
};
}
}