JAVA-BASED REAL-TIME PROGRAMMING

More documents

Recommendations

Info

2. Fundamentals Both a process and an interrupt contain threading and some kind of execution state, but a process is more powerful than a thread whereas an interrupt is less powerful. In more detail: • A process may contain one or several threads which we then say are internal to the process. The internal threads share a common address space in which they can share data and communicate without having to copy or transfer data via pipes or files. An object reference (or pointer in C/C++) can be used by several threads, but sharing objects between processes requires special techniques. The same applies to calls of member functions. All threads of one process have the same access rights concerning system calls, file access, etc. Different processes, on the other hand, may have different access rights. The concept of a process makes it possible to isolate execution and data references of one program. By controlling the MMU (Memory Management Unit) accordingly, an illegal data access (due to dereference of a dangling pointer in a C program for instance) can be trapped and handled by the operating system. To the UNIX user, there will be something like a “segmentation fault” message. In Windows 95/98, which lacks this support, one application programming error may crash other applications or even hang the operating system. • An interrupt starts a new execution thread, but it is subject to special restrictions. First, it must complete without blocking because it may not change execution state (switch context). Second, the interrupt may only start in a static function/method because this type of hardware call does not provide function arguments such as the implicit this pointer. Third, an interrupt may run within the context of another thread because the final restore of used registers and the requirement of “execution until completion” ensures that the context of the interrupted thread will be restored. The priorities of interrupts are managed by the hardware. Thus, whereas threads will be the most common way to accomplish concurrently executing software entities, an ISR is sometimes more appropriate or even necessary (device drivers), or there may be reasons for using (OS) processes instead of threads. Device drivers cannot be (purely) implemented in Java, and such machine-level programming is outside the scope of this book; it is well known how to do that and there are several hardware/OS-specific manuals/books on the topic. The issue of multithreading versus multiprocessing is more relevant, in particular for large complex systems, deserving a more detailed treatment. 36 2012-08-29 16:05
2.7 Multi-process programming 2.7. Multi-process programming Programming languages include constructs for expressing the execution of one program, while interaction between programs are handled via library calls. Exercises in basic programming courses are solved by writing one program, possibly in several files that are compiled separately, but linked as one executable unit which is executed within one OS process. Possibly, event handlers (in terms of event listeners or callback routines) or multiple threads are used, but it is one program and one process sharing a common memory space. Note that even if we let different OS processes share memory (via system calls such as mmap in UNIX), we have no language support for signaling and mutual exclusion; that too has to be handled via system calls. Using multiple threads (multi-threaded programming) can, in principle, as mentioned, be used to create any concurrency. Also for utilization of multiple CPUs (with shared memory), threads are enough. So, in real-world systems, what are the reasons for using multiple processes instead of just multiple threads? In short, reasons for dividing a software application into multiple OS processes include the following: 1. Different parts of the applications need to run on different computers which are distributed (not sharing memory). 2. Different parts of the application need different permissions and access rights, or different sets of system resources. 3. In the Java case, different virtual machine properties (such as GC properties) can be desirable for different parts of the system, depending on timing demands etc. 4. If the application consists of (new) Java parts and other (typically old, so called legacy) parts written in other languages like C, these parts can be interfaces and linked together using the Java Native Interface (JNI). However, if the virtual machine and the legacy code requires specific but different native threading libraries, this may not be possible (resulting in linkage errors). This is solved by using multiple processes. 5. Licensing terms for different parts of the application can forbid execution as one process. For instance, GNU-type of free software (GPL) may not be linked with proprietary software. 6. A large application including code written in an unsafe language (such as C/C++) will be more reliable if it is divided into several executable units, each with its own memory space and with memory accesses checked by the MMU (memory management unit) hardware. Instead of a ’bluescreen’ due to an illegal access, just one part of the application may stop. The use of protected memory is a main reason why large systems have 37
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: 2.6. Models of concurrent execution
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 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?