G52CON: Concepts of Concurrency

Transcription

1 G52CON: Concepts of Concurrency Lecture 11 Synchronisation in Java II Natasha Alechina School of Computer Science

2 Outline of this lecture Mutual exclusion in Java continued (next lecture: more on condition synchronization) synchronized methods and statements in Java limitations of synchronized methods and statements external locks: extra flexibility (and greater potential for errors) Readers and Writers ReadWriteLocks G52CON Lecture 11: Synchronisation in Java II 2

3 Summary of the previous lecture every Java object has an intrinsic lock or monitor `inside it a thread which needs an exclusive and consistent access to the object (recall atomicity, visibility, ordering...) can acquire the object s lock (enter its monitor), do its work, and then release the lock (exit the monitor) the thread which acquired the object s intrinsic lock owns the lock until it releases it; while it owns the lock, no other thread can acquire it. If another thread attempts to acquire the lock, it will block in the object s monitor entry queue a thread which invokes synchronized method foo() on object o acquires o s intrinsic lock, same for executing synchronized(o) { G52CON Lecture 11: Synchronisation in Java II 3

4 Summary of the previous lecture If a thread is executing a synchronized method foo() on an object o or if it is executing statements in synchronized(o) { and an exception is thrown method returns abnormally, the end of synchronized statements is not reached the lock on o is released. This means that a Java program cannot deadlock because it is waiting for a lock to be released by a dead thread, for example. G52CON Lecture 11: Synchronisation in Java II 4

5 Fully synchronised objects The safest (but not necessarily the best) design strategy for mutual exclusion is to use fully synchronized objects in which: all methods are synchronized there are no public fields or other encapsulation violations all methods are finite (so cannot get a lock and go into an infinite loop) all fields are initialised to a consistent state in constructors the state of the object is consistent at both the beginning and end of each method (even in the presence of exceptions). G52CON Lecture 11: Synchronisation in Java II 5

6 Limitations of synchronized synchronized methods and blocks have a number of limitations: there is no way to back off from an attempt to acquire a lock, e.g., to timeout or cancel a lock attempt following an interrupt: this may waste time synchronisation within methods and blocks limits use to strict block structured locking: cannot do hand-over-hand locking (example later) there is no way to alter the semantics of a lock, e.g., read vs write protection there is no access control for condition synchronisation One way these problems can be overcome is by using utility classes to control locking. G52CON Lecture 11: Synchronisation in Java II 6

7 Limitations of synchronized synchronized methods and blocks have a number of limitations: there is no way to back off from an attempt to acquire a lock, e.g., to timeout or cancel a lock attempt following an interrupt synchronisation within methods and blocks limits use to strict block structured locking there is no way to alter the semantics of a lock, e.g., read vs write protection there is no access control for condition synchronisation G52CON Lecture 11: Synchronisation in Java II 7

8 Handling interrupts Threads should periodically check their interrupt status, and if interrupted, shut down: a good place to check is before calling a synchronized method, as we may spend a long time contending for the lock on s blocking waiting for a lock can result in threads being unresponsive to interrupts an interrupted thread may acquire the lock and only after that discover that it is interrupted, so it should release the lock and shut down this wastes time G52CON Lecture 11: Synchronisation in Java II 8

9 Example: just acquire the lock public synchronized void P() throws InterruptedException { while (value == 0) { wait(); --value; This is the semaphore method from the last lecture. Here a thread would just try to execute P() (acquire a lock on the semaphore object). It may already be interrupted when it acquires it so should release it as soon as it notices that its interrupted status is true (hopefully before it starts blocking in wait()). G52CON Lecture 11: Synchronisation in Java II 9

10 Example: checking for interrupts public void P() throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); synchronized(this) { while (value == 0) wait(); --value; Here is a more defensive/civilised version (Lea): the method is not synchronized, and before the synchronized statements the thread checks its interrupted status. G52CON Lecture 11: Synchronisation in Java II 10

11 Backing off from lock attempts Even if we check for interrupts before attempting to acquire a lock on a synchronized method or block a thread which is trying to acquire the lock must be prepared to wait indefinitely however, we can implement more flexible locking protocols using utility classes G52CON Lecture 11: Synchronisation in Java II 11

12 The Lock interface java.util.concurrent defines a Lock interface and a number of utility classes (e.g., ReentrantLock) which implement the interface: public interface Lock { void lock(); void lockinterruptibly() throws InterruptedException; boolean trylock(); boolean trylock(long timeout, TimeUnit unit) throws InterruptedException; void unlock(); Condtion newcondition(); G52CON Lecture 11: Synchronisation in Java II 12

13 Replacing synchronized blocks A Lock can be used to replace blocks of the form: synchronized(this) { /* body */ with a before/after construction, e.g.: Lock lock = new ReentrantLock(); lock.lock(); try { // body: catch & handle exceptions if necessary finally { lock.unlock(); G52CON Lecture 11: Synchronisation in Java II 13

14 Replacing synchronized blocks A Lock can be used to replace blocks of the form: synchronized(this) { /* body */ with a before/after construction, e.g.: Lock lock = new ReentrantLock();// or some other lock lock.lock();// or lockinterruptibly() etc. try { // body: catch & handle exceptions if necessary finally { lock.unlock();// now we have to release the lock ourselves or there might be a deadlock! G52CON Lecture 11: Synchronisation in Java II 14

15 Backing off from lock attempts with Lock Unlike synchronzied, the Lock interface supports: polled lock acquisition: trylock() allows control to be regained if all the required locks can t be acquired timed lock acquisition: trylock(timeout) allows control to be regained if the time available for an operation runs out interruptible lock acquisition: lockinterruptibly allows an attempt to aquire a lock to be interrupted (so solves the first problem we discussed, with backing out of lock acquisition after an interrupt) G52CON Lecture 11: Synchronisation in Java II 15

16 Limitations of synchronized synchronized methods and blocks have a number of limitations: there is no way to back off from an attempt to acquire a lock, e.g., to timeout or cancel a lock attempt following an interrupt synchronisation within methods and blocks limits use to strict block structured locking there is no way to alter the semantics of a lock, e.g., read vs write protection there is no access control for condition synchronisation G52CON Lecture 11: Synchronisation in Java II 16

17 Locking is block structured synchronized methods and blocks limit use to strict block structured locking a lock is always released in the same block as it was acquired, regardless of how control exits the block e.g., a lock can t be acquired in one method or block and released in another this prevents potential coding errors, but can be inflexible again we can use utility classes to implement non-block structured locking G52CON Lecture 11: Synchronisation in Java II 17

18 Example: ListUsingLocks for example, we can use Lock objects to lock the nodes of linked list during operations that traverse the list the lock for the next node must be obtained while the lock for the current node is still being held after acquiring the next lock, the current lock is released this allows extremely fine-grained locking and increases potential concurrency only worthwhile in situations where there is a lot of contention. G52CON Lecture 11: Synchronisation in Java II 18

19 Example: ListUsingLocks class ListUsingLocks { static class Node { Object item; Node next; Lock lock = new ReentrantLock(); Node(Object x, Node n) { item = x; next = n; protected Node head; protected synchronized Node gethead() { return head; public synchronized add(object x) { head = new Node(x, head); G52CON Lecture 11: Synchronisation in Java II 19

20 ListUsingLocks 2 boolean search(object x) throws InterruptedException { Node p = gethead(); if (x == null p == null) return false; Node nextp; p.lock.lock(); for (;;) { try { if (x.equals(p.item)) return true; if ((nextp = p.next()) == null) return false; nextp.lock.lock(); finally { p.lock.unlock(); p = nextp; // other methods omitted... G52CON Lecture 11: Synchronisation in Java II 20

21 ListUsingSynchronized // Broken, do not use... boolean search(object x) throws InterruptedException { Node p = gethead(); if (x == null p == null) return false; Node nextp; for (;;) { synchronized(p) { if (x.equals(p.item)) return true; if ((nextp = p.next()) == null) return false; synchronized(nextp) { // can t release the lock on p here... p = nextp; G52CON Lecture 11: Synchronisation in Java II 21

22 Limitations of synchronized synchronized methods and blocks have a number of limitations: there is no way to back off from an attempt to acquire a lock, e.g., to timeout or cancel a lock attempt following an interrupt synchronisation within methods and blocks limits use to strict block structured locking there is no way to alter the semantics of a lock, e.g., read vs write protection there is no access control for condition synchronisation G52CON Lecture 11: Synchronisation in Java II 22

23 Altering the semantics of a lock With synchronized there is no way to alter the semantics of a lock, e.g., read vs write protection this makes it difficult to solve selective mutual exclusion problems, like the Readers and Writers problem (next slide) again, these problems can be overcome is by using utility classes to control locking G52CON Lecture 11: Synchronisation in Java II 23

24 Readers and Writers Given a shared file and a collection of processes that need to access and update the file: reader processes only need to read the file writer processes need to both read and write the file We assume that the file is initially in a consistent state each read or write executed in isolation transforms the file into a new consistent state. G52CON Lecture 11: Synchronisation in Java II 24

25 Correctness vs efficiency The Readers and Writers problem is a special case of the general problem of a number of processes all of which may both read and write to a file: any solution to the general problem will also be a correct solution to the Readers and Writers problem however (much) more efficient solutions are possible for the Readers and Writers problem In general, an efficient solution depends on the specifics of the problem. G52CON Lecture 11: Synchronisation in Java II 25

26 A simple solution One solution to the readers and writers problem would be to make all accesses to the file mutually exclusive: at most one process, whether reader or writer would be able to access the file at a time this is simple and correct but, in general, the performance of such an approach is unacceptable G52CON Lecture 11: Synchronisation in Java II 26

27 Synchronisation requirements To ensure correctness and for maximum efficiency (concurrency) and we require that: if a writer is writing to the file, no other writer may write to the file and no reader may read it; and any number of readers may simultaneously read the file. G52CON Lecture 11: Synchronisation in Java II 27

28 Scope of the problem The Readers and Writers problem is an abstraction of a common class of concurrency problems: the file can be any shared resource, e.g., an area of memory, or a database reading and writing can be any operations: reading doesn t change the resource readers can be allowed to proceed concurrently writing must be mutually exclusive of all readers and all other writers G52CON Lecture 11: Synchronisation in Java II 28

29 Selective mutual exclusion a critical section is a section of code belonging to a process that accesses shared variables, where, to ensure correct behaviour, the critical section must be given mutually exclusive access to the shared variables mutual exclusion is the requirement that, at any given time, at most one process is executing its critical section mutual exclusion applies between critical sections In the Readers and Writers problem, reading need not be not mutually exclusive of reading, but writing must be mutually exclusive of reading and writing. G52CON Lecture 11: Synchronisation in Java II 29

30 The ReadWriteLock interface java.util.concurrent defines a ReadWriteLock interface and a number of utility classes (e.g., ReentrantReadWriteLock) which implement the interface: public interface ReadWriteLock { Lock readlock(); // returns the read lock Lock writelock(); // returns the write lock G52CON Lecture 11: Synchronisation in Java II 30

31 ReadWriteLocks A ReadWriteLock maintains a pair of associated Locks, one for readonly operations and one for writing: the readlock may be held simultaneously by multiple reader threads, so long as there are no writers the writelock is exclusive since the readlock and writelock implement the Lock interface, they support polled, timed and interruptible locking G52CON Lecture 11: Synchronisation in Java II 31

32 Read-Write locks A read-write lock can allow for a greater level of concurrency in accessing shared data than that permitted by a mutual exclusion lock if: the methods in a class can be separated into those that only read internally held data and those that read and write reading is not permitted while writing methods are executing the application has more readers than writers the methods are time consuming, so it pays to introduce more overhead in order to allow concurrency among reader threads. e.g, in accessing a dictionary which is frequently read but seldom modified G52CON Lecture 11: Synchronisation in Java II 32

33 Example RWDictionary class RWDictionary { private final Map<String, Data> m = new TreeMap<String, Data>(); private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); private final Lock r = rwl.readlock(); private final Lock w = rwl.writelock(); // methods follow... G52CON Lecture 11: Synchronisation in Java II 33

34 Example RWDictionary readers // Reader method (does not update the map) public Data get(string key) { r.lock(); try { return m.get(key); finally { r.unlock(); G52CON Lecture 11: Synchronisation in Java II 34

35 Example RWDictionary writers // Writer method (changes the map) public Data put(string key, Data value) { w.lock(); try { return m.put(key, value); finally { w.unlock(); G52CON Lecture 11: Synchronisation in Java II 35

36 Mutual exclusion summary all the synchronisation primitives we have looked at are equivalent in the sense that they all have the same expressive power while it is often helpful to take advantage of the higher level of abstraction offered by monitors, there are situations when other forms of synchronisation are required and we can implement any of these using any of the primitives. more complex forms of locking can and are defined in terms of primitives like Lock. at each level of abstraction we see this pattern of acquiring and releasing locks. G52CON Lecture 11: Synchronisation in Java II 36

37 Formal coursework Implement a Hotel booking system which can be used by multiple concurrent threads (Java program page essay) Methods of Hotel.java class: boolean roombooked(int[] days, int roomnum) boolean bookroom(string bookingref, int[] days, int roomnum) boolean updatebooking(string bookingref, int[] days, int roomnum) throws NoSuchBookingException void cancelbooking(string bookingref) throws NoSuchBookingException Description on Deadline 20 March, submission on cw (coursework id 190). G52CON Lecture 11: Synchronisation in Java II 37

38 The next lecture Condition synchronisation in Java Suggested reading: Lea (2000), chapter 3. G52CON Lecture 11: Synchronisation in Java II 38