EMBEDDED SYSTEMS

BCSE-305L
Module 5.1:
Real Time Operating System-
Classification of Real time Systems,
Issues & Challenges in RTS
Dr . A.Sivaranjani
Faculty Id: 21842
School of Computer Science and
Engineering
VIT, Vellore-632014
Tamil Nadu, India
Sivaranjani.A, AP/SCOPE VIT
Module:1 Introduction 5 hours
Overview of Embedded Systems, Design challenges, Embedded processor technology,
Hardware Design, Micro-controller architecture -8051, PIC, and ARM.

Module:2 I/O Interfacing Techniques 8 hours

Memory interfacing, A/D, D/A, Timers, Watch-dog timer, Counters, Encoder & Decoder,
UART, Sensors and actuators interfacing.

Module:3 Architecture of Special Purpose Computing System 6 hours

ATM, Handheld devices, Data Compressor, Image Capturing Devices–Architecture and
Requirements, Challenges & Constraints of special purpose computing system.

Sivaranjani.A, AP/SCOPE VIT

Module:4 Programming Tools 7 hours
Evolution of embedded programming tools, Modelling programs, Code optimization, Logic
analyzers, Programming environment.

Module:5 Real Time Operating System 8 hours

Classification of Real time system, Issues & challenges in RTS, Real time scheduling schemes-
EDF-RMS & Hybrid techniques, eCOS, POSIX, Protothreads.

Module:6 Embedded Networking Protocols 5 hours

Inter Integrated Circuits (I2C), Controller Area Network, Embedded Ethernet Controller, RS232,
Bluetooth, Zigbee, Wifi.

Module:7 Applications of Embedded Systems 4 hours

Introduction to embedded system applications using case studies – Role in Agriculture sector,
Automotive electronics, Consumer Electronics, Industrial controls, Medical Electronics.

Module:8 Contemporary Issues

Sivaranjani.A, AP/SCOPE VIT
Text Book
1. Marilyn Wolf, Computers as Components – Principles of Embedded Computing System Design,
Fourth Edition, Morgan Kaufman Publishers, 2016.

Reference Books
1. Embedded Systems Architecture, Programming and Design, by Raj Kamal, McGraw Hill
Education, 3e, 2015.
2. Embedded System Design A Unified Hardware/Software Introduction, by Vahid G Frank and
Givargis Tony, John Wiley & Sons, 2009.

Mode of Evaluation: CAT, written assignment, Quiz, FAT.

Recommended by Board of Studies 04-03-2022 Approved by Academic Council No. 65 Date
17-03-2022

Sivaranjani.A, AP/SCOPE VIT

 Real Time System
A real-time system is a system where the correctness of the
computation depends not only on the logical result of the
computation, but also on the time at which the result is
produced.
In other words, deadlines matter. Failing to meet a deadline
can have consequences, ranging from minor glitches to
catastrophic failures.
Definition: A real-time system is a software system where the
correct functioning of the system depends on the results
produced by the system and the time at which these results
Sivaranjani.A, AP/SCOPE VIT
are produced.
REAL Time System
The controlling system interacts with the controlled system in various
ways
1.The interaction can be periodic
The controlling system -> the controlled system
Predictable and occurs at predefined intervals
2.The interaction can be aperiodic
The controlled system -> the controlling system
Unpredictable from random occurrences of external events
3.The communication can be a combination of both types
The controlling system must process and respond to the events and
information generated by the controlled system in a guaranteed time
frame.
DVD player
Controlling system
DVD player must decode both the video and audio streams from the
disc simultaneously.

Controlled system
Remote control is viewed as a sensor to feed pause and language
selection events into DVD player
Clock-Based & Event-Based Systems:
Synchronization between the external processes and
internal actions (tasks) carried out by the computer
may be defined in terms of the passage of time, or the
actual time of day, in which case the system is said to be
“Clock-based system” or
it may be defined in terms of events, and the system is
said to be “Event-based system”.
 Characteristics of Real-Time Systems:

● Predictability: The system's behavior should be predictable, especially

concerning timing. This is crucial for guaranteeing deadlines.
● Determinism: The time taken to execute an operation should be known
and consistent, or at least bounded.
● Responsiveness: The system must react quickly to events.
● Concurrency: Real-time systems often handle multiple tasks
concurrently.
● Interrupt Handling: Efficient and timely handling of interrupts is
essential

