CS452 - Real-Time Programming - Fall 2008
Lecture 8 - Inter-task Communication
Questions & Comments
- Grad school
- Assignment 1 review
- context switch
- starting the first task
- creating other tasks, as requested by the first task
Debugging
Printf
- based on inb(), outb()
- busy-wait means
- reliable
- in order execution
- slow, so it may mask errors
- print out registers, memory contents by address, task descriptors,
queues, etc.
Graphics Output
GRUB
Breakpoint
interactive front-end to print functionality
- usually compiled into code
- could be attached to NMI
Autopsy
Could be Breakpoint, starting when you do NMI
Gossip
Circular buffer somewhere in memory, where log messages are placed
- much faster than printf, so you can leave it turned on
- choose amount of output and size of buffer to determine how much of the
past you see
- make it accessible from Breakpoint
History buffers
Permanent versions of gossip, so must be more selective
Use Bits
Data structure somewhere in memory where bits are set when significant
events occur
- make it accessible (and interpreted?) by Breakpoint
The Trace Bit
Causes the CPU to take an exception at the end of each instruction
- usually goes into Breakpoint, with some default printing, like register
contents
Message Passing
Let's think about objects
- Send a message to an object, asking it to run some code for us, and
return an response
We normally think about this in a single threaded way, like a procedure
call
- Call a method and block
- Method is just sitting, waiting for the call and immediately starts to
execute
- When it's finished executing ut returns a result.
- We are no longer blocked and continue executing.
- The method goes back to sitting, waiting
In an environment with multiple threads of control
- Several threads might call the same method
- or different methods within the same object
at the same time.
- Then the object needs to be `thread-safe'
- aware that there may be simultaneous execution
- use monitors, or whatever
- The object worries about the details
- but this makes the object very difficult to create, OR
- if the object isn't thread-safe makes user code very difficult to
write
To make the last easier we make the communnication more explicit than it
is in a method call
- To call the method a task calls
Send
with an argument that
indicates which code is to be executed and its environment
- To indicate its readiness to execute the object calls
Receive
, which returns which code is to be executed and its
environment
- To indicate that the code has completed its execution the object calls
Reply
with an argument that indicates the result of the
execution
Send
returns within the task, with the result of the
execution
Synchronization details
Send
blocks the caller
- Either it has to block sometime
- Or it needs to poll
- Or it needs to split into multiple threads
Most of the time it needs the result before it can proceed further
Receive
blocks the callee
- Which makes it easy for the object to control how many executions
it is performing
- And obviates the need for multiple threads
Reply
blocks nobody
- The transaction is complete
What practical things can be going on in the sender?
- Getting some information that's needed
- Making a request for a service
- Output some characters
- Create a new task
Waiting for something
- Input to be available
- a particular time
- a resource to be free
Return to: