CS452 - Real-Time Programming - Spring 2013

Lecture 10 - Name Server

Pubilc Service Annoucements

1. Due date for kernel 2: 31 May.
2. Error returns for Send
   • There can be problems when the corresponding Receive is handled.
   • There can be problems when the corresponding Reply is handled.
   • There can be problems when the receiver (or delegate) is running. In this case the receiver can Reply with the (implementation-dependent) problem described in the message.

   The kernel document describes three error returns that are required.

   • -1 & -2 are produced during the handling of Send.
   • -3 can be produced during the handling of Receive.
   • If Destroy is present, allkinds of extra errors can occur.

   General comments on the handing of errors.

   • You can add any extra errors you choose
   • There are two types of errors.

Inter-task Communication

There are two cases

Send before Receive

Receive before Send

Practical Details

• Keeping around the request
  • Send before Receive
    • request is a pointer into the sender's address space
    • sender is still blocked when copying occurs
    • request is copied from sender's address space into receiver's address space by kernel while receive is being handled.
  • Receive before Send
    • request will be copied to a pointer into the receiver's address space
    • receiver remains blocked until send occurs
    • request is copied from sender's address space into receiver's address space by kernel while send is being handled.
  • Reply
    • response is a pointer into the replier's address space
    • sender is still blocked when copying occurs
    • response is copied from replier's address space into sender's address space by kernel while reply is being handled.
• Copying inside the kernel is the reason why you want
  • unformatted messages
  • fast memcpy

Example of a Difficult Bug

A group noticed that

• Tasks that are RCV_BL are never on ReadyQs.
• The next pointer is available to link the Receiver's sendQ.

They decided to implement this optimization, using reasoning based on the following scenario.

1. Sender calls Send while receiver is in some state other than SND_BL.
2. Sender is made RCV_BL and placed on receiver's SendQ.
3. A second sender calls Send before first sender has been received.
4. The second sender is put on the first sender's next pointer. Both senders are now RCV_BL.
5. Duplicate 3 & 4 as many times as you like.
6. Receiver calls Receive and immediately has a transaction with first sender.
   • removing the first sender from the SendQ pulls the second sender onto it.
7. Receiver calls Reply; both receiver and first sender are RDY.
   • first sender's next pointer is available for use in ReadyQ.
8. Receiver runs first, calls Receive and handles second sender

Servers

What is a server?

• a task that provides service to a client task
  • tasks requesting service, clients, must know the Tid of the server