Sivaranjani.A, AP/SCOPE VIT

 Classification of Real-Time Systems:
• Hard Real-Time: Missing a deadline is unacceptable and can lead to
system failure or damage.
Examples: Airbag systems, Pacemakers, Flight control systems.

● Firm Real-Time: Missing a deadline results in a degraded

performance, but the system can still function. Occasional missed
deadlines are tolerable.
Examples: Digital video recording, Stock market transactions.

● Soft Real-Time: Missing a deadline is undesirable but doesn't cause

system failure. The system continues to operate, but performance may
be impacted.
Examples: Ticket reservation system, Web browsing, Online gaming.
Sivaranjani.A, AP/SCOPE VIT
 Applications
Hard Real-Time:

● Anti-lock Braking System (ABS): The brakes must respond within a very strict time frame to prevent wheel lockup
and maintain vehicle control. A late response is as bad as no response.
● Pacemaker: The electrical impulses regulating a heartbeat must be delivered at precise intervals. A delayed or
mistimed impulse could be life-threatening.
● Nuclear Power Plant Control: Monitoring and control systems require immediate responses to prevent meltdowns.

Soft Real-Time:

● Online Stock Trading: While fast response is desirable for maximizing profit, a slight delay is unlikely to cause
significant harm.
● Web Server: Users prefer quick page loads, but a few extra milliseconds are generally acceptable.
● Multimedia Streaming: Buffering allows for some variations in delivery time without affecting the user experience.

Firm Real-Time:

● Video Conferencing: Some delay is tolerable, but excessive latency makes the experience unusable. Occasional
dropped frames are acceptable, but consistent delays are not.
● Digital Audio/Video Editing: Small delays are permissible, but large delays or glitches disrupt the editing process.
Sivaranjani.A, AP/SCOPE VIT
Sivaranjani.A, AP/SCOPE VIT
 Applications
Firm Real-Time:
● Stock Trading Systems: Delayed processing makes trade data
irrelevant, resulting in potential financial loss.
● Radar Systems in Air Traffic Control: If data is not processed
on time, it becomes obsolete, potentially affecting navigation
decisions.
● Quality Control Systems in Manufacturing: If inspection or
sorting is delayed, defective products may continue down the
assembly line.
Sivaranjani.A, AP/SCOPE VIT
 Applications
Soft Real-Time:

● Web Server: Users prefer quick page loads, but a few extra
milliseconds are generally acceptable.
● Multimedia Streaming: Buffering allows for some variations
in delivery time without affecting the user experience.

Sivaranjani.A, AP/SCOPE VIT

Why have an OS in Embedded system
 Real Time Operating System
• An RTOS (Real-Time Operating System) is designed to manage
hardware resources and execute tasks with strict timing constraints.
• It ensures that time-critical tasks are completed within predictable
timeframes.
• Unlike general-purpose operating systems (like Windows or Linux), an
RTOS prioritizes tasks based on urgency and deadlines.
• Used in time-sensitive applications where delays can cause failures or
safety risks.
• Ensures deterministic behavior: The same input produces the same
output within the same time frame.
• Crucial in systems where reliability, predictability, and low-latency are
mandatory.
• Task scheduling is primary mechanism for making the application meet
their respective deadlines.
 Key Characteristics of an RTOS:
● Deterministic Scheduling: The RTOS uses scheduling algorithms that ensure tasks are executed
in a predictable order and within their deadlines. These algorithms consider task priorities,
deadlines, and resource requirements.
● Fast Context Switching: The RTOS can quickly switch between tasks, minimizing the overhead
associated with task switching. This is essential for responding promptly to events and meeting
deadlines.
● Preemptive Scheduling: Higher-priority tasks can interrupt lower-priority tasks to ensure that
critical tasks are executed immediately. This is a key feature for hard real-time systems.
● Minimal Interrupt Latency: The time it takes for the RTOS to respond to an interrupt should be
minimal and predictable. This is crucial for handling external events quickly.
● Efficient Inter-Process Communication (IPC): The RTOS provides mechanisms for tasks to
communicate and synchronize with each other efficiently.
● Resource Management: The RTOS manages system resources (CPU time, memory, I/O) to ensure
that they are available when needed by the highest-priority tasks.
 Real-Time System:
