JAVA-BASED REAL-TIME PROGRAMMING

More documents

Recommendations

Info

3. Multi-Threaded Programming mutex Track for loading Track for unloading (incoming trains mutual exclusive) Buffer signal Industrial track (resources handled along the line) Wagon to wagon zone entry exit Figure 3.5: Railroad tracks seen from above, illustrating semaphore usage. The name of the semaphores refer to the semaphore figures earlier in this section. The Buffer is a place for storage, permitting one train to unload and continue before the next train arrives for loading. In the lower right zone there is no such buffer (or intermediate passive object) so loading has to be done directly from one train to another, which corresponds to the synchronous mechanism of rendezvous. no such intermediate storage; both trains have to be there to permit items to be transferred from one train to another, which corresponds to rendezvous implemented by the semaphores entry and exit. In more detail, trains on the industrial track have access to resources along the track but when reaching the transfer zone it gets blocked until the other train is on the adjacent track. The train entering the zone for unloading (coming from the track for loading) also has to wait until the other train is there. Hence, in terms of software again, with the use of rendezvous you know that the passed data is actually in use by the other thread when the calling thread continues execution, whereas using ordinary method calls for data transfer (even if the method belongs to an active object) the executing thread using the provided data can be unaffected (for some time after the call). Disadvantages When using semaphores, one should also be aware of the drawbacks (both in general and compared to other techniques introduced later). If semaphores are inlined in the code wherever mutual exclusion is to be accomplished, it gets hard to read and maintain the program. If it is not clear where the critical sections actually are, the risk for shared data not being locked increases. Another case is statements like if, throw, and return unintentionally results in a resource being left in a locked state, and the entire application gets locked up or does not work anymore. A first good rule therefore is to place critical sections as methods in separate classes. 62 2012-08-29 16:05
3.2. Resources and mutual exclusion – Semaphores Another disadvantage is when a thread temporarily has to leave a critical section, waiting for some condition to be fulfilled, it can in some cases be rather complicated to implement. The semaphore concept is as such sufficient for implementation of any multi-threaded program, but the application may be unnecessarily complex compared to using monitors or messages as explained below. Therefore, semaphores are best suited for low-level and small software modules with special demands on efficiency. 3.2.3 The semaphores package To support the use of semaphores in Java, a package se.lth.cs.realtime.semaphore has been developed. Different classes are providing implementations for different types of semaphores, such as a class MutexSem for the mutual exclusion case where it can be checked that give is called by the thread currently holding the semaphore, and a class CountingSem that for signaling purposes is prescribed to contain a counter. The default implementations are 100% Java using the synchronized keyword that is further explained in the next section. That is of course not acceptable for cross-compilation to small embedded systems since: • Very small systems often provide only semaphores, so synchronized has to be mapped to semaphores and not the other way around. • For low-level software serving interrupts, native semaphores for signaling from the interrupt routine to threads are indispensable. Therefore, the default implementation is for the run-anywhere (that is, pure Java) case. The idea is then to support platforms providing native semaphores by proper cross-compilation tools (outside the scope of this chapter). The Semaphore interface All semaphores provide the methods give, take, and tryTake. That is expressed by the interface Semaphore, which is useful when a semaphore object is to be used without the need to know what type of semaphore it is. These methods are documented as: public void give() Increments by 1 the counter represented by this semaphore, and notify at least one, if any, of the waiting threads. Basically this means executing the following two lines ++count; // Or set to true (or 1) in case of a binary semaphore. notify(); // If any threads blocked , release the first in queue. atomically (synchronized, with interrupts disabled, or in hardware, as accomplished in a particular type of system). 63
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: 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 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

Create successful ePaper yourself

Delete template?

Save as template?