Scribd
Upload
8 views

EmbeddedSoftware6

The document provides an overview of embedded systems, focusing on inter-process communication (IPC) methods such as message passing and shared memory. It discusses the advantages and disadvantages of each IPC method, including direct and indirect communication, blocking and non-blocking primitives, and different classes of service like datagrams and virtual circuits. Additionally, it introduces remote procedure calls (RPCs) as a higher-level abstraction for message passing in client-server models, highlighting their advantages and limitations.

Uploaded by

Ramiz Karaeski
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
8 views

EmbeddedSoftware6

The document provides an overview of embedded systems, focusing on inter-process communication (IPC) methods such as message passing and shared memory. It discusses the advantages and disadvantages of each IPC method, including direct and indirect communication, blocking and non-blocking primitives, and different classes of service like datagrams and virtual circuits. Additionally, it introduces remote procedure calls (RPCs) as a higher-level abstraction for message passing in client-server models, highlighting their advantages and limitations.

Uploaded by

Ramiz Karaeski
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 38

Embedded Systems

Prof. Dr. Faruk Bağcı


Prof. Dr. Mesut Güneş
CHAPTER OVERVIEW
• Introduction to Embedded Systems
• Embedded & Real-time Operating Systems
• Linux Kernel
• Peripheral Access
• Threads & Processes
• Memory
• Inter-process Communication
• Real-time Scheduling
• Interrupt Handling
• Advanced Topics
INTER-PROCESS COMMUNICATION

• Types of IPC
• Message passing
• Shared memory
• Message passing
• Blocking/non-blocking, …
• Datagrams, virtual circuits, streams
• Remote procedure calls
MESSAGE PASSING (I)

• Processes that want to exchange data send and receive


messages
• Any message exchange requires
• A send
• send(addr, msg, length);
• A receive
• receive(addr, msg, length);
MESSAGE PASSING (II)

send(…)

Sender msg Receiver

receive(…)
ADVANTAGES

• Very general
• Sender and receivers can be on different machines
• Relatively secure
• Receiver can inspect the messages it has received
before processing them
DISADVANTAGES

• Hard to use
• Every data transfer requires a send() and a
receive()
• Receiving process must expect the send()
• Might require forking a special thread
SHARED MEMORY

• Name says it
• Two or more processes share a part of their address
space

Process P
shared
Process Q
ADVANTAGES

• Fast and easy to use


• The data are there but
• Some concurrent accesses to the shared data can result
into small disasters
• Must synchronize access to shared data
• Topic will be covered in next chapter
DISADVANTAGES

• Not a general solution


• Sender and receivers must be on the same machine
• Less secure
• Processes can directly access a part of the address
space of other processes
MESSAGE PASSING

• Defining issues
• Direct/Indirect communication
• Blocking/Non-blocking primitives
• Exception handling
• Quality of service
• Unreliable/reliable datagrams
• Virtual circuits, streams
DIRECT COMMUNICATION (I)

• Send and receive system calls always specify


processes as destination or source:
• send(process, msg, length);
• receive(process, msg, length);
• Most basic solution because there is
• No intermediary between sender and receiver
AN ANALOGY

• Phones without switchboard


• Each phone is hardwired to another phone
DIRECT COMMUNICATION (II)

• Process executing the receive call must know the identity


of all processes likely to send messages
• Very bad solution for servers
• Servers have to answer requests from arbitrary processes
INDIRECT COMMUNICATION (I)

• Send and receive primitives now specify an


intermediary entity as destination or source: the
mailbox
• send(mailbox, msg, size);
• receive(mailbox, msg, size);
• Mailbox is a system object created by the kernel at the
request of a user process
AN ANALOGY (I)

• Phones with a switchboard


• Each phone can receive calls from any other phone
AN ANALOGY (II)

• Each phone has now a phone number


• Callers dial that number, not a person’s name
• Taking our phone with us allows us to receive phone
calls from everybody
INDIRECT COMMUNICATION (II)

• Different processes can send messages to the same


mailbox
• A process can receive messages from processes it does
not know anything about
• A process can wait for messages coming from
different senders
• Will answer the first message it receives
MAILBOXES

• Mailboxes can be
• Private
• Attached to a specific process
• Think of your cell phone
• Public
• System objects
• Think of a house phone
PRIVATE MAILBOXES

• Process that requested its creation and its children are the
only processes that can receive messages through the
mailbox are that process and its children
• Cease to exist when the process that requested its creation
(and all its children) terminates.
• Often called ports
• Example: BSD sockets
PUBLIC MAILBOXES

• Owned by the system


• Shared by all the processes having the right to receive
messages through it
• Survive the termination of the process that requested their
creation
• Work best when all processes are on the same machine
• Example: System V UNIX message queues
BLOCKING PRIMITIVES (I)

• A blocking send does not return until the receiving


process has received the message
• No buffering is needed
• Analogous to what is happening when you call
somebody who does not have voice mail
BLOCKING PRIMITIVES (II)

• A blocking receive does not return until a message has


been received
• Like waiting by the phone for an important message or
staying all day by your mailbox waiting for the mail
carrier
NON-BLOCKING PRIMITIVES (I)

• A non-blocking send returns as soon as the


message has been accepted for delivery by the OS
• Assumes that the OS can store the message in a
buffer
• Like mailing a letter: once the letter is dropped in the
mailbox, we are done
• The mailbox will hold your letter until a postal employee
picks it up
NON-BLOCKING PRIMITIVES (II)

• A non-blocking receive returns as soon as it has either


retrieved a message or learned that the mailbox is
empty
• Like checking whether your mail has arrived or not
NON-BLOCKING PRIMITIVES (III)

receive(…)
acts as a
retrieve(…)

Sender send(…) Receiver

Buffer
msg
SIMULATING BLOCKING RECEIVES

• Can simulate a blocking receive with a non- blocking


receive within a loop:

do {
code = receive(mbox,msg,size);
sleep(1); // delay
} while (code == EMPTY_MBOX);

• Known as a busy wait


• Costlier than a blocking wait
CLASSES OF SERVICE

• Datagrams:
• Messages are send one at time
• Virtual circuits:
• Ordered sequence of messages
• Connection-oriented service
• Streams:
• Ordered sequence of bytes
• Message boundaries are ignored
DATAGRAMS

• Each message is sent individually


• Some messages can be lost, other duplicated or arrive out
of sequence
• Equivalent of a conventional letter
• Reliable datagrams:
• resent until they are acknowledged
• Unreliable datagrams
VIRTUAL CIRCUITS (I)

• Establish a logical connection between the sender


and the receiver
• Messages are guaranteed to arrive in sequence
without lost messages or duplicated messages
• Same as the words of a phone conversation
VIRTUAL CIRCUITS (II)

• Require setting up a virtual connection before sending


any data
• Costlier than datagrams
• Best for transmitting large amounts of data that require
sending several messages
• File transfer protocol (FTP)
• Hypertext transfer protocol (HTTP)
STREAMS

• Like virtual circuits


• Do not preserve message boundaries:
• Receiver sees a seamless stream of bytes
• Offspring of UNIX philosophy
• Record boundaries do not count
• Message boundaries should not count
Remote Procedure
Calls
MOTIVATION (I)

• Apply to client-server model of computation


• A typical client-server interaction:

send_req(args); rcv_req(&args);
process(args, &results);
send_reply(results);
rcv_reply(&results);
MOTIVATION (II)

• Very similar to a procedure call to a local procedure:

xyz(args, &results); xyz(...) {


...
return;
... } // xyz

• Try to use the same formalism


THE BIG IDEA

• We could write
rpc(xyz, args, &results); xyz(...) {
...
return;
... } // xyz

and let system take care of all message passing details


ADVANTAGES

• Hides all details of message passing


• Programmer can focus on the logic of her application
• Provides a higher level of abstraction
• Extends a well-known model of programming
• Anybody that can use procedures and function can
quickly learn to use remote procedure calls
DISADVANTAGE

• The illusion is not perfect


• RPCs do not always behave exactly like regular
procedure calls
• Client and server do not share the same address space
• Programmer must remain aware of these subtle and
not so subtle differences

You might also like