ISSUES AND CHALLENGES
EMBEDDED SYSTEMS
BCSE-305L
Module 5.1:
Real Time Operating System-
Classification of Real time Systems,
Issues & Challenges in RTS
Dr . A.Sivaranjani
Faculty Id: 21842
School of Computer Science and
Engineering
VIT, Vellore-632014
Tamil Nadu, India
Sivaranjani.A, AP/SCOPE VIT
Module:1 Introduction 5 hours
Overview of Embedded Systems, Design challenges, Embedded processor technology,
Hardware Design, Micro-controller architecture -8051, PIC, and ARM.

Module:2 I/O Interfacing Techniques 8 hours

Memory interfacing, A/D, D/A, Timers, Watch-dog timer, Counters, Encoder & Decoder,
UART, Sensors and actuators interfacing.

Module:3 Architecture of Special Purpose Computing System 6 hours

ATM, Handheld devices, Data Compressor, Image Capturing Devices–Architecture and
Requirements, Challenges & Constraints of special purpose computing system.

Sivaranjani.A, AP/SCOPE VIT

Module:4 Programming Tools 7 hours
Evolution of embedded programming tools, Modelling programs, Code optimization, Logic
analyzers, Programming environment.

Module:5 Real Time Operating System 8 hours

Classification of Real time system, Issues & challenges in RTS, Real time scheduling schemes-
EDF-RMS & Hybrid techniques, eCOS, POSIX, Protothreads.

Module:6 Embedded Networking Protocols 5 hours

Inter Integrated Circuits (I2C), Controller Area Network, Embedded Ethernet Controller, RS232,
Bluetooth, Zigbee, Wifi.

Module:7 Applications of Embedded Systems 4 hours

Introduction to embedded system applications using case studies – Role in Agriculture sector,
Automotive electronics, Consumer Electronics, Industrial controls, Medical Electronics.

Module:8 Contemporary Issues

Sivaranjani.A, AP/SCOPE VIT
Text Book
1. Marilyn Wolf, Computers as Components – Principles of Embedded Computing System Design,
Fourth Edition, Morgan Kaufman Publishers, 2016.

Reference Books
1. Embedded Systems Architecture, Programming and Design, by Raj Kamal, McGraw Hill
Education, 3e, 2015.
2. Embedded System Design A Unified Hardware/Software Introduction, by Vahid G Frank and
Givargis Tony, John Wiley & Sons, 2009.

Mode of Evaluation: CAT, written assignment, Quiz, FAT.

Recommended by Board of Studies 04-03-2022 Approved by Academic Council No. 65 Date
17-03-2022

Sivaranjani.A, AP/SCOPE VIT

Basic Of Task Scheduling
REAL TIME TASK SCHEDULING
Example: Industrial Machine
Operation
● e1 = Machine starts heating a
component.
● e2 = Machine begins the next
operation on the component.
● ddd = 5 seconds (Minimum
time required for the
component to reach the desired
temperature).
 Concept Definition Example
Job Single execution instance of a task Checking sensor data once

Task Set of related jobs performing a function Periodic temperature

monitoring
Task Instance Specific occurrence of a task A cycle of checking sensor data

Relative Time allowed from release to completion 3 seconds

Deadline
Absolute Exact time by which a job must finish Release at 5s, deadline at 8s
Deadline
Response Time Time taken from release to completion 5 seconds

Release Time When a job becomes ready for execution 0, 10, 20, ... seconds

Completion When a job finishes execution 5 seconds

Time
Arrival Time When a job arrives in the system 4 seconds
 Earliest deadline First (EDF)
Earliest deadline first (EDF) comes under the category of the dynamic
scheduling algorithm.
• We can use it in real-time operating systems for scheduling tasks as well as
processes with specific deadlines.
• It’s a priority-based algorithm where we assign the highest priority to the
tasks with the earliest deadline.
• Additionally, the CPU executes the scheduled tasks based on priority.
• The algorithm assigns a priority to each task based on its deadline and
chooses the task with the earliest deadline for execution.
• Additionally, if multiple tasks have the same deadline, the CPU executes the
task with the highest priority.
• EDF is an optimal algorithm for scheduling a set of periodic tasks with
known deadlines and execution times as long as the total utilization of the
tasks doesn’t exceed unity.
• Hence, the total execution time of all tasks should be less than the total
available time
The earliest deadline first scheduling algorithm consists of four steps:
initialization, task prioritization, task scheduling, and task execution.
• The first step is to initialize the available tasks. Additionally, along
with initialization, we assign each task a deadline based on completion
requirements.
• The next step is to assign priority to each task. The system sorts the
tasks in order of their deadlines, with the task having the earliest
deadline assigned the highest priority.
• Furthermore, the system selects the task with the earliest deadline for
execution. If multiple tasks have the same deadline, we select the task
with the highest priority.
• Finally, the CPU executes the selected task until completed or the
deadline is reached.
• If the task is completed before its deadline, the system returns to the
task prioritization step to select the next task for execution.
• If the deadline is reached, the task is considered to be missed.
Now before the algorithm terminates, we need to check two
conditions.
• First, we need to check whether all the tasks are executed.
• Additionally, we check if all deadlines have been missed. If
one of these conditions is met, we need to go back to the task
prioritization step and repeat the steps until the algorithm
terminates.
• EDF is a dynamic scheduling algorithm where the task
priority can change over time as deadlines approach.
• Hence, the algorithm continually updates the priority of
tasks based on their deadlines and selects the task with the
earliest deadline for execution.
Least Slack Time Scheduling
Least Slack Time (LST) is a dynamic priority-driven scheduling
algorithm used in real-time systems.
• In LST, all the tasks in the system are assigned some priority
according to their slack time. The task which has the least slack
time has the highest priority and vice versa.
• Priorities to the tasks are assigned dynamically
eCOS Real-Time Operating System
eCOS Real-Time Operating System
Embedded Configurable Operating System
(eCOS)
• The eCos is an open source,royalty-free,real-time OS intended for
embedded applications.
The system is targeted at high-performance small embedded systems.
For such systems,an embedded form of Linux or other commercial OS
would not provide the streamlined software required.
The eCos software has been implemented on a wide variety of processor
platforms,including Intel IA32, PowerPC, SPARC, ARM, CalmRISC,
MIPS, and NEC V8xx.
It is one of the most widely used embedded operating systems.
1. Configuration system
The configuration system is the core of eCos, allowing users to tailor the
OS to their specific needs. It enables developers to select only the required
packages, reducing the application's footprint and ensuring efficient
resource usage.
● eCos uses compile-time control methods, meaning that configurations
are determined during compilation, ensuring fine-grained control over
the included code.
●
● These control methods are implemented using the C preprocessor,
which helps in enabling or disabling specific features.
This example shows how specific features or debugging
tools can be enabled or disabled at compile time.
2. Components
 eCos Components
eCos consists of several core components that work together to provide a real-time environment:
1. Hardware Abstraction Layer (HAL) – Provides a standardized interface for different hardware
platforms.
2. Real-time Kernel – The core of the RTOS, handling scheduling, task management, and
synchronization.
3. ISO C and Math Libraries – Standard C libraries for mathematical and general-purpose
functions.
4. Device Drivers – Interfaces for hardware peripherals such as serial ports, timers, and networking.
5. GNU Debugger (GDB) Support – Provides debugging support, enabling developers to
troubleshoot and optimize their applications (Redboot ROM monitor).
6. Target hardware: Target hardware refers to the embedded system or microcontroller
where eCos runs.
The real-time kernel is the most critical component, as it manages tasks and ensures real-time
behavior.
3. eCOS API
 eCos API (Application Programming Interface)
eCos supports multiple APIs, making it compatible with various
development environments:
1. µITRON API – A widely used real-time OS standard in embedded
systems.
2. POSIX API – Allows compatibility with UNIX-based applications.
3. Embedded Linux API (EL/IX) – Bridges the gap between embedded
systems and Linux-based development.
4. Native eCos API – A custom API specifically designed for eCos.
These APIs provide developers with flexibility when porting applications
from other systems.
4.HAL
4.Hardware Abstraction Layer (HAL)
The HAL is a crucial software layer that ensures eCos can run on multiple
hardware platforms. It provides:
● Platform-independent API for handling platform-specific operations.
● Portability, allowing developers to write code that works across different
architectures without modification.
● Extends the HAL support to tightly coupled peripherals like interrupt
controllers and timer devices.
● This module defines the platform or board that includes the selected processor
architecture and variant.It includes code for startup,chip selection
configuration,interrupt controllers,and timer devices.
API Consistency:
Although the underlying implementations differ (one using ARM inline assembly and
the other using PowerPC assembly wrapped in CYG_MACRO_START/END), both
definitions provide the same function-like API—HAL_ENABLE_INTERRUPTS(). This
means that application code can call HAL_ENABLE_INTERRUPTS() without worrying
about the hardware-specific details.
5. The Kernel in eCos

The real-time kernel is at the heart of eCos and provides standard OS

functionalities such as:
1. Interrupt and Exception Handling – Ensures the system can respond to
events in real time.
2. Scheduling – Manages the execution of multiple tasks efficiently.
3. Threads – Supports multi-threaded applications.
4. Synchronization – Provides mechanisms like semaphores and mutexes for
task coordination.
6. Kernel API
Kernel API
The Kernel API is a C-based API that allows direct interaction with the eCos kernel. Unlike
many other APIs, it does not return error codes but instead provides assertions for error
checking.

Assertions in eCos:
Assertions are used to detect unexpected conditions in the code:
● CYG_FAIL(diag_message): Always outputs a diagnostic message (used for debugging).
● CYG_ASSERT(condition, diag_message): Checks a condition and prints a diagnostic
message if it fails.
● CYG_ASSERTC(condition): A compact version of CYG_ASSERT that does not print
messages.
 7. Exception Handling
Exception handling is categorized into two types:

A. HAL + Kernel Exception Handling (Default)

● Uses a Vector Service Routine (VSR), an array of function pointers to
exception handlers.
● The HAL performs basic exception handling, such as saving CPU registers.
● The kernel then takes control for further processing, if necessary.

B. Application Exception Handling

● Applications can override the default exception handler and define their
own.
● Must use assembly language to write custom VSRs.
● The macros HAL_VSR_GET and HAL_VSR_SET allow access to the VSR
table.
8. Interrupt Processing in eCos

Interrupts are processed using ISRs (Interrupt Service Routines) and DSRs
(Deferred Service Routines).
● ISR (Interrupt Service Routine):
○ Performs minimal processing.
○ Executes quickly to maintain real-time constraints.
○ Cannot use synchronization primitives (e.g., mutexes, semaphores).
● DSR (Deferred Service Routine):
○ Handles additional processing after ISR completes.
○ Can use synchronization mechanisms, but must not block.
9. Threads in eCos

● eCos provides API functions to manage threads.

● Supports both eCos threads and POSIX threads.
Thread Management API Functions
● Create & Exit Threads
● Kill or Delete Threads
● Yield a Thread
● Delay, Suspend, and Resume Threads
 10. Scheduler in eCos
The scheduler is a core component of the eCos kernel that manages thread execution.
eCos provides two scheduling algorithms:

A. Multilevel Queue Scheduler

● Allows multiple threads at the same priority level.
● Supports preemption between different priority levels.
● Time slicing is allowed within a priority level.

B. Bitmap Scheduler
● Allows only one thread per priority level.
● Preemption is still supported.
● Simpler and more efficient than the multilevel queue scheduler.
11. Synchronization Mechanisms in eCos
Mutex API:

● cyg_mutex_init()
Synchronization mechanisms prevent race conditions when ● cyg_mutex_destroy()
multiple threads access shared resources. eCos provides the ● cyg_mutex_lock()
following: ● cyg_mutex_trylock()
● cyg_mutex_unlock()
A. Mutexes ● cyg_mutex_release()
● cyg_mutex_set_ceiling()
● Allow mutual exclusion (only one thread can access a
● cyg_mutex_set_protocol()
resource at a time).
● Prevent priority inversion (where a low-priority thread holds
a resource needed by a high-priority thread).
● Supports Priority Ceiling Protocol and Priority
Inheritance Protocol to manage priority inversion.
 11. Synchronization Mechanisms in eCos
Semaphore API:
● cyg_semaphore_init()
● cyg_semaphore_destroy()
B. Semaphores
● cyg_semaphore_wait()
● Used for counting synchronization (multiple ● cyg_semaphore_trywait()
threads can access a resource up to a limit). ● cyg_semaphore_timed_wait()
● eCos does not support binary semaphores ● cyg_semaphore_post()
(which allow only 0 or 1). ● cyg_semaphore_peek()
11. Synchronization Mechanisms
in eCos Condition Variable API:
● cyg_cond_init()
● cyg_cond_destroy()
C. Condition Variables ● cyg_cond_wait()
● Used along with mutexes to allow ● cyg_cond_timed_wait()
multiple threads to wait for a ● cyg_cond_signal()
condition to be met. ● cyg_cond_broadcast()
https://www.eventhelix.com/embedded/issues-in-real-time-system-design/

https://medium.com/@aditya.bonte20/difference-between-rtos-and-gpos-11d1990044ec
EMBEDDED AND REAL
TIME SYSTEMS

1
Example of Real Time
Operating Systems

2
 Example of RTOS

 POSIX

 Windows CE

3
 POSIX
 POSIX - Portable Operating System Interface
 POSIX.1 – Core services
 POSIX.1b – Real-time extensions
 POSIX.1c – Thread extensions
 The POSIX standard is written in terms of the C
programming language. POSIX supports two
programming environments.
 One is based on the Traditional C language.
 The other is based on the Standard C language
defined by American National Standard for Information
Systems.
 Since Standard C was developed by the American
National Standards Institute (ANSI), some people call
it ANSI C
4
 POSIX is based on UNIX operating system.
 Usually UNIX was not originally designed as a real
time operating system, POSIX has been extended to
support real time requirements.
 POSIX defines a standard way for an application to
interface to the operating system.
 The original POSIX standard defines interfaces to
core functions such as file operations, process
management, signals, and devices.

5
POSIX

6
 The POSIX process model
• POSIX does not implement lightweight
processes.

• Each POSIX process runs in its own address

space and cannot directly access the data or
code of other processes

7
 Processes in POSIX
 In POSIX, a new process is created by making a copy
of an existing process

 The copying process creates two different processes

both running the same code

 The complication comes in ensuring that one process

runs the code intended for the new process.

 While the other process continues the work of the old

process.

8
 A process makes a copy of itself by calling fork()
function
 It creates a new child process which is exact copy
of parent process
 The both have the same code and the same data
values with one exceptions the return value of fork()
– Parent Process: returns the process ID of the
child process
– Child process: returns 0
 We can Test the return value of fork() to determine
which process is the child.

9
 execv() function –> It takes the list of arguments to
the process in the form of array.
 perror() & exit() function –> To perform call
functions.
 parent_stuff() function –> To perform the work of
parent function.
 wait() function –> It make wait the child process

10
 Real time scheduling in POSIX
• POSIX supports real time scheduling in the
_POSIX_PRIORITY_SCHEDULING resource
• The sched_setscheduler() function is used to determine a
process’s scheduling policy and other parameters
Ex: i = sched_setscheduler (process_id, SCHED_FIFO,
&sched_params)
 It tells POSIX to use the SCHED_FIFO policy for this process
along with some other scheduling parameters.
 sched_getparams() function returns the current parameter values
for a process
 sched_setparams() function changes the parameter values
11
 SCHED_FIFO scheduling

• POSIX supports rate-monotonic scheduling in the

SCHED_FIFO scheduling policy.
• It is a strict priority-based
• scheduling scheme in which a process runs until it is
preempted or terminates
• The term FIFO simply refers to the fact that, within a
priority, processes run in first-come first-served
order.

12
 SCHED_RR
• SCHED_RR is a combination of real-time and
interactive scheduling techniques:
• within a priority level, the processes are timesliced.
Interactive systems must ensure
• that all processes get a chance to run, so time is
divided into quanta. Processes get the
• CPU in multiple of quanta

13
 SCHED_OTHER
• The SCHED_OTHER is defined to allow non-real-
time processes to intermix with realtime processes.
• The precise scheduling mechanism used by this
policy is not defined.
• It is used to indicate that the process does not need a
real-time scheduling policy.

