semaphore

advertisement
CS512 Embedded RTOS
Embedded RTOS
Inter-Process
Communication
C.-Z. Yang
http://syslab.cse.yzu.edu.tw/~czyang
YZUCSE SYSLAB
Introduction
• Inter-Process Communication (IPC)
Classification
–
–
–
–
–
YZUCSE SYSLAB
czyang@acm.org
Synchronization / communication
Communication with/without data
Uni-directional/bi-directional transfer
Structured/un-structured data
Destructive/non-destructive read
CS512 Embedded RTOS
2
IPC Classification (1/2)
• Mutual exclusion & synchronization
– Semaphore
• Binary semaphore
• Counting semaphore
• Mutex semaphore
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
3
IPC Classification (2/2)
•
Communication with data
– Structured data
• destructive read
– Message queue
– Unstructured data
• Uni-direction
– destructive read
» Named pipe
(FIFO)
» Unnamed pipe
• Bi-direction
– non-destructive read
» Shared memory
YZUCSE SYSLAB
czyang@acm.org
•
Communication without
data
– Event register
– Signal
– Condition variable
CS512 Embedded RTOS
4
CS512 Embedded RTOS
Semaphore
YZUCSE SYSLAB
Semaphore Introduction
• Multiple concurrent threads of execution
within an application must be able to
– Synchronize their execution
– Coordinate mutually exclusive access to shared
resources
• RTOS provides a semaphore object and
associated semaphore management
services
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
6
Semaphores
• A semaphore S is an integer variable
• Can only be accessed through two
indivisible (atomic) operations
– wait
wait(S) {
– signal
while (S ≤ 0) ; // no-op
}
S--;
signal(S) {
S++;
}
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
7
Implementation of Blocking
Semaphores
• Semaphore operations now defined as:
wait(S)
signal(S)
YZUCSE SYSLAB
czyang@acm.org
void wait(semaphore S) {
S.value --;
if (S.value < 0) then {
add this process to S.L;
block();
}
}
void signal(semaphore S) {
S.value ++;
if (S.value <= 0) {
remove a process P from S.L;
wakeup(P);
}
}
CS512 Embedded RTOS
8
Usage of Semaphores - mutual
exclusion
• Example: critical-section for n-processes
• Shared data:
semaphore mutex; // initially mutex = 1
do {
wait (mutex);
critical section
signal (mutex);
remainder section
} while (1);
Process Pi
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
9
Usage of Semaphores -
synchronization
• Semaphore as general synchronization tool
to synchronize processes
– Use semaphore (with value initialized to 0)
• Example: if we want to execute S1 and
then S2
• Shared data:
semaphore synch; // initially synch = 0
S1;
signal(synch);
Process P1
YZUCSE SYSLAB
czyang@acm.org
wait(synch);
S2;
Process P2
CS512 Embedded RTOS
10
Deadlocks and Starvation
• Two or more processes are waiting indefinitely for
an event that can be caused by only one of the
waiting processes.
• Let S and Q be two semaphores, initialized to 1.
P0
wait(S);
wait(Q);
...
signal(S);
signal(Q);
YZUCSE SYSLAB
czyang@acm.org
P1
wait(Q);
wait(S);
.
..
signal(Q);
signal(S);
CS512 Embedded RTOS
P0: wait(S) … pass
P1: wait(Q) … pass
P0: wait(Q) … block
P1: wait(S) … block
Deadlock occurs !
11
Incorrect Use of Semaphores
• Incorrect use of semaphores
may cause timing errors
signal(mutex);
...
critical section
...
wait(mutex);
will violate
mutual exclusion
YZUCSE SYSLAB
czyang@acm.org
wait(mutex);
...
critical section
...
wait(mutex);
will cause
deadlock
wait(mutex);
...
critical section
...
wait(mutex);
...
critical section
...
signal(mutex);
...
critical section
..
signal(mutex);
will violate mutual exclusion
or cause deadlock
CS512 Embedded RTOS
12
Defining Semaphores
• A semaphore or semaphore token
– A kernel object that one or more threads of
execution can acquire or release for the
purpose of synchronization or mutual exclusion
• When a semaphore is first created, kernel
assigns
–
–
–
–
YZUCSE SYSLAB
czyang@acm.org
An semaphore control block (SCB)
A unique ID
A value (binary or a count)
A task-waiting list
CS512 Embedded RTOS
13
The Associated Parameters, and
Supporting Data Structures
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
14
Semaphore (1/2)
• A key that allows a task to carry out some
operation or to access a resource
– A single semaphore can be acquired a finite
number of times
– Acquire a semaphore is like acquiring the
duplicate of a key
– If the token counter reaches 0
• The semaphore has no token left
• A requesting task cannot acquire the semaphore and
may block if it chooses to wait
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
15
Semaphore (2/2)
• Task-waiting list tracks all tasks blocked while
waiting on an unavailable semaphore
– FIFO: first-in-first-out order
– Highest-priority first order
• When an unavailable semaphore becomes available
– Kernel allows the first task in task-waiting list to acquire
it
• Different types of semaphores
– Binary semaphores
– Counting semaphores
– Mutual-exclusion (mutex) semaphores
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
16
Binary Semaphores
• Have a value of either 0 or 1
– 0: the semaphore is considered unavailable
– 1: the semaphore is considered available
• When a binary semaphore is first created
– It can be initialized to either available or
unavailable (1 or 0, respectively)
• When created as global resources
– Shared among all tasks that need them
– Any task could release a binary semaphore even
if the task did not initially acquire it
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
17
The State Diagram of a Binary
Semaphore
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
18
Counting Semaphores (1/2)
• Use a counter to allow it to be acquired or
released multiple times
• The semaphore count assigned when it was
first created denotes the number of
semaphore tokens it has initially
• Global resources that can be shared by all
tasks that need them
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
19
The State Diagram of a Counting
Semaphore
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
20
Counting Semaphores (2/2)
• Bounded count
– A count in which the initial count set for the
counting semaphore
– Act as the maximum count for the semaphore
– Determined when the semaphore was first
created
• Unbounded count
– Allow the counting semaphore to count beyond
the initial count to the maximum value that can
be held by the counter’s data type
• An unsigned integer or an unsigned long value
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
21
Mutual Exclusion (Mutex)
Semaphores
• A special binary semaphore that supports
–
–
–
–
Ownership
Recursive access
Task deletion safety
One or more protocols avoiding problems
inherent to mutual exclusions
• The states of a mutex
– Locked (1) and unlocked (0)
• A mutex is initially created in the unlocked
state
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
22
The State Diagram of a Mutual
Exclusion (Mutex) Semaphore
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
23
Mutex Ownership
• Ownership of a mutex is gained when a task
first locks the mutex by acquiring it.
• When a task owns the mutex
– No other task can lock or unlock that mutex
– Contrast to the binary semaphore that can be
released by any task
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
24
Recursive Locking (1/3)
• Allow a task that owns the mutex to
acquire it multiple times in the locked state
• The mutex with recursive locking is called a
recursive mutex
– Useful when a task requiring exclusive access
to a shared resource calls one or more routines
that also require access to the same resource
– Allows nested attempts to lock the mutex to
succeed, rather than cause deadlock
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
25
Recursive Locking (2/3)
• Implementation
– A lock count track two states of a mutex and
the number of times it has been recursively
locked
– A mutex might maintain two counts
• A binary value to track its state
• A separate lock count to track the number of times it
has been acquired in the lock state by the task owns
it
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
26
Recursive Locking (3/3)
• Comparison
– The count used for the mutex
• Track the number of times that the task owning the
mutex has locked or unlocked the mutex
• Always unbounded, which allows multiple recursive
accesses
– The count used for the counting semaphore
• Track the number of tokens that have been acquired
or released by any task
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
27
Task Deletion Safety
• Premature task deletion is avoided
• While a task owns the mutex with built-in
task deletion safety capability, the task
cannot be deleted
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
28
Priority Inversion Avoidance
• When a higher priority task is blocked and
is waiting for a resource being used by a
lower priority task, which has itself been
preempted by an unrelated medium-priority
task
• Priority inversion avoidance protocols
– Priority inheritance protocol
– Ceiling priority protocol
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
29
Priority Inversion Example
• Priority inversion
– a situation in which a low-priority task executes
while a higher priority task waits on it due to
resource contentions
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
30
Unbounded Priority Inversion
Example
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
31
Priority Inheritance Protocol
Example
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
32
Ceiling Priority Protocol Example
• When acquiring the mutex, the task’ priority is
automatically set to the highest priority of all
possible tasks that might request it until it is
released
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
33
Typical Semaphore Operations
•
•
•
•
Creating and deleting semaphores
Acquiring and releasing semaphores
Clearing a semaphore’s task-waiting list
Getting semaphore information
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
34
Creating and Deleting
Semaphores (1/2)
• Different calls might be used for creating
binary, counting, and mutex semaphores
– Binary: specify the initial semaphore state and
the task-waiting order
– Counting: specify the initial semaphore count
and the task-waiting order
– Mutex: specify the task-waiting order and
enable task deletion safety, recursion, and
priority-inversion avoidance protocols
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
35
Creating and Deleting
Semaphores (2/2)
• When a semaphore is deleted
– Blocked tasks in its task-waiting list are
unblocked and moved to the ready or running
states
• Do not delete a semaphore while it is in use
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
36
Acquiring and Releasing
Semaphores
• Tasks acquires a semaphore can
– Wait forever
– Wait with a timeout
– Do not wait
• Any task can release a binary or counting
semaphore
– However, a mutex can only be released (unlocked) by the
task that first acquired (locked)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
37
Clearing Semaphore TaskWaiting Lists
• Clear all tasks waiting on a semaphore taskwaiting list
• Useful for thread rendezvous
– When multiple tasks’ executions need to meet
at some point in time to synchronize execution
control
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
38
Getting Semaphore Information
• Useful for performing monitoring or
debugging
• Should be used judiciously
– The semaphore information might be dynamic at
the time it is requested
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
39
Typical Semaphore Use
• Semaphore useful for
– Synchronize execution of multiple tasks
– Coordinate access to a shared resource
• Examples
–
–
–
–
–
–
YZUCSE SYSLAB
czyang@acm.org
Wait-and-signal synchronization
Multiple-task wait-and-signal synchronization
Credit-tracking synchronization
Single shared-resource-access synchronization
Recursive shared-resource-access synchronization
Multiple shared-resource-access synchronization
CS512 Embedded RTOS
40
Wait-and-Signal Synchronization
(1/4)
• Two tasks can communicate for the
purpose of synchronization without
exchanging data.
• Example: a binary semaphore can be used
between two tasks to coordinate the
transfer of execution control
– Binary semaphore is initially unavailable
– tWaitTask has higher priority and runs first
• Acquire the semaphore but blocked
– tSignTask has a chance to run
• Release semaphore and thus unlock tWaitTask
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
41
Wait-and-Signal Synchronization
Between Two Tasks (2/4)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
42
Wait-and-Signal Synchronization
(3/4)
• To coordinate the synchronization of more
than two tasks
– Use the flush operation on the task-waiting list
of a binary semaphore
• Example
– Binary semaphore is initially unavailable
– tWaitTask has higher priority and runs first
• Acquire the semaphore but blocked
– tSignTask has a chance to run
• Invoke a flush operation and thus unlock the three
tWaitTask
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
43
Wait-and-Signal Synchronization
(4/4)
tWaitTask ()
{
:
Do some processing specific to task
Acquire binary semaphore token
:
}
tSignalTask ()
{
:
Do some processing
Flush binary semaphore's task-waiting list
:
}
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
44
Credit-Tracking Synchronization
(1/4)
• The rate at which the signaling task
executes is higher than that of the
signaled task
– Need to count each signaling occurrence
– By means of the counting semaphore
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
45
Credit-Tracking Synchronization
Between Two Tasks (2/4)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
46
Credit-Tracking Synchronization
(3/4)
• Counting semaphore’s count is initially 0
• tSignalTask has higher priority than tWaitTask
– tSignalTask continues to run until it relinquishes the CPU
by making a blocking system call or delaying itself
– Thus, tSignalTask might increment the counting
semaphore multiple times before tWaitTask task running
• The counting semaphore allows a credit buildup of
the number of times that the tWaitTask can
execute before the semaphore becomes available
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
47
Credit-Tracking Synchronization
(4/4)
• Credit-tracking mechanism is useful if
tSignalTask releases semaphore in bursts
– Giving tWaitTask the chance to catch up every
once in a while
• Useful in ISR handling to signal task
waiting on a semaphore
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
48
Single Shared-Resource-Access
Synchronization (1/3)
• Provide for mutually exclusive access to a
shared resource
• A shared resource may be a
– Memory location
– A data structure
– An I/O devices
• Example
– Use a binary semaphore to protect the shared
resource
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
49
Single Shared-Resource-Access
Synchronization (2/3)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
50
Single Shared-Resource-Access
Synchronization (3/3)
• Dangers
– Any task can accidentally release the binary
semaphore, even never acquired the semaphore
first
• Both tasks can access the shared resource at the
same time
• Solutions
– Use a mutex semaphore instead
• Support the concept of ownership
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
51
Recursive Shared-ResourceAccess Synchronization (1/2)
• In some cases, a task must be able to
access a shared resource recursively
• Example
– tAccessTask calls Routine A that calls Routine
B
– All three need access to the same shared
resource
– If semaphore is used
• tAccessTask would end up blocking and causing a
deadlock
– Solution
• Use a recursive mutex
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
52
Recursive Shared-ResourceAccess Synchronization (2/2)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
53
Pseudo Code for Recursively
Accessing a Shared Resource
tAccessTask ()
{
:
Acquire mutex
Access shared resource
Call Routine A
Release mutex
:
}
Routine A ()
{
:
Acquire mutex
Access shared resource
Call Routine B
Release mutex
:
}
YZUCSE SYSLAB
czyang@acm.org
Routine B ()
{
:
Acquire mutex
Access shared resource
Release mutex
:
}
CS512 Embedded RTOS
54
Multiple Shared-ResourceAccess Synchronization (1/2)
• If multiple equivalent shared resources are used
– May use a counting semaphore that is initially set to the
number of equivalent shared resource
• However, as with the binary semaphore
– May cause problem if a task releases a semaphore that it
did not originally acquire
• Solution
– A separate mutex can be assigned for each shared
resource
– Acquire the first mutex in a non-blocking way
– If unsuccessful, acquire the second mutex in a blockingway
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
55
Multiple Shared-ResourceAccess Synchronization (2/2)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
56
Pseudo Code: Use the Counting
Semaphore
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
57
Pseudo Code: Use the Mutex
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
58
CS512 Embedded RTOS
Message Queues
YZUCSE SYSLAB
Message Queues Introduction
(1/2)
• To facilitate inter-task data communication,
kernels provide
– a message queue object and message queue
management services
• A message queue
– a buffer-like object through which tasks and
ISRs send and receive messages to
communicate and synchronize with data
• The message queue itself consists of a
number of elements, each of which can hold
a single message.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
60
Message Queues Introduction
(2/2)
• When a message queue is first created, it is
assigned
–
–
–
–
–
–
–
a queue control block (QCB)
a message queue name
a unique ID
memory buffers
a queue length
a maximum message length
task-waiting lists
• Kernel takes developer-supplied parameters to
determine how much memory is required for the
message queue:
– queue length and maximum message length
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
61
The associated parameters, and
supporting data structures
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
62
Message Queue States (1/2)
• The state diagram for a message queue:
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
63
Message Queue States (2/2)
• When a task attempts to send a message
to a full message queue, two ways of kernel
implementation:
– the sending function returns an error code to
that task
– Sending task is blocked and is moved into
sending task-waiting list
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
64
Message Queue Content (1/3)
• Message queues can be used to send and
receive a variety of data. Some examples:
–
–
–
–
–
YZUCSE SYSLAB
czyang@acm.org
a temperature value from a sensor
a bitmap to draw on a display
a text message to print to an LCD
a keyboard event
a data packet to send over the network
CS512 Embedded RTOS
65
Message Queue Content (2/3)
• When a task sends a message to another
task, the message normally is copied twice
– from sender’s memory area to the message
queue’s memory area
– from the message queue’s memory area to
receiver’s memory area
• Copying data can be expensive in terms of
performance and memory requirements
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
66
Message copying and memory use for
sending and receiving messages
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
67
Message Queue Content (3/3)
• Keep copying to a minimum in a real-time
embedded system:
– by keeping messages small
– by using a pointer instead
• Send a pointer to the data, rather than the
data itself
– overcome the limit on message length
– improve both performance and memory
utilization
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
68
Message Queue Storage (1/2)
• Message queues may be stored in a system
pool or private buffers
• System Pools
– the messages of all queues are stored in one
large shared area of memory
– Advantage: save on memory use
– Downside: a message queue with large messages
can easily use most of the pooled memory
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
69
Message Queue Storage (2/2)
• Private Buffers
– separate memory areas for each message queue
– Downside: uses up more memory
• requires enough reserved memory area for the full
capacity of every message queue that will be created
– Advantage: better reliability
• ensures that messages do not get overwritten and
that room is available for all messages
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
70
Typical Message Queue
Operations
• creating and deleting message queues
• sending and receiving messages
• obtaining message queue information
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
71
Creating and Deleting Message
Queues
• When created, message queues are treated as
global objects and are not owned by any particular
task.
• When creating a message queue, a developer needs
to decide
– message queue length
– the maximum messages size
– the blocked tasks waiting order
Operation
Create
Delete
YZUCSE SYSLAB
czyang@acm.org
Description
Creates a message queue
Deletes a message queue
CS512 Embedded RTOS
72
Sending and Receiving Messages
Operation
Description
Send
Sends a message to a message queue
Receive
Receives a message from a message queue
Broadcast
Broadcasts messages
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
73
Sending messages in FIFO or
LIFO order
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
74
Sending Messages
• Tasks can send messages with different
blocking policies:
– not block (ISRs and tasks)
• If a message queue is already full, the send call
returns with an error, the sender does not block
– block with a timeout (tasks only)
– block forever (tasks only)
• The blocked task is placed in the message
queue’s task-waiting list
– FIFO or priority-based order
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
75
FIFO and priority-based taskwaiting lists
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
76
Receiving Messages (1/2)
• Tasks can receive messages with different
blocking policies:
– not blocking
– blocking with a timeout
– blocking forever
• Due to the empty message queue, the
blocked task is placed in the message
queue’s task-waiting list
– FIFO or priority-based order
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
77
FIFO and priority-based taskwaiting lists
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
78
Receiving Messages (2/2)
• Messages can be read from the head of a
message queue in two different ways:
– destructive read
• removes the message from the message queue’s
storage buffer after successfully read
– non-destructive read
• without removing the message
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
79
Obtaining Message Queue
Information
• Obtain information about a message queue:
– message queue ID, task-waiting list queuing
order (FIFO or priority-based), and the
number of messages queued.
Operation
Description
Show queue info
Gets information on a message queue
Show queue’s taskwaiting list
Gets a list of tasks in the queue’s taskwaiting list
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
80
Typical Message Queue Use
• Typical ways to use message queues within
an application:
–
–
–
–
YZUCSE SYSLAB
czyang@acm.org
non-interlocked, one-way data communication
interlocked, one-way data communication
interlocked, two-way data communication
broadcast communication
CS512 Embedded RTOS
81
Non-Interlocked, One-Way Data
Communication (1/3)
• non-interlocked (or loosely coupled), oneway data communication:
– The activities of tSourceTask and tSinkTask
are not synchronized.
• TSourceTask simply sends a message and does not
require acknowledgement from tSinkTask.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
82
Non-Interlocked, One-Way Data
Communication (2/3)
tSourceTask ()
{
:
Send message to message queue
:
}
tSinkTask ()
{
:
Receive message from message queue
:
}
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
83
Non-Interlocked, One-Way Data
Communication (3/3)
• ISRs typically use non-interlocked, one-way
communication.
– A task such as tSinkTask runs and waits on the
message queue.
– When the hardware triggers an ISR to run, the
ISR puts one or more messages into the
message queue for tSinkTask.
• ISRs send messages to the message queue
in a non-blocking way.
– If the message queue becomes full, any
additional messages that the ISR sends to the
message queue are lost.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
84
Interlocked, One-Way Data
Communication (1/2)
• interlocked communication
– the sending task sends a message and waits to
see if the message is received
– useful for reliable communications or task
synchronization
• Example
– a binary semaphore initially set to 0 and a
message queue with a length of 1 (also called a
mailbox)
– Sender tSourceTask and receiver tSinkTask
operate in lockstep with each other
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
85
Interlocked, One-Way Data
Communication (2/2)
tSourceTask ()
{
:
Send message to message queue
Acquire binary semaphore
:
tSinkTask ()
}
{
:
Receive message from message queue
Give binary semaphore
:
}
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
86
Interlocked, Two-Way Data
Communication (1/2)
• interlocked, two-way data communication
(also called full-duplex or tightly coupled
communication)
– data flow bidirectionally between tasks
– useful when designing a client/server-based
system
– two separate message queues are required
• If multiple clients need to be set up
– all clients can use the client message queue to
post requests
– tServerTask uses a separate message queue to
fulfill the different clients’ requests
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
87
Interlocked, Two-Way Data
Communication (2/2)
tClientTask ()
{
:
Send a message to the requests queue
Wait for message from the server queue
:
tServerTask ()
}
{
:
Receive a message from the requests queue
Send a message to the client queue
:
}
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
88
Broadcast Communication (1/3)
• Allow developers to broadcast a copy of
the same message to multiple tasks
• Message broadcasting is a one-to-manytask relationship.
– tBroadcastTask sends the message on which
multiple tSink-Task are waiting.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
89
Broadcast Communication (2/3)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
90
Broadcast Communication (3/3)
tBroadcastTask ()
{
:
Send broadcast message to queue
:
}
Note: similar code for tSignalTasks 1, 2, and 3.
tSignalTask ()
{
:
Receive message on queue
:
}
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
91
CS512 Embedded RTOS
Shared Memory
YZUCSE SYSLAB
Shared Memory Introduction
• A region of memory is set aside, and a set
of processes is given access to it.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
93
Why shared memory? (1/2)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
94
Why shared memory? (2/2)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
95
Some issues
• Must do something to ensure that reads
are carefully separated from writes.
• Shared memory could be used for some of
the same purposed for which message
queues are used.
• A more common use of shared memory is to
expose an application’s internal state.
• A shared memory region need not appear
at the same address for each process.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
96
Typical Shared Memory
Operations
• Create or get a shared memory segment
• Attach a shared memory segment into a
process’s address space with specified
access mode
• Issue commands to control a shared
memory segment
• Deattach a shared memory segment from a
process’s address space
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
97
Flowchart of Using Shared
Memory Under Linux
sys_shmget()
Create
Segment
YZUCSE SYSLAB
czyang@acm.org
sys_shmat()
Process to
attach segment
For read and
write
Give a valid
IPC identifier
Remove or
detach
segment
Execute
commands about
Shared memory
sys_shmdt()
sys_shmctl()
CS512 Embedded RTOS
98
Shared Memory System Call in
Linux
• int shmget ( key_t key, int size, int
shmflg );
• int shmat ( int shmid, char *shmaddr,
int shmflg);
• int shmctl ( int shmqid, int cmd,
struct shmid_ds *buf );
• int shmdt ( char *shmaddr );
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
99
System Call – shmget()
• int shmget ( key_t key, int size, int shmflg );
• Return:
Success: shared memory segment identifier.
Error:
EINVAL ( Invalid segment size specified )
EEXIST ( Segment exists, cannot create )
EIDRM ( Segment is marked for deletion, or was
removed )
ENOENT ( Segment does not exist )
EACCES ( Permission denied )
ENOMEM ( Not enough memory to create segment )
ENOSPC ( Not enough shared mem pages to create
segment )
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
100
System Call – shmat()
• int shmat ( int shmid, char *shmaddr, int
shmflg );
• Return:
Success: address at which segment was
attached to the process.
Error:
EINVAL ( Invalid IPC ID value or attach
address passed )
EACCES ( Permission denied )
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
101
System Call – shmctl() (1/2)
•
•
int shmctl ( int shmqid, int cmd, struct shmid_ds *buf );
Return:
Success: 0.
Error:
EACCES ( No read permission and cmd is IPC_STAT )
EFAULT ( Address pointed to by buf is invalid with IPC_SET
and
IPC_STAT commands )
EIDRM ( Segement was removed during retrieval )
EINVAL ( shmid invalid )
EPERM ( IPC_SET or IPC_RMID command was issued, but
calling process does not have write (alter) access to
the segment )
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
102
System Call – shmctl() (2/2)
• Command:
– IPC_INFO:return the information about shared memory
variables that linux implements.
– SHM_INFO:return the information about shared
memory
variables
– IPC_STAT:return segment data structure
– SHM_STAT:return shared memory segment identifier
data
structure
– IPC_SET:allow superuser to set the new argument
– IPC_RMID:remove segment
– SHM_LOCK:allow superuser to lock segment in memory
– SHM_UNLOCK:allow superuser to unlock segment in
memory
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
103
System Call – shmdt()
• int shmdt ( char *shmaddr );
• Return: 0
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
104
CS512 Embedded RTOS
Pipes
YZUCSE SYSLAB
Pipe Introduction (1/2)
• Provide unstructured data exchange and facilitate
synchronization among tasks
• A pipe is a unidirectional data exchange facility
• Two descriptors, one for each end of the pipe (one
end for reading and one for writing), are returned
when the pipe is created.
– Data is written via one descriptor and read via the other.
• Reader becomes blocked when the pipe is empty,
and writer becomes blocked when the pipe is full.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
106
A common pipe—unidirectional
• The data remains in the pipe as an
unstructured byte stream.
• Data is read from the pipe in FIFO order.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
107
Pipe Introduction (2/2)
• Typically used to exchange data between a
data-producing task and a data-consuming
task
• Allows several writers for the pipe with
multiple readers on it.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
108
Pipes vs. Message Queue
• A pipe does not store multiple messages.
– data that it stores is not structured, but
consists of a stream of bytes
• The data in a pipe cannot be prioritized
– the data flow is strictly FIFO
• Pipes support the powerful select operation,
and message queues do not.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
109
Pipe Control Blocks (1/3)
• Pipes can be dynamically created or
destroyed.
• Kernel creates and maintains pipe-specific
information in a pipe control block
– a kernel-allocated data buffer for the pipe’s
input and output operation
– buffer size is fixed when the pipe is created
– current data byte count
• amount of readable data in the pipe
– current input and output position
• specifies the next write/read position in the buffer
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
110
Pipe Control Blocks (2/3)
• Kernel creates two descriptors
– unique within the system I/O space and returns
these descriptors to the creating task
– identify each end of the pipe uniquely
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
111
Pipe Control Blocks (3/3)
• Two task-waiting lists are associated with
each pipe
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
112
Pipe States
• Corresponds to the data transfer state
between the reader and the writer of the
pipe
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
113
Named and Unnamed Pipes
• Two kinds of pipe objects:
– named pipe, also known as FIFO
• has a name similar to a file name and appears in the
file system as if it were a file or a device
• referenced by name
– unnamed pipe
• does not have a name and does not appear in the file
system
• referenced by the descriptors that the kernel
returns when the pipe is created
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
114
Typical Pipe Operations
•
•
•
•
create and destroy a pipe
read from or write to a pipe
issue control commands on the pipe
select on a pipe
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
115
Create and Destroy (1/2)
Operation
Description
Pipe
Creates a pipe
Open
Opens a pipe
Close
Deletes or closes a pipe
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
116
Create and Destroy (2/2)
• pipe operation
– creates an unnamed pipe
– returns two descriptors to the calling task
• One descriptor is used only for writing, and the other
descriptor is used only for reading
• mknod and mkfifo operation
– creating a named pipe is similar to creating a
file
– after created, the pipe can be opened using
open operation
– either open for read or write (cannot be both)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
117
Read and Write
• read operation is destructive because data
is removed from a pipe
• write operation appends new data to the
existing byte stream in the pipe
–
data is unstructured and cannot be prioritized
Operation
Description
Read
Reads from the pipe
Write
Writes to a pipe
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
118
Control
• provides generic control over a pipe’s
descriptor using various commands
– non-blocking
– flush
• flush the data from the pipe and reset its state
Operation
Description
Fcntl
Provides control over the pipe descriptor
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
119
Select (1/2)
• Allows a task to block and wait for a
specified condition to occur on one or more
pipes
• The wait condition can be
– waiting for data to become available
– waiting for data to be emptied from the pipe(s)
Operation
Description
Select
Waits for conditions to occur on a pipe
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
120
Select (2/2)
• a task reading from multiple pipes can
perform a select operation on those pipes
– the select call returns when any one of them
has data available
• a task writing to multiple pipes can perform
a select operation on the pipes
– the select call returns when space becomes
available on any one of them
• the main advantage of using a pipe over a
message queue for intertask communication
is that it allows for the select operation
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
121
The select operation on multiple
pipes
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
122
Typical Uses of Pipes
• mainly used for task-to-task or ISR-totask data transfer
• inter-task synchronization
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
123
CS512 Embedded RTOS
Signals
YZUCSE SYSLAB
Signal Introduction (1/3)
• A signal is a software interrupt that is
generated when an event has occurred.
• It diverts the signal receiver from its
normal execution path and triggers the
associated asynchronous processing.
• signals notify tasks of events that
occurred during the execution of other
tasks or ISRs
– these events are asynchronous to the notified
task
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
125
Signals
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
126
Signal Introduction (2/3)
• The number and type of signals defined is both
system-dependent and RTOS-dependent.
• each signal is associated with an event
– Unintentional
• such as an illegal instruction encountered during program
execution
– Intentional
• such as a notification to one task from another that it is
about to terminate
• a task can specify the particular actions to
undertake when a signal arrives
– the task has no control over when it receives signals
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
127
Signal Introduction (3/3)
• When a signal arrives, the task is diverted
from its normal execution path, and the
corresponding signal routine is invoked.
• Signal routine, signal handler, asynchronous
event handler, and asynchronous signal
routine (ASR)
• Each signal is identified by an integer value,
which is the signal number or vector
number.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
128
Signal Control Blocks (1/2)
• signal control block
– part of the task control block
– maintains a set of wanted signals
• The task can provide a signal handler for
each signal to be processed, or it can
execute a default handler that the kernel
provides.
• Signals can be ignored, made pending,
processed (handled), or blocked.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
129
Signal Control Blocks (2/2)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
130
Typical Signal Operations (1/3)
Operation
Description
Catch
Installs a signal handler
Release
Removes a previously installed handler
Send
Sends a signal to another task
Ignore
Prevents a signal from being delivered
Block
Blocks a set of signal from being delivered
Unblock
Unblocks the signals so they can be delivered
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
131
Typical Signal Operations (2/3)
• On the arrival of the signal
– kernel interrupts task’s execution, and the
handler is invoked
• task-installed handler has two options
– processing the signal and returning control to
the kernel
– processing the signal and passing control to the
default handler for additional processing
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
132
Typical Signal Operations (3/3)
• Signals are usually associated with
hardware events that occur during
execution of a task
– E.g., generation of an unaligned memory address
or a floating-point exception.
• Such signals are generated automatically when their
corresponding events occur
• The send operation, by contrast, enables a
task to explicitly generate a signal to
another task.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
133
The catch operation
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
134
Typical Uses of Signals (1/3)
• Some signals are associated with hardware
events and thus are usually sent by
hardware ISRs.
• The ISR is responsible for immediately
responding to these events.
• The ISR, however, might also send a signal
so that tasks affected by these hardware
events can conduct further, task-specific
processing
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
135
Typical Uses of Signals (2/3)
• signals can also be used for synchronization
between tasks
• However, signals should be used sparingly
– Because signals occur asynchronously, the
receiving task becomes nondeterministic
• undesirable in a real-time system
– do not support queuing or counting of signals
– data cannot be attached to a signal
– do not support a signal delivery order, signal
priority
– do not guarantee when an unblocked pending
signal will be delivered to the destination task
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
136
Typical Uses of Signals (3/3)
• real-time extensions to traditional signal
handling:
– prioritized delivery of a signal based on the
signal number
– each signal to carry additional information
– multiple occurrences of the same signal to be
queued
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
137
CS512 Embedded RTOS
Event Registers
YZUCSE SYSLAB
Event Register Introduction
• part of each task’s control block
• consists of a group of binary event flags
– track the occurrence of specific events
• Each bit in the event register is treated
like a binary flag (also called an event flag)
– can be either set or cleared
• Applications define the event associated
with an event flag.
– This definition must be agreed upon between
the event sender and receiver using the event
register.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
139
Event register
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
140
Event Register Control Blocks
• kernel creates an event register control
block as part of task control block when
task creation
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
141
Typical Event Register
Operations
Operation
Description
Send
Sends events to a task
Receive
Receives events
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
142
The Receive Operation (1/2)
• allows a task to block-wait for arrival of
multiple events
• kernel translates this event set into the
notification conditions
• The receive operation returns either when
the notification conditions are satisfied or
when the timeout has occurred.
• Any received events not indicated in the
receive operation are left pending.
• The receive operation returns immediately
if the desired events are already pending.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
143
The Receive Operation (2/2)
• The event set is constructed using the bitwise AND/OR operation.
– AND operation
• task resumes execution only after every event bit
from the set is on
– OR operation
• task resumes execution when any one event bit from
the set is on
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
144
The Send Operation
• allows a task or an ISR, to send multiple
events to another task through a single
send operation.
• Events in the event register are not queued.
– An event register cannot count the occurrences
of the same event while it is pending
– subsequent occurrences of the same event are
lost
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
145
Typical Uses of Event Registers
(1/2)
• typically used for unidirectional activity
synchronization
– the issuer of the receive operation determines
when activity synchronization should take place
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
146
Typical Uses of Event Registers
(2/2)
• No data is associated with an event when
events are sent through the event register.
• This lack of associated data can sometimes
create difficulties
– noncumulative nature of events in the event
register
– does not have a built-in mechanism for
identifying the source of an event if multiple
sources are possible
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
147
Identifying an event source
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
148
CS512 Embedded RTOS
Condition Variables
YZUCSE SYSLAB
Condition Variable Introduction
(1/5)
• condition variable
– allow tasks waiting on a shared resource to
reach a desired value or state
– a kernel object associated with a shared
resource
• allows one task to wait for other task(s) to create a
desired condition in the shared resource
• can be associated with multiple conditions
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
150
Condition Variable Introduction
(2/5)
• A condition variable implements a
predicate.
• predicate
– a set of logical expressions concerning the
conditions of the shared resource
• A task evaluates the predicate
– True -> conditions are satisfied, the task
continues execution
– False -> the task must wait
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
151
Condition Variable Introduction
(3/5)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
152
Condition Variable Introduction
(4/5)
• When examining a condition variable, the
task must have exclusive access to that
condition variable
– a mutex is always used
– A task must first acquire the mutex before
evaluating the predicate.
• kernel must guarantee that
– the task can release the mutex and then blockwait for the condition in one atomic operation
• an operation that cannot be interrupted
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
153
Condition Variable Introduction
(5/5)
• After the desired conditions have been
created, one of the waiting tasks is
awakened and resumes execution.
– priority-based or FIFO-based (kernel-defined)
– the selected task is removed from the taskwaiting list, reacquires the guarding mutex, and
resumes its operation in one atomic operation
• The essence of the condition variable is
the atomicity of the unlock-and-wait and
the resume-and-lock operations provided
by the kernel
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
154
Condition Variable Control
Blocks (1/2)
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
155
Condition Variable Control
Blocks (2/2)
• The cooperating tasks define which
conditions apply to which shared resources.
– This information is not part of the condition
variable
– each task can have a different predicate or
condition for which the task looks.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
156
Typical Condition Variable
Operations
Operation Description
Create
Creates and initializes a condition variable
Wait
Waits on a condition variable
Signal
Signals the condition variable on the presence of a
condition
Signals to all waiting tasks the presence of a
condition
Broadcast
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
157
Typical Uses of Condition
Variables (1/2)
• Pseudo code for wait and the signal
Task 1
operations:
Lock mutex
Examine shared resource
While (shared resource is Busy)
WAIT (condition variable)
Mark shared resource as Busy
Unlock mutex
Task 2
Lock mutex
Mark shared resource as Free
SIGNAL (condition variable)
Unlock mutex
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
158
Typical Uses of Condition
Variables (2/2)
• A signal on the condition variable is lost
when nothing is waiting on it.
– a task should always check for the presence of
the desired condition before waiting on it
• A task should also always check for the
presence of the desired condition after a
wakeup as a safeguard against improperly
generated signals on the condition variable.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
159
Execution sequence of wait and
signal operations
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
160
CS512 Embedded RTOS
IPC Mechanisms Used in
Well-known RTOS
YZUCSE SYSLAB
IPC Mechanisms Used in Wellknown RTOS
• eCos
–
–
–
–
–
–
Mutexes
Semaphore
Condition variable
Flags (Event Registers)
Message boxes
Spinlocks
• uC/OS-II
– Semaphore, mutex, event flag, message mailbox, message
queue
• LyraOS
– Semaphore, message queue, signal, spinlock
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
162
References
•
•
•
•
•
Qing Li and Caroline Yao, Real-Time Concepts for Embedded
Systems, CMP Books, ISBN: 1-57820-124-1, 2003.
Silberschatz, Galvin, and Gagne, “Operating System
Concepts”, John Wiley, 2002.
Anthony J. Massa, Embedded Software Development With
eCos, Prentice Hall, ISBN: 0-13-035473-2, 2003.
Jean J. Labrosse, "MicroC OS II: The Real Time Kernel,"
ISBN: 1578201039, CMP Books, June 15, 2002.
Z. Y. Cheng, M. L. Chiang, and R. C. Chang, "A component
based operating system for Resource limited embedded
devices," IEEE International Symposium on Consumer
Electronics, HongKong, Dec. 5-7, 2000.
YZUCSE SYSLAB
czyang@acm.org
CS512 Embedded RTOS
163
Download