Only one thread can own a specific monitor

Transcription

1 Java 5

2 Notes Threads inherit their priority and daemon properties from their creating threads The method thread.join() blocks and waits until the thread completes running A thread can have a name for identification Stopping a running thread was possible in old versions of Java, but it is now deprecated Instead, interruption mechanisms should be used (thread.interrupt()) 2

3 Notes isinterupted() can be used by a thread to check if another thread has been interrupted isalive() can be used by a thread to check if another thread is alive join() allows one thread to wait for the completion of another 3

4 Synchronization 4 Monitors are key elements in Java's thread synchronization Every object has a monitor An object's monitor is used as a guardian that watches a block of code (called a critical section) and enables only one thread to enter that code To enter a critical section, a thread must first acquire an ownership over the corresponding monitor

5 Synchronization 5 Only one thread can own a specific monitor If a thread A tries to enter a block under a monitor and a different thread B has already entered that block, A will wait until B releases the monitor and (hopefully) that monitor will be passed to A Hence, monitors are related to as locks When a thread leaves the critical section, the monitor is automatically released Threads awaiting a monitor are blocked

6 6 Synchronization Example 1 synchronizing methods: public class SynchronizedCounter { private int c = 0; public synchronized void increment() { c++; public synchronized void decrement() { c--; public synchronized int value() { return c; The synchronized keyword on a method means that if this is already locked anywhere (on this method or elsewhere) by another thread, we need to wait till this is unlocked before entering the method

7 7 Synchronization Example 2 synchronizing blocks: public void addname(string name) { synchronized(this) { lastname = name; namecount++; namelist.add(name); When synchronizing a block, key for the locking should be supplied (usually would be this) The advantage of not synchronizing the entire method is efficiency

8 8 Synchronization Example 3 synchronizing using different locks: public class TwoCounters { private long c1 = 0, c2 = 0; private Object lock1 = new Object(); private Object lock2 = new Object(); public void inc1() { synchronized(lock1) { c1++; public void inc2() { synchronized(lock2) { c2++; You must be absolutely sure that there is no tie between c1 and c2

9 9 Synchronization Example 4 synchronizing static methods: public class Screen { private static Screen thescreen; private Screen(){ // private c tor public static synchronized Screen getscreen() { if(thescreen == null) { thescreen = new Screen(); return thescreen; It is not the most efficient way to implement Singleton in Java This is a Singleton example

10 10 Synchronization Example 4 synchronizing static methods Having a static method be synchronized means that ALL objects of this type are locked on the method and can get in one thread at a time. The lock is the Class object representing this class. The performance penalty might be sometimes too high needs careful attention!

11 11 Synchronization Example 4 a better singleton: public class Screen { private static Screen thescreen = new Screen(); private Screen(){ // private c tor public static getscreen() { return thescreen; No synchronization

12 Cycle buffer public class LogEntryBase { Entry entries[]; int size; int first=0;int last=0; int current=0; public LogEntryBase() { this(500); public LogEntryBase(int si) { size=si;entries=new Entry[size]; synchronized public void addentry(entry e) { entries[last]=e; last=(last+1) % size; if (last==first) first=(first+1) % size; if (last==current) current=(current+1) % size; synchronized public Entry[] getunread() { Entry ret[]; int ile=0,i,j; if (current==last) return new Entry[0]; if (last<current) ile=size-current+last; else ile=last-current; ret=new Entry[ile]; for (i=0,j=current;i<ile;i++,j=(j+1)%size) ret[i]=entries[j]; current=last;return ret;

13 13 wait(), notify(), notifyall() wait() and notify() allows a thread to wait for an event A call to notifyall() allows all threads that are on wait() with the same lock to be released A call to notify() allows one arbitrary thread that is on a wait() with the same lock to be released Instead of busy wat or sleep loop!

14 wait(), notify(), notifyall() Suppose that an object has some monitor, but conditions disable it from completing the critical section The wait/notify mechanism enables that object to release the monitor and wait until conditions are changed 14

15 wait() The method Object.wait() requires the current thread to own the monitor of the object When called, the current thread releases ownership on the object's monitor stops and waits until some other thread will wake it up and the monitor will be re-obtained 15

16 notify() Like wait, requires the object to own the monitor The method Object.notify() wakes up an arbitrary thread that waits on the monitor of the object Object.notifyAll() wakes all such threads When a thread is waken up, it regularly waits for the monitor to be available (since it called Object.wait()) The thread calling notify should release the monitor for the waiting thread to continue (e.g exit the synchronized scope) 16

17 17 wait(), notify(), notifyall() Example (from public class Drop { // Message sent from producer to consumer private String message; // A flag, True if consumer should wait for // producer to send message, False if producer // should wait for consumer to retrieve message private boolean empty = true;... Flag must be used, never count only on the notify

18 18 wait(), notify(), notifyall() Example (cont ) Must be in synchronized context public class Drop {... public synchronized String take() { // Wait until message is available while (empty) { // we do nothing on InterruptedException // since the while condition is checked anyhow try { wait(); catch (InterruptedException e) { // Toggle status and notify on the status change empty = true; notifyall(); return message;...

19 19 wait(), notify(), notifyall() Example (cont ) Must be in synchronized context public class Drop {... public synchronized void put(string message) { // Wait until message has been retrieved while (!empty) { // we do nothing on InterruptedException // since the while condition is checked anyhow try { wait(); catch (InterruptedException e) { // Toggle status, store message and notify consumer empty = false; this.message = message; notifyall();...

20 20 Sophisticated Primitives Wait and Notify: basis for higher level constructs. general constructs Specific mechanisms make code easier to understand and demand less details when using them: Semaphores Readers-Writers locks.

21 21 Semaphores Object controls bounded number of permits (permit = train ticket): Threads ask semaphore for permit (a ticket). If semaphore has permits available, one permit is assigned to requesting thread. If no permit available, requesting thread is blocked until permit is available when a thread returns permit received earlier

22 22 implementation

23 23 Java Semaphore class properties not re-entrant thread calls acquire() twice, must release() twice! semaphore can be released by a thread other than owner (unlike lock) no ownership. constructor accepts fairness parameter if t1 requested before t2 it will receive first services as tryacquire and managing permits.

24 class Pool { private static final int MAX_AVAILABLE = 100; private final Semaphore available = new Semaphore(MAX_AVAILABLE, true); public Object getitem() throws InterruptedException { available.acquire(); return getnextavailableitem(); public void putitem(object x) { if (markasunused(x)) available.release(); // Not a particularly efficient data structure; just for demo protected Object[] items =... whatever kinds of items being managed protected boolean[] used = new boolean[max_available];

25 protected synchronized Object getnextavailableitem() { for (int i = 0; i < MAX_AVAILABLE; ++i) { if (!used[i]) { used[i] = true; return items[i]; return null; // not reached protected synchronized boolean markasunused(object item) { for (int i = 0; i < MAX_AVAILABLE; ++i) { if (item == items[i]) { if (used[i]) { used[i] = false; return true; else return false; return false;

26 What is a Thread Pool? A collection of threads that are created once (e.g. when a server starts) That is, no need to create a new thread for every client request Instead, the server uses an already prepared thread if there is a free one, or waits until there is a free thread 26

27 Why Using Thread Pools? Thread pools improve resource utilization The overhead of creating a new thread is significant Thread pools enable applications to control and bound their thread usage Creating too many threads in one JVM can cause the system to run out of memory and even crash There is a need to limit the usage of system resources such as connections to a database 27

28 Thread Pools in Servers Thread pools are especially important in client-server applications The processing of each individual task is shortlived and the number of requests is large Servers should not spend more time and consume more system resources creating and destroying threads than processing actual user requests When too many requests arrive, thread pools enable the server to force clients to wait until threads are available 28

29 The Obvious Implementation There is a pool of threads Each task asks for a thread when starting and returns the thread to the pool after finishing When there are no available threads in the pool the thread that initiates the task waits till the pool is not empty What is the problem here? Synchronized model - the client waits until the server takes care of its request 29

30 The Obvious Implementation is Problematic When the pool is empty, the submitting thread has to wait for a thread to be available We usually want to avoid blocking that thread A server may want to perform some actions when too many requests arrive Technically, Java threads that finished running cannot run again 30

31 A Possible Solution Every thread looks for tasks in the queue Task Queue wait() If Q is Empty Worker Threads All the worker threads wait for tasks 31

32 A Possible Solution Task Task Queue Worker Threads A-synchronized model: Launch and forget The number of worker threads is fixed. When a task is inserted to the queue, notify is called 32

33 A Possible Solution Task Task Queue notify() Worker Threads The number of worker threads is fixed. When a task is inserted to the queue, notify is called 33

34 A Possible Solution The task is executed by the thread Task Queue Worker Threads 34

35 A Possible Solution The task is executed by the thread Task Queue Worker Threads The remaining tasks are executed by the other threads 35

36 A Possible Solution When a task ends, the thread is released Task Queue Worker Threads While the Q is not empty, take the task from the Q and run it (if the Q was empty, wait() would have been called) 36

37 A Possible Solution A new task is executed by the released thread Task Queue Worker Threads 37

38 Risks in Using Thread Pools Threads can leak A thread can endlessly wait for an I/O operation to complete For example, the client may stop the interaction with the socket without closing it properly What if task.run() throws a runtime exception (as opposed to other exceptions that a programmer of a client application has to catch in order to succeed compiling)? Solutions: Bound I/O operations by timeouts using wait(time) Catch possible runtime exceptions 38

39 Pool Size What is better: to have a large pool or a small pool? Each thread consumes resources memory, management overhead, etc. A large pool can cause starvation Incoming tasks wait for a free thread A small pool can cause starvation Therefore, you have to tune the thread pool size according to the number and characterizations of expected tasks There should also be a limit on the size of the task queue (why?) 39

40 Executor The class Executors has 2 static methods to create thread pools ExecutorService newfixedthreadpool(int nthreads) Pool of a fixed size ExecutorService newcachedthreadpool() Creates new threads as needed New threads are added to the pool, and recycled ExecutorService has an execute method void execute(runnable command) 40

41 41 The Dining Philosophers Problem

42 42 Let there be one rice bowl in the center Let there be five philosophers Let there be only five chopsticks, one between each of the philosophers

43 43 Let concurrent eating have these conditions 1. A philosopher tries to pick up the two chopsticks immediately on each side Picking up one chopstick is an independent act. It isn t possible to pick up both simultaneously.

44 44 2. If a philosopher succeeds in acquiring the two chopsticks, then the philosopher can eat. Eating cannot be interrupted 3. When the philosopher is done eating, the chopsticks are put down one after the other Putting down one chopstick is an independent act. It isn t possible to put down both simultaneously. Note that under these conditions it would not be possible for two neighboring philosophers to be eating at the same time

45 45 This concurrency control problem has two challenges in it: 1. Starvation Due to the sequence of events, one philosopher may never be able to pick up two chopsticks and eat

46 46 2. Deadlock Due to the sequence of events, each philosopher may succeed in picking up either the chopstick on the left or the chopstick on the right. None will eat because they are waiting/attempting to pick up the other chopstick. Since they won t be eating, they ll never finish and put down the chopstick they do hold