14
 POSIX

• POSIX supports

Semaphores

Shared memory mechanism

Message Queues

15
 POSIX semaphores
 POSIX supports Counting semaphores in the
_POSIX_SEMAPHORES option

 A Counting semaphore allows more than one

process to access a resource at a time

 If a semaphore allows up to N resources, then it will

not block until N process have simultaneously passed
the semaphore

16
 semaphores
• At that point, the blocked process can resume only
after one of the processes has given up its semaphore.
• The simplest way to think about counting semaphores
is that they count down to 0- when the semaphore
value is 0-,
• the process must wait until another process gives
up the semaphore and increments the count.

17
 POSIX semaphores

 Names for the semaphore start with “/”

• sem_open() – To create a semaphore

• sem_close () – To destroy a semaphore

• sem_wait() – To wait for Getting a semaphore

• sem_post() – To Releasing a semaphore

18
 POSIX Shared Memory
 POSIX shared memory is supported under the
_POSIX_SHARED_MEMORY_OBJECTS option.
 Shared memory functions create blocks of memory
that can be used by several processes
• shm_open() – To open a shared memory

• close() – To close a shared memory

• mmap() – For memory mapping

• objdesc = shm_open(“/memobj1”,O_RDWR);
19
• Before using the shared memory object, we must
map it into the process memory
• space using the mmap() function. POSIX assumes
that shared memory objects
• fundamentally reside in a backing store such as a disk
and are then mapped into the address space of the
process.

20
 POSIX pipes
• The pipe is very familiar to Unix users from its shell syntax:

if (pipe(pipe_ends) <0) { /* create the pipe, check for errors */

perror(“pipe”);
break;

• A parent process uses the pipe() function to create a pipe to

talk to a child.
• It must do so before the child itself is created or it will not
have any way to pass a pointer to the pipe to the child.

21
• Each end of a pipe appears to the programs as a filed
the process at the head of the pipe writes to one file
descriptor while the tail process reads from another
file descriptor.
• The pipe() function returns an array of file
descriptors,
• The first for the write end and the second for the read
end.

22
 POSIX Message Queues
 POSIX supports message queues under the
_POSIX_MESSAGE_PASSING option.
 Message queues starts with “/”
 No need to create a queue before creating a process

• mq_open() – to create named queue

• mq_close() – to destroy named queue

• mq_send() – to transmit a message

• mq_receive() – to receive a message

• mq_maxmsg() – Maximum number of messages

• mq_msgsize() – Maximum size of a message
23
• The advantage of a queue over a pipe is that,
because queues have names,

• we do not have to create the pipe descriptor before

creating the other process using it, as with pipes.

• The name of a queue follows the same rules as for

semaphores and shared memory: it starts with a “/”
and contains no other “/” characters

24
Protothreads
 Protothreads
• Protothreads are extremely lightweight stackless threads
designed for severely memory constrained systems, such as
small embedded systems or wireless sensor network nodes.
• Protothreads provide linear code execution for event-driven
systems implemented in C.
• Protothreads can be used with or without an underlying
operating system to provide blocking event-handlers.
• Protothreads provide sequential flow of control without
complex state machines or full multi-threading.
 Example protothreads code
#include "pt.h"
struct pt pt;
struct timer timer;

PT_THREAD(example(struct pt *pt))
{
PT_BEGIN(pt);

while(1) {
if(initiate_io()) {
timer_start(&timer);
PT_WAIT_UNTIL(pt, io_completed() || timer_expired(&timer));
read_data();
}
}
PT_END(pt);
}
• While protothreads originally were created for
memory-constrained embedded systems, it has found
many uses as a general purpose library too.
• Examples include multimedia streaming server
software, grid computing research software, and
MPEG decoding software for Internet TVs.
Main features:
• Very small RAM overhead - only two bytes per
protothread and no extra stacks
• Highly portable - the protothreads library is 100% pure
C and no architecture specific assembly code
• Can be used with or without an OS
• Provides blocking wait without full multi-threading or
stack-switching
• Freely available under a BSD-like open source license
Example applications:
– Memory constrained systems
– Event-driven protocol stacks
– Small embedded systems
– Sensor network nodes
– Portable C applications