JAVA-BASED REAL-TIME PROGRAMMING

More documents

Recommendations

Info

2. Fundamentals Lack of reentrance is common problem in badly written C programs. The reason is the use of static variables, i.e., variables that are allocated on a fixed place in memory instead of on the stack or on the heap. In most run-time systems, local variables in functions and blocks are allocated (pushed) on the stack, which means that they are deallocated (popped from the stack) when the PC leaves the scope. Data created dynamically, using operator new in Java or C++, are allocated on the heap which is sometimes called the free store. But also for heap allocation we usually have the reference to the object declared locally in some scope which means that it is put on the stack. This is a proper programming style which means that all data is pushed on the stack of the caller. If, on the other hand, we use static variables, two callers of one function will access the same local data (referred to by absolute addresses in the compiled code of the function). The real problem is when the one who wrote the function is not aware of concurrent programming. Example: A numerical equation solver was implemented in C, and then it was packaged together with other routines in a library. To optimize the code for the hardware at that time, the temporary variables of the algorithm were declared static. The function was then successfully used for years on an old-style UNIX machine, where each program only contains one point of execution (except for the signal handlers). Then, the library was compiled and linked with applications running on the newer so called multi-threaded UNIX dialects, such as Sun Solaris, HP-UX 10 and later, and later versions of IRIX from SGI. It was also used on the Microsoft Win32 platform. In all these cases, when using the equation solver concurrently from different parts of the application, the results were sometimes wrong. In this case, the function was correct as a program, but not correct when used in a concurrent program where some interleavings resulted in undesired mixing of temporary data from different equations. Also in Java it is easy to declare static variables, but we should only do that for so called class variables needed for the structure of our program, and in that case we should treat them as other types of shared data (which we will return to). Note that when you write an ordinary function, you cannot know if it later will be used concurrently. In conclusion, one should learn concurrent programming before doing any type of professional programming. 2.6 Models of concurrent execution The concurrency issues made our simple sequential execution model (from Section 2.1) more complex because we now have several sequences that interact with each other. With each sequence, there are: • A PC (the Program Counter) which according to the previous section refers to the next machine instruction to be executed. 30 2012-08-29 16:05
2.6. Models of concurrent execution • An SP (the Stack Pointer) which refers to the stack of that particular execution sequence. On the stack, there are the activation records of all blocks/functions that are currently entered, as required for reentrant code. • The machine state (of the CPU or some virtual machine depending on the implementation of the run-time system) holds part of the status of our execution sequence. • If common resources (like shared data) are reserved in one sequence, that affects the others and should therefore be dealt with somehow. Continuing our attempt to bring order in the complexity by exploring fundamental properties, some basic terms will now be described. First we have the following two definitions: Definition: A context is the state of an active program execution, which includes PC, SP, and machine state. From an operating system point of view, execution may also be associated with permission and user privileges which then may be included in the context. In such a case we call it a process context or a heavy-weight context. From this point on, we will use the former minimal definition which is also called a light-weight context. Definition: A context switch refers to the change of context typically performed by some scheduler or operating system. Since we aim at appropriate programming methods, there is the question about what support we have from the language and from the programming interfaces (libraries of available classes). This has a great impact on the way we have to write our code. For instance, when programming in C, the language itself does not give any support for handling concurrency which makes the use of special libraries important (and tricky). In Ada there is language support in terms of tasks and rendezvous, but using that support has a significant impact on both design and implementation. A language with extensive support, like Occam, is in danger of being too special and therefore not being widely used. 2.6.1 Fundamental abstractions The question now is, to what extend should a general purpose programming language support concurrency? As suggested by Buhr in a proposed extensions of C++, it is appropriate to separate the context from the execution sequence as such, and the following execution properties should be supported by the language: Thread - is execution of code that occurs independently and possibly concurrent with other execution. The execution resulting from one thread is sequential as expressed in ordinary programming languages such as Java. Multiple threads provide concurrent execution. A programming language should provide features that support creation of new threads and specification of how 31
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: 2.5. Interrupts, pre-emption, and r
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 77 and 78: class Producer extends Thread { pub
Page 81 and 82:
3.3. Objects providing mutual exclu
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

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

Delete template?

Save as template?