

Project final presentation






Wednesday 11/18 : Team 1, 4, 7
Friday 11/20: Team 2, 5, 8
Monday 11/23: Team 3, 6, 9, 10
•
All the teams need to submit their presentation slides by 11/18
Each team will have roughly 15 minutes
•
Everything that you have done in the project needs to be presented
A demo is required for every team
•
YouTube upload is recommended
Project final report is due before the final exam
Before/After Thanksgiving


Final review on 11/25
Final exam on 12/2 (tentative time)
ECE 455/555 Embedded System Design 1

Fall 2015 2



Inter-process communication ( IPC )
 OS provides mechanisms so that processes can pass data.
IPC styles
 Shared memory:
• processes have some memory in common;
• must cooperate to avoid destroying/missing messages.
 Message passing:
• processes send messages along a communication channel---no common address space.
ECE 455/555 Embedded System Design 3



Process 1 and 2 take turn to execute on the CPU
Problem when two processes try to write the shared memory location: Race condition



 process 1 reads flag and sees 0.
process 2 reads flag and sees 0.
process 1 sets flag to one and writes location.
process 2 sets flag to one and overwrites the same location.
if (flag == 0)
/* preempted */ flag=1; loc=var;
/* preempted */ print(loc); var = 5; process 1 if (flag == 0) flag=1; loc=var; memory var = 2; process 2 if (flag == 0)
/* preempted */ flag=1; loc=var;
/* preempted */
ECE 455/555 Embedded System Design 4

 Conditions for race conditions to happen


Concurrent processes/tasks access shared variables.
Preemption/interruption at a “wrong” time.


Atomic section : section of code that cannot be interrupted by another process.
Critical section : section of code that must not be concurrently accessed by more than one thread of execution.
 Mutual exclusion


POSIX:
 preemptive scheduling  race among processes.
TinyOS
 non-preemptive scheduling for tasks  no race among tasks.
ECE 455/555 Embedded System Design 5





Asynchronous code (AC) : code that is reachable from at least one interrupt/event handler
Synchronous code (SC) : code that is only reachable from tasks
Potential races


Between AC (events) and SC (tasks)
Between AC and AC
Key properties
 Any update to shared state (variable) from AC is a potential race condition
 Any update to shared state from SC that is also updated from AC is a potential race condition
ECE 455/555 Embedded System Design 6




Race-Free Invariant
 Any update to shared state is either not a potential race condition (SC only), or occurs within an atomic section.
Compiler identifies all shared states and return errors if the above invariant is violated
How to fix race condition?


Make the access to all shared states with potential race conditions atomic
Move access to SC
ECE 455/555 Embedded System Design 7

atomic {
<Statement list>
}



Implements critical region
Disable interrupt when atomic code is being executed
But cannot disable interrupt for long!  restrictions
 No loops
ECE 455/555 Embedded System Design 8




Tested on full TinyOS code, plus applications



186 modules (121 modules, 65 configurations)
20-69 modules/app, 35 average
17 tasks, 75 events on average (per application)
•
Lots of concurrency!
Found 156 races: 103 real!


About 6 per 1000 lines of code
53 false positives
Fixing races:
 Add atomic sections
 Post tasks (move code to task context)
ECE 455/555 Embedded System Design 9

• Half of the races exist in system-level components
• MultihopM , eepromM and TinyAlloc maintain lots of internal states through complex concurrent operations
ECE 455/555 Embedded System Design 10




OS primitive for controlling access to critical regions.
 Mutual exclusion
Use


Get access to semaphore S with wait(S).
Perform critical region operations.
 Release semaphore with signal(S).
Mutex: only one process can hold a semaphore at a time.
/* initialize busy=1 */ event result_t Timer.fired(){ wait(busy); call ADC.getData(); signal(busy); return SUCCESS;
}
ECE 455/555 Embedded System Design 11

event result_t Timer.fired() { localBusy = test_set(busy); if (!localBusy) call ADC.getData(); return SUCCESS;
}


Supported by many processors
OS uses test-and-set to implement semaphores
 Also having been seen in busy-and-wait I/O interrupt
ECE 455/555 Embedded System Design 12

 Provide protective barriers between applications and OS.
 Prevent applications from corrupting OS data.
 On processors with supervisor mode, you can do the following only in supervisor mode
 Execute privileged instructions and access special hardware
•
Set real-time priority
•
Device driver


Access to a separate address space (the kernel space)
This is the mode in which the operating system usually runs.
ECE 455/555 Embedded System Design 13