• a task that owns a resource and provides synchronized access to it.
• above,
  • `a task' owns the interface
  • other tasks may do the work

How are servers implemented?

• Receive is the key
  • Receive a request
  • Reply the response
• Sender (client, task that is making the request) blocks until the response is available. That is, sender, in effect, is running at the priority of the server between the request and its reponse
  • Server priority should be set according to the importance of the service it supplies.
  • But client priority should be considered by the server. For example, the server might have
    • one set of instructions for higher priority clients, and
    • another set of instructions for lower priority clients.

Name Server

What is a name server?

• There is a set of global execution-independent names
• There is a set of execution-dependent tasks that provide services associated with the names
• Name server maintains an up-to-date table mapping names to resources
  • Accepts requests to update the table
  • Accepts queries concerning the table

Why Do We Need a Name Server

How do You Get the Task Id of the Name Server?

1. Make it a constant across executions

Name Server API

int RegisterAs( char *name );

• One task can be registered under two names.
• Each name is associated with a single task.
• Name is \000 terminated.

int WhoIs( char *name );

• Name is \000 terminated.

Name Server Semantics

RegisterAs

• Errors
  1. Not a legal name.
     • It's up to you to decide what you will accept as legal names
  2. tid is not a task
  3. tid is not the Name Server
  4. Already somebody registered with that name
     • What does the caller do?

WhoIs

• Errors
  1. Not a legal name.
  2. tid is not a task
  3. tid is not the Name Server
  4. No task registered under that name
     • What does the caller do?

Comments

• RegisterAs overwrites.
• Why? The rule is that the name -> task map is many to one.
  • A task may have many names
  • A name may have only one task

Name Server Implementation

What does the client need to know in order to use the name server

1. its taskid
2. the requests it services
3. its API: function signatures and type definitions

User Pseudo-Code

• A structure for the request received by the name server
  1. Must be known by client
  2. It must be declared explicitly somewhere

int RegisterAs( char *name ) {
    NSstruct *req, *result;
    // pack structures
    bytes = Send( NSTid, (char *) req, sizeof(NSstruct), (char *) result, sizeof(NSstruct) );
    // unpack structures}

There are lots of possible variations.

Generic Server Code

typedef struct {
    int type;
    // other stuff
} ReqStr;

int tid;
NSstruct req;
// initialize server internals
FOREVER {
    Receive( &tid, &req, sizeof(NSstruct) );
    switch( req.type ) {
        case SERV1:
            do1( &req );
            Reply( tid, ... );
            break;
        case SERV2:
            do2( &req );
            Reply( tid, ... );
            break;
        ...
        default:
            // This should never happen
    }
}
    }
}

Name Server

1. One service associates a taskid with a name
2. The second service looks up the taskid and replys it to the requestor

Questions

1. How much will this code run?
   • When will it run?
2. What should happen when a WhoIs request is made for an unregistered name?
3. How would you implement insert & lookup?
   • Figure out
     1. What deadlines does Nameserver have?
     2. How many names will be in NameServer?
     3. How many RegisterAs? and when?
     4. How many WhoIs? and when?
4. What should be allowable as a name?

Hardware Interrupts

What is a Hardware Interrupt?

In the CPU

1. Test interrupt signal before fetching the next instruction
   • actually AND of INT and the IRQ bit in the CPSR
2. If asserted, change mode to IRQ
3. Disable interrupt in CPSR
4. Execute instruction at 0x18

In the Interrupt Control Unit (ICU)

• Several interrupts may be present when an interrupt occurs
  • One is chosen, by a priority mechanism
  • Put in a special place
  • Software can choose to ignore priority mechanism in ICU
• Clearing one interrupt may just expose another one

In the Peripheral Hardware

• Several interrupts may be present
  • ORed in peripheral hardware
  • ORed in glue hardware
  • Rare that there is a priority mechanism
• Clearing one interrupt can expose another one

When two interrupts are present

May have been two present when interrupt processing started

• in which case interrupt occurring now is known to be of lower priority

May have occurred since interrupt processing started

• in which case interrupt occurring now may be of higher priority

What happens next?

1. Kernel executes with interrupts disabled
2. Context switch into user task turns on interrupts
3. Before fetching the first user task instruction test interrupt signal
4. If asserted, re-initiate interrupt processing

Context Switches for Interrupts

Difference from Software Interrupts

It is impossible to predict where they occur

• You may have made some assumptions about when they occur

Assymmetry between User Task and Kernel

Scratch Registers must be saved

• including the IP

Two Link Registers

1. One to return from interrupt
   • In the registers of the interrupt handling code
   • To return to the interrupted task in the right place
2. One to move to the caller's stack frame
   • In the registers of the interrupted task
   • To return to whatever started in interrupted task

Helpful Features of the ICU

1. Several places where you can read state
2. Several places where you can block interrupt flow
3. Trigger hardware interrupt from software
   • What makes interrupts hard is that you are doing two semi-hard things at once
     1. Making the hardware produce the interrupt
     2. Responding to the interrupt
   • This allows you to separate them in developing/debugging

The Hardware in the Trains Lab

32-bit Timer

Base address: 0x80810080

Three registers:

Interrupt Control Unit (ICU)

The actual device is the ARM PL190

The logic in this design is completely asynchronous, so it functions when the CPU clock is turned off.

• Important (= essential) for low power operation.

All input signals are

• active high
• level sensitive

Base addresses

• VIC1: 0x800B0000
• VIC2: 0x800C0000

Basic Operation

VIC powers up with

• all vectored interrupts disabled.
• all interrupts masked
• all interrupts giving IRQ

Procedure

Initialization

1. leave protection off
2. enable in VICxIntEnable when you are ready to handle the interrupt

On an interrupt

1. Read VICxIRQStatus
2. Choose which interrupt you wish to handle
3. Clear the interrupt source in the device

For debugging

1. Use VICxSoftInt and VICxSoftIntClear to turn interrupt sources off and on in software

Hardware Definitions

Helpful Features of the ICU

1. Several places where you can read state
2. Several places where you can block interrupt flow
3. Trigger hardware interrupt from softwareonce
   1. What makes interrupts hard is that you are doing two semi-hard things at once
      • Making the hardware produce the interrupt
      • Responding to the interrupt
   2. Software interrupt generation allows you to separate them in developing/debugging

Non-vectored Operation

Initialization

1. Enable interrupt in device
2. Enable interrupt in ICU
3. Enable interrupt in CPU, usually by MOVS

Interrupt occurs

1. AND of IRQ and NOT( IRQ disabled bit in CPSR ) is checked before each instruction fetch.
2. If set IRQ exception is taken in place of next instruction fetch.
   • Possibly zero instructions of active task are executed.
   • Make sure that this case works
3. Context switch into kernel

   ---

   Context switch novelties

   Difference from Software Interrupts

   • It is impossible to predict where they occur
   • You may inadvertently have made some assumptions about when they occur
   • Scratch Registers must be saved
     • r0-3
     • IP -- used only very occasionally by gcc
   • Two Link Registers
     • One to return from interrupt
     • One to return from the interrupted task to whatever called it

   ---

4. Turn off interrupt in device
   • Should turn off interrupt in ICU
   • What about IRQ?

You are now ready to process the interrupt in the kernel

Return to:

• Bill Cowan's lecture notes for CS452 in s13
• Bill Cowan's Spring 2013 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page