JAVA-BASED REAL-TIME PROGRAMMING

More documents

Recommendations

Info

3. Multi-Threaded Programming Performed(event) of the event listeners that implement the ActionListener interface and have been registered via the Button.addActionListener(listener) method. For programming of embedded systems in general we should of course not depend on any graphics-related packages or classes (since embedded processors usually do not provide a GUI, and they are subject to restrictions on available memory) for the core operation of the system. (Compare with Linux which is very small without the graphics, compared to a full installation with window managers and the like.) We will, however, make use of the delegation-based event model; you subscribe on the events you want to receive so the sender does not have to perform any mass distribution which would be a waste of resources. In the packages mentioned above, emitting an event is usually referred to as firing it. To fire an event will be referred to as synchronously calling the event listeners, whereas to post an event will be referred to as asynchronously buffer the event for later processing by the receiving thread. This agrees, although not stated explicitly, with conventions used in various graphics packages, even if posting is normally handled internally and the user code is assumed to process each fired event in a single-threaded manner (to improve performance and to reduce complexity/concurrency). That requires that all listeners can process their events instantly, otherwise the entire GUI would ’freeze’ during that period of processing or waiting. For the situation when waiting actually have to be done, for instance waiting for a download of a file to be completed after a download button has been pushed, concurrent GUI-based processing can be requested and managed via the javax.swing.SwingUtilities and javax.swing.Timer classes. In SwingUtilities, you have to use the methods invokeLater and invokeAndWait, which take a Runnable argument. That Runnable is run concurrently with the built-in GUI event-dispatching thread, but in such a way that it does not interfere with the swing/AWT and the user’s event processing code, which concerning the GUI mainly stays singlethreaded. In multi-threaded programming threads need to operate asynchronously (although synchronizing when accessing shared data), so the emitting thread needs to post the events/messages to some buffering object where the receiving thread can fetch the events/messages. For threads running in different virtual (or physical) machines, sending a message from one thread to another cannot be accomplished by simply passing a reference to an event object between the threads. Recall that object references (which are pointers within the address space of the OS-process) have a meaning only within the program. For multi-threaded programs (within one JVM/OS-process) on the other hand, we can build upon the EventObject class mentioned above. To prepare for real-time programming, however, we need a new base class with some additions for real-time event objects. 88 2012-08-29 16:05
Real-Time Events – RTEvent 3.4. Message-based communication – Mailboxes The class se.lth.cs.realtime.event.RTEvent is the EventObject base class for real-time events. Real-time here basically means that events are timestamped, whereas true real-time properties have to do with the properties of the executing threads and their scheduling. Hence, real-time events will be needed by real-time threads (introduced in a later chapter), but they are also useful for multi-threaded programming and for the communication between concurrent and real-time threads, so introducing the RTEvent class here for message-based concurrency is natural. Every RTEvent comes from a source object referred to in the EventObject base class. Additional IDs, such as sequential numbers or the kind of event within a certain type, are expected to be defined in subclasses together with other user attributes. The time stamp is, however, fundamental to real-time systems as a mean to denote the freshness of the data. It is therefore an attribute here and the motivation for this class. The source attribute, typically being a thread object, is not supposed to keep any reference to the event after posting it. Therefore, methods of this class should not need to be synchronized. To support detection of kept references, for instance when the event is sent again, there is a field owner which is set to the same as source when the event is created. When an event is transferred, for instance via a buffer, the ownership changes to the buffer and then to the receiving thread. Using available classes, the user should not need to care about the ownership, it is checked to detect certain programming errors. Sometimes, however, it is desirable to keep a set of event objects that are sent several times, for instance every time a certain state transition occurs. In such cases the specific event subclasses are supposed to set the (protected) owner field to null, which disables the checking of ownership. Refer to the online class documentation for further details. In short, neglecting a few features for later chapters, the se.lth.cs.realtime.RTEvent class looks as: public abstract class RTEvent extends EventObject { protected long timestamp; // Creation time in ms. protected volatile transient Object owner; // Responsible thread. } public RTEvent(); // Use current Thread & TimeMillis. public RTEvent(Object source); // Set source , default timestamp. public RTEvent(long ts); // Set timestamp , default source public RTEvent(Object source , long ts); // Override both defaults. public final Object getOwner() public double getSeconds() public long getMillis() public long getNanos() There is also a setOwner method, but that method is declared final and has package visibility so it is of no interest for user code. Still, the user can in 89
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 77 and 78: class Producer extends Thread { pub
Page 85 and 86: 3.4 Message-based communication - M
Page 87: 3.4.2 Events and buffers 3.4. Messa
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?