Java Concurrency - Revision history

Suhridk at 22:14, 3 October 2012

2012-10-03T22:14:53Z

Suhridk: /* Delaying Threads */

2012-01-11T17:51:44Z

Delaying Threads

Suhridk: /* Signals */

2012-01-06T19:20:48Z

Signals

Suhridk: /* Semaphore */

2012-01-06T18:45:24Z

Semaphore

Suhridk: /* Semaphore */

2012-01-06T18:45:04Z

Semaphore

Suhridk: /* Semaphore */

2012-01-06T18:41:08Z

Semaphore

Suhridk: /* Semaphore */

2012-01-06T18:32:49Z

Semaphore

Suhridk at 18:24, 6 January 2012

2012-01-06T18:24:35Z

Suhridk: /* Java Memory Model */

2011-12-30T18:09:06Z

Java Memory Model

Suhridk: /* Condition Synchronization */

2011-12-30T02:17:49Z

Condition Synchronization

← Older revision		Revision as of 22:14, 3 October 2012
Line 376:		Line 376:


−	[[Category:~~CRTP~~]]	+	[[Category:RealtimeJava]]

@@ Line 225: / Line 225: @@
 * Timeout on waiting. Threads can wait() indefinitely for a notify. However wait() can also be specified with a timeout.
 * It is not possible to know if thread has woken up after timeout or if someone has called notify.
 == Thread Groups ==

← Older revision		Revision as of 19:20, 6 January 2012
Line 310:		Line 310:
	= Signals =		= Signals =

		+	* Often a thread needs to wait for a signal from another thread before it can proceed. There are various types of signals. A persistent signal (sometimes called a latch or a gate ) is a signal that remains set until a single thread has received it.
		+	* Example:

		+	<syntaxhighlight lang="java5">
		+
		+	package net.suhrid;
		+
		+	public class PersistentSignal {
		+
		+	private boolean arrived = false;
		+
		+	public synchronized void waitS() throws InterruptedException {
		+	while(!arrived) wait();
		+	arrived = false;
		+	}
		+
		+	public synchronized void signal() {
		+	arrived = true;
		+	notify();
		+	}
		+
		+	public static void main(String[] args) {
		+
		+	final PersistentSignal ps = new PersistentSignal();
		+
		+	Thread t1 = new Thread() {
		+	public void run() {
		+	try {
		+	System.out.println("T1 computing part 1");
		+	Thread.sleep(2000);
		+	System.out.println("Done Part 1 .. signalling");
		+	ps.signal();
		+	System.out.println("T1 computing part 2");
		+	Thread.sleep(2000);
		+	} catch(InterruptedException e) {
		+	}
		+	}
		+	};
		+
		+	Thread t2 = new Thread() {
		+	public void run() {
		+	try {
		+	System.out.println(" T2 Waiting for a signal");
		+	ps.waitS();
		+	} catch (InterruptedException e) {
		+	}
		+
		+	System.out.println(" T2 Received a signal from t1");
		+	}
		+	};
		+
		+	t1.start();
		+	t2.start();
		+
		+	}
		+	}
		+
		+	</syntaxhighlight>
		+
		+	* A transient signal (or pulse ) is a signal that releases one or more waiting threads but is lost if no threads are waiting.


	[[Category:CRTP]]		[[Category:CRTP]]

@@ Line 307: / Line 307: @@
 * Tunnel can have a counting semaphrore initialized to max number of cars it can allow.
 * Each car then has to call entryProtocol() which calls semaphore.acquire, make the journey and then call exitProtocol() which calls semaphore.release().
 [[Category:CRTP]]

← Older revision		Revision as of 18:45, 6 January 2012
Line 301:		Line 301:

	</syntaxhighlight>		</syntaxhighlight>
		+
		+	* Now this semaphore can be used to control access to a certain resource by a specified number of threads.
		+	* For e.g. a tunnel (resource) where only a certain number of cars (threads) can use at a any given time.
		+
		+	* Tunnel can have a counting semaphrore initialized to max number of cars it can allow.
		+	* Each car then has to call entryProtocol() which calls semaphore.acquire, make the journey and then call exitProtocol() which calls semaphore.release().
		+


	[[Category:CRTP]]		[[Category:CRTP]]

