JAVA-BASED REAL-TIME PROGRAMMING

More documents

Recommendations

Info

3. Multi-Threaded Programming by semaphores). When an object has been locked by synchronized (for a method or a blocks), there can be conditions that need to be fulfilled before the operations on the shared data can be fulfilled. Java provides the following support for that situation. 3.3.2 Conditions – wait and notify Consider a buffer with operations put and get. To accomplish mutual exclusion during manipulation of the buffer, those methods are typically declared synchronized. However, both in this case as well as in many other types of monitors, certain conditions may need to be fulfilled before an operation can be completed. For instance, there must be something in the buffer to fetch before get can be performed, and the buffer may not be full in order to let put be carried out. If such conditions can be evaluated before any shared data is manipulated we could simply cancel the operation and make a new call when the status has changed, but we also require: • When waiting for a certain condition to be fulfilled, that thread should be blocked to prevent waste of CPU time (polling or busy wait, possibly leading to starvation of other threads, is not allowed). • When the condition is fulfilled we need a way of waking up the blocked thread(s). • When a thread continues execution after being blocked on some condition, it has to compete for the resource again since we have to ensure that only one thread at a time is executing inside the monitor (i.e., inside the critical region). To accomplish these features, each Java object is equipped with a wait/notify mechanism in terms of the methods wait, notify, and notifyAll according to (see Figure 3-7): wait() The thread executing within the monitor (inside a synchronized method or block) gives up the exclusive access, stepping out to the ’back yard’ containing the condition queue. The runtime system puts the blocked thread in the condition queue, where it typically is inserted in priority order with the thread with the highest priority first. The saved context of the blocked thread, referring to the stack of the thread and thereby to the state of execution, of course contains the state of the half made monitor operation. notify() Threads waiting in the condition queue will remain there until notified by some other thread, or until a timeout occurs as explained later. Threads that inside the monitor change any data that affects conditions that the threads in the condition queue might waiting for, should call 74 2012-08-29 16:05
3.3. Objects providing mutual exclusion – Monitors synchronized(.){ Exclusive area Thread with exclusive access to monitor data } wait Scheduling notify Thread just left monitor Thread about to enter waiting for exclusive access Monitor queue awaiting fulfilled condition Condition queue Figure 3.7: The monitor concept, including the wait-notify mechanism as a back yard. The crosses are revolving doors, that is, the door turns in the direction of the bent arrow and threads can only pass in the direction shown by the straight arrow. notify to wake up one of the blocked threads. If the condition queue is empty, notify does nothing. It depends on the runtime system which of the blocked threads that are selected for notification, but here we assume the normal case that it is the first in queue thread, which in turn is the one with the highest priority. After the thread is notified and ready for execution, it has to compete for CPU time with all other threads to advance its execution point at all. When execution advances, the thread also has to compete (again!) with other threads for exclusive access to the monitor, and if not successful it is blocked and placed in the monitor queue (in priority order we assume, even if not specified by Java). notifyAll() All the threads in the condition queue are notified, and thereby made ready for execution. They are then all subject to scheduling as explained for notify. Since scheduling is not part of the Java specification, and since knowing what threads that might be using the monitor requires global information, the reliable and portable way of notification is to always call notifyAll instead of notify; the use of notify is purely for optimization and performance tuning (to prevent excessive context switches that can be the case when many threads first are unblocked and then all but one calls wait again when the condition again is not fulfilled). 75
Page 1:
JAVA-BASED REAL-TIME PROGRAMMING Kl
Page 4 and 5:
• Each piece of software must be
Page 7 and 8:
Contents I Concurrent programming i
Page 9:
Part I Concurrent programming in Ja
Page 12 and 13:
1. Introduction pany depends on the
Page 14 and 15:
1. Introduction control may be dela
Page 17 and 18:
Chapter 2 Fundamentals Goal: Review
Page 19 and 20:
2.2. Our physical world is parallel
Page 21 and 22:
2.4. Concurrency a trend that the p
Page 23 and 24: 2.4. Concurrency Behind the term co
Page 25 and 26: 2.4. Concurrency in functions like
Page 27 and 28: 2.5. Interrupts, pre-emption, and r
Page 29 and 30: 2.5. Interrupts, pre-emption, and r
Page 31 and 32: 2.6. Models of concurrent execution
Page 33 and 34: Object properties Implicit mutual e
Page 35 and 36: 2.6. Models of concurrent execution
Page 37 and 38: 2.7 Multi-process programming 2.7.
Page 39 and 40: 2.9. Software issues In this chapte
Page 41 and 42: Chapter 3 Multi-Threaded Programmin
Page 43 and 44: 3.1.1 Thread creation At start of a
Page 45 and 46: to foresee the value actually retur
Page 47 and 48: 3.1. Threads first obtains the curr
Page 49 and 50: the run-time system (that is, the s
Page 51 and 52: 3.1.6 Thread interruption and termi
Page 53 and 54: • If the operation of an industri
Page 55 and 56: 3.2. Resources and mutual exclusion
Page 59 and 60: give give give 3.2. Resources and m
Page 61 and 62: synch. T1 entry give take 3.2. Reso
Page 67 and 68: class Account { int balance; Semaph
Page 69 and 70: 3.3. Objects providing mutual exclu
Page 73: 3.3. Objects providing mutual exclu
Page 77 and 78: class Producer extends Thread { pub
Page 85 and 86: 3.4 Message-based communication - M
Page 87 and 88: 3.4.2 Events and buffers 3.4. Messa
Page 89 and 90: Real-Time Events - RTEvent 3.4. Mes
Page 91 and 92: 3.4. Message-based communication -
Page 93 and 94: RTEvent post(RTEvent e) final void
Page 95 and 96: 3.4. Message-based communication -
Page 97: 3.4. Message-based communication -
Page 100 and 101: 4. Exercises and Labs 4. In the pro
Page 102 and 103: 4. Exercises and Labs /** * The buf
Page 104 and 105: 4. Exercises and Labs object and gi
Page 106 and 107: 4. Exercises and Labs Excerpt from
Page 108 and 109: 4. Exercises and Labs 4.3 Lab 1 - A
Page 110 and 111: 4. Exercises and Labs Some advice o
Page 112 and 113: 4. Exercises and Labs 4.4 Exercise
Page 114 and 115: 4. Exercises and Labs • CustomerH
Page 116 and 117: 4. Exercises and Labs 4.5 Exercise
Page 118 and 119: 4. Exercises and Labs Lab 2 prepara
Page 120 and 121: 4. Exercises and Labs } /** Draws a
Page 122 and 123: 4. Exercises and Labs public static
Page 124 and 125:
4. Exercises and Labs Specification
Page 126 and 127:
4. Exercises and Labs /** * Turns t
Page 128 and 129:
4. Exercises and Labs your washing
Page 130 and 131:
4. Exercises and Labs } } super(mac
Page 132 and 133:
4. Exercises and Labs } /** * @retu
Page 134 and 135:
4. Exercises and Labs PeriodicThrea
Page 136 and 137:
4. Exercises and Labs Miscellaneous
Page 138 and 139:
4. Exercises and Labs Scheduling wi
Page 140 and 141:
4. Exercises and Labs Getting appro
Page 142 and 143:
5. Solutions 2. With some additiona
Page 144 and 145:
5. Solutions 5.2 Solution to exerci
Page 146 and 147:
5. Solutions class YourMonitor { pr
Page 148 and 149:
5. Solutions 5.4 Solution to exerci
Page 150:
5. Solutions b) After the rewriting
show all

JAVA-BASED REAL-TIME PROGRAMMING

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?