Submitted by heartin on Fri, 10/16/2015 - 00:26
Let us consider an example program that deadlocks, and then see how we could have avoided that. Below example is an example for a lock ordering deadlock.
The DeadLockExample class has two objects lockObject1 and lockObject2, which we will use as locks for synchronizing.
We will have two Runnables, which we will use for creating two threads: Runnable1 synchronizes on lockObject1 and try to get lockObject2, and Runnable2 synchronizes on lockObject2 and try to get lockObject1.
Submitted by heartin on Sat, 11/08/2014 - 06:06
Submitted by heartin on Sat, 11/08/2014 - 06:01
Java concurrency package give you the ability to use explicit locks. With explicit locks, you can see if a lock is available and acquire only if it is available. This way you can avoid deadlocks. We already wrote a deadlock simulation program without using explicit locks and now we will write the same program using explicit locks. This is just a rewrite and hence will also deadlock like hte older one.
Submitted by heartin on Fri, 11/07/2014 - 01:16
Lock ordering deadlock is caused when using different order of acquiring locks when locking on multiple objects. The solution is also simple: either acquire only one lock at a time or when acquiring multiple locks, acquire them in same order, whenever feasible.
Submitted by heartin on Fri, 11/07/2014 - 01:09
According to the book Java Concurrency in Practice, there are different types of deadlocks such as Lock ordering deadlocks, Open call deadlocks and Resource deadlocks. All the examples in this note are inspired from the examples given in the book Java Concurrency in Practice.
Lock ordering deadlock is caused when using different order of acquiring locks when locking on multiple objects.
Submitted by heartin on Mon, 07/21/2014 - 20:26
Deadlock involves a mutual interdependence between two or more threads.
Submitted by heartin on Wed, 07/10/2013 - 11:27
A Future interface provides methods to check if the computation is complete, to wait for its completion, and to retrieve the result of the computation. The result is retrieved using method get when the computation has completed, and it blocks until it is ready. If a task completes by throwing an exception, corresponding Future.get rethrows it wrapped in an ExecutionException; and if it was cancelled, get throws CancellationException. The submit method in the ExecutorService return a Future when you submit a Runnable or a Callable.
Submitted by heartin on Wed, 07/10/2013 - 02:17
The interface ExecutorService extends Executor and provides methods to manage termination of an Executor and methods that can produce a Future for tracking progress of one or more asynchronous tasks. An ExecutorService can be shut down, which will cause it to reject new tasks. Method submit extends base method Executor.execute(java.lang.Runnable) by creating and returning a Future that can be used to cancel execution and/or wait for completion.
Submitted by heartin on Tue, 07/09/2013 - 19:40
A task is a logical unit of work We can execute tasks sequentially or in parallel, and threads are the mechanism by which tasks can run in parallel. In Java, a task can be a Runnable or a Callable. Executors in Java concurrency package are the best way for executing tasks in a bounded way, and it is advised not to use Thread class directly.
Submitted by heartin on Mon, 07/08/2013 - 06:44
In computer science, particularly in operating systems, a semaphore is a variable or abstract data type that provides a simple but useful abstraction for controlling access, by multiple processes, to a common resource in a parallel programming or a multi user environment. Semaphores which allow an arbitrary resource count are called counting semaphores, while semaphores which are restricted to the values 0 and 1 (or locked/unlocked, unavailable/available) are called binary semaphores.