← Older revision		Revision as of 18:41, 6 January 2012
Line 274:		Line 274:
	* 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''' (same functionality that mutexes have).		* 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''' (same functionality that mutexes have).

		+	<syntaxhighlight lang="java5">

		+	public class Semaphore {
		+
		+	protected int value;
		+
		+	public Semaphore(int initial) {
		+	value = initial;
		+	}
		+
		+	public synchronized void acquire() throws InterruptedException {
		+	while(value==0) wait();
		+	value--;
		+	}
		+
		+	public synchronized void release() {
		+	value++;
		+	notify();
		+	}
		+
		+	public static void main(String[] args) {
		+
		+	}
		+
		+	}
		+
		+	</syntaxhighlight>


	[[Category:CRTP]]		[[Category:CRTP]]

← Older revision		Revision as of 18:32, 6 January 2012
Line 269:		Line 269:

	== Semaphore ==		== Semaphore ==
		+
		+	* A semaphore is a technique for coordinating or synchronizing activities in which multiple processes compete for the same resource.
		+	* A useful way to think of a semaphore is as a record of how many units of a particular resource are available, coupled with operations to safely (i.e. without race conditions) adjust that record as units are required or become free, and if necessary wait until a unit of the resource becomes available.
		+	* 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''' (same functionality that mutexes have).
		+



	[[Category:CRTP]]		[[Category:CRTP]]

@@ Line 265: / Line 265: @@
 ** Thread compatible / Not Thread safe: Instance are mutable, to use them concurrently clients must externally synchronize each method invocation. e.g. ArrayList, Map etc.
 ** Thread hostile: Not safe for concurrent use even if methods are surrounded by external synchronization. Usually happens when static data is modified without synchronization or accessing external data.
 [[Category:CRTP]]

@@ Line 150: / Line 150: @@
 * Not only do they enable mutual exclusive access to a shared resource but they also '''ensure that data written by one thread (the writer) becomes visible to another thread (the reader).'''
 * The visibility of data written by the writer is only guaranteed when it releases a lock that is subsequently acquired by the reader.
 == Thread Priorities ==

← Older revision		Revision as of 02:17, 30 December 2011
Line 87:		Line 87:
	* A condition variable queue is usually ordered either in a first-in-first-out manner or according to the priority of the waiting threads. Some monitors also support a third operation called NotifyAll.		* A condition variable queue is usually ordered either in a first-in-first-out manner or according to the priority of the waiting threads. Some monitors also support a third operation called NotifyAll.

		+	* wait() : Causes the current thread to wait until another thread invokes the notify() method or the notifyAll() method for this object.
		+	** The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAll method. The thread then waits until it can re-obtain ownership of the monitor and resumes execution.
		+
		+	* wait(long millis) : The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until either of the following two conditions has occurred:
		+	**Another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAll method.
		+	**The timeout period, specified by timeout milliseconds plus nanos nanoseconds arguments, has elapsed.
		+	* '''Important: The thread then waits until it can re-obtain ownership of the monitor and resumes execution.'''
		+
		+	* notify() : Wakes up a single thread that is waiting on this object's monitor. If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. A thread waits on an object's monitor by calling one of the wait methods.
		+	** The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened thread enjoys no reliable privilege or disadvantage in being the next thread to lock this object.
		+	**This method should only be called by a thread that is the owner of this object's monitor.
		+
		+	* notifyAll() : Wakes up all threads that are waiting on this object's monitor. A thread waits on an object's monitor by calling one of the wait methods.
		+
		+	** The awakened threads will not be able to proceed until the current thread relinquishes the lock on this object. The awakened threads will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened threads enjoy no reliable privilege or disadvantage in being the next thread to lock this object.

	* In Java, every object is associated with a mutual exclusion lock.		* In Java, every object is associated with a mutual exclusion lock.