JAVA-BASED REAL-TIME PROGRAMMING

More documents

Recommendations

Info

2. Fundamentals these threads accomplish execution. Furthermore, there must be programming language constructs whose execution causes threads to block and subsequently be made ready for execution. A thread is either blocked or running or ready. A thread is blocked when it is waiting for some event to occur. A thread is running when it is actually executing on a processor. A thread is ready when it is eligible for execution but is not being executed. Execution state - is the state information needed to permit concurrent execution. An execution state can be active or inactive, depending on whether or not it is currently being used by a thread. An execution state consists of the context and the activation state. These are typically stored (internally in the run-time system) in a data structure, which traditionally has been called process control block/record (PCR). An inactive execution state is then completely stored within the PCR, whereas the hardware related parts (registers, interrupt masks, etc.) of an active execution state are stored in the hardware/CPU. Referring to the context as the main item, we call the change between the active and inactive states a context switch. The switch includes storing or restoring the hardware state, and it occurs when the thread transfers from one execution state to another. Mutual exclusion - is the mechanism that permits an action to be performed on a resource without interruption by other operations on that resource. In a concurrent system, mutual exclusion is required to guarantee consistent generation of results, and it should therefore be supported in a convenient way by the programming language. Furthermore, for efficiency at run time, it needs to be provided as an elementary execution property. In an object-oriented framework, these three execution properties are properties of objects. Therefore, an object may or may not have/be a thread, it may or may not have an execution state, and it may or may not have/provide mutual exclusion. The latter means that it may or may not exclude concurrent access via call of methods of that object. The next issue is to know: What are the possible and useful combinations of the execution properties? All eight combinations (which would make up a 2 by 2 by 2 cube) is depicted in Figure 2.3. The numbers in that table refers to the following items: 1. This is an ordinary object as known from object oriented programming, or an ordinary piece of code in the case that object orientation is not supported. This is the only case that programmers not acquainted with concurrent programming use. A class programmed in this way can still be useful in an concurrent environment if its member functions are reentrant, which they are if only local data is used and the if language/execution supports recursion (direct or indirect). Since there is neither a thread nor an execution state, we say that the object is a passive object. 2. It is still a passive object if we add mutual exclusion, but only one thread 32 2012-08-29 16:05
Object properties Implicit mutual exclusion of methods Thread Exec. state No Yes 2.6. Models of concurrent execution Comment No No Object Monitor Passive objects No Yes Coroutine ’Co-monitor’ Not in Java 5 6 Yes No — — Not useful 7 8 Yes Yes Thread-object Task Active objects Figure 2.3: Fundamental properties of software execution. Language support for an execution property is marked with “yes”. For mutual exclusion to be supported, it must be implicitly obtained from the types or declarations. at a time may run the code of the object. This abstraction is called a monitor. 3. Having an execution state without having a thread permanently associated with it forms an abstraction called a coroutine. A coroutine must be used by a thread to advance its execution state. If you have multiple coroutines but only one thread, only one coroutine at a time may execute. This is useful to handle parallellity issues in algorithms or in simulations because there the (virtual) time of the model can be held or advanced arbitrarily. That is, the real time used by a specific thread for its execution is unimportant, and a single thread using multiple coroutines is appropriate. An implementation based on coroutines can always be rewritten to work without them, but that may require more complex data structures and code. In combination with timer interrupts triggering a scheduler, coroutines can be used to implement thread objects. 4. Adding mutual exclusion to coroutines is not really necessary in the case of just one thread, and in the case that a group of coroutines run by one thread interacts with other threads, this alternative leads to difficult and error-prone programming. The name co-monitor is not established and this case is neither used nor commented in the sequel. 5. A thread without an execution state cannot execute on its own, and borrowing another thread for its execution does not provide concurrency. This case it therefore not useful. 6. Also with mutual exclusion, this case is not useful for the reasons mentioned in item 5. 7. An object with both thread and execution state is capable of execution of its own. We call this an active object or a thread object. The problem is that access to the attributes requires explicit mutual exclusion. That has to be simple to express in the program in order to make this alternative 1 3 2 4 33
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: 2.6. Models of concurrent execution
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 77 and 78: class Producer extends Thread { pub
Page 83 and 84:
3.3. Objects providing mutual exclu
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:
Page 97:
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?