Careful with memory access (pointers) when
 programs run in supervisor mode
 or processor has no supervisor mode
•
Easy to corrupt OS data
Support supervisor mode?
 SHARC: Yes
 Pentium, ARM: No
ECE 455/555 Embedded System Design 14

5.
6.
1.
2.
3.
4.
Device requests interrupt
CPU checks for pending interrupts and acknowledges the highest priority request.
Device receives acknowledge and sends CPU the interrupt vector.
CPU saves current states, looks up and calls the corresponding handler.
Handler processes request.
CPU restores states to foreground program.
ECE 455/555 Embedded System Design 15



 An exception generated by a software instruction.
 e.g. enter supervisor mode.
ARM uses SWI instruction for traps.
SHARC offers three levels of software interrupts.
 Called by setting bits in IRPTL register.
ECE 455/555 Embedded System Design 16





Exception : internally detected error.
Exceptions are caused by instruction execution
 Unpredicted
Build on top of interrupt mechanism.
Exceptions are usually prioritized and vectorized.
ECE 455/555 Embedded System Design 17




Interrupt: generated by external devices
Exception: generated by CPU due to software errors
 Ex. div by 0


Memory overflow: segmentation fault…
Memory allocation error
Trap: generated by software using instructions (enter supervisor mode: open file, read from network etc.)
ECE 455/555 Embedded System Design 18



Definition
 Multitasking OS intended for real-time applications
RTOS facilitates the creation of a real-time system but does not guarantee real-time
 Key factors are bounded interrupt latency and bounded thread switching latency

 how quick and/or predictable to a particular event
Scheduling, inter-task communication, resource sharing, etc
 Types of RTOS
 Proprietary kernels
 Real-time extensions to general-purpose OS
ECE 455/555 Embedded System Design 19







Small: micro-kernel
Minimal set of functionality
Fast and time bounded context switch
Fast and time bounded response to interrupts
Fixed or variable partitions of memory
 May not support paging or virtual memory
Sequential file that can accumulate data at fast rate
 May be memory-based
ECE 455/555 Embedded System Design 20




Preemptive priority scheduling


At least 32 priority levels, commonly 128-256 priority levels
Usually does not directly support Earliest Deadline First (EDF)
•
Fairness among processes/tasks
System calls
 Bounded execution times
 Short non-preemptable code
High-resolution system clock


Resolution down to nanoseconds
But it takes about a microsecond to process a timer interrupt
ECE 455/555 Embedded System Design 21



VRTX (Versatile Real-Time Executive)
 VRTXsa (scalable architecture)
•
•
RT-POSIX compliant
Full operating system features and real-time support
 VRTXmc (micro-controller)
•
Optimized for power and footprint
First RTOS certified by FAA
(Federal Aviation Administration)
 100% code coverage in testing

 e.g., Used by MD-11 airplanes
VxWorks was originally an extension of the VRTX
ECE 455/555 Embedded System Design 22





Generally slower and less predictable than RTOS
Much greater functionality and development support
Standard interfaces
Useful for soft real-time and complex applications
ECE 455/555 Embedded System Design 23




Compliant kernels : Modified native RTOS


Functionality and semantics of Linux are emulated e.g., LynxOS (LynuxWorks)
Dual kernels: Hard real-time kernel sits below Linux




Real-time kernel traps all interrupts and schedules all processes
Linux runs as a low-priority process
No memory protection between the two kernels e.g., RT-Linux (FSM, Finite State Machine, Labs)
Core kernel modifications: patches
 Preemptive kernel, priority inheritance, high resolution timer, etc
 e.g., TimeSys Linux, Monta Vista Linux, Android
ECE 455/555 Embedded System Design 24



Real-time scheduling class


Scheduled based on fixed priority
Scheduling threads with a same priority
•
•
SCHED_FIFO: First-In-First-Out
SCHED_RR: Round-Robin
Non-real-time scheduling class (SCHED_OTHER)
 Priority is adjusted dynamically to favor I/O bound threads
ECE 455/555 Embedded System Design 25




Race conditions


Atomic sections
Race condition check in TinyOS
 Semaphores and test-and-set
Process management
 CPU Supervisor mode
 Trap & Exception
Real-Time OS
 Proprietary kernels

•
•
Features for efficiency and real-time
Example: VRTX
Real-time extensions to general-purpose OS
•
Real-time Linux
•
Linux scheduling
ECE 455/555 Embedded System Design 26

 Textbook: 6.4-6.7
ECE 455/555 Embedded System Design 27