CS 452/652 Fall 2019 - Lecture 9

SWI Revisited

• normal subroutine call: bl <addr>
  • automatic storage: lr := pc+4
  • control transfer to <addr>
• subroutine return: bx lr
  • alternative: mov pc, lr
  • control transfer to instruction after subroutine call.
• system call: swi N
  • mode switch: usr → svc
  • automatic storage: lr_svc := pc+4
  • N is encoded in opcode (can be retrieved via [lr_svc-4])
• system call return: movs pc, lr
  • control transfer to instruction after system call.
  • mode switch: svc → usr
• other return mechanisms possible (e.g., using ldm)

SRR Blocking

• keeping track of send-blocked senders?
  • in kernel: store with receiver's task descriptor
• keeping track of reply-blocked senders?
  • in kernel: optional, housekeeping
    beware: reply might actually originate from different task than receiver!
  • in receiver task: have only tid, no access to task descriptor!
• keeping track of receive-blocked receivers?
  • in kernel: optional, housekeeping

SRR for Producer/Consumer

• single producer, single consumer (SPSC)
  • producer sends, consumer responds with ack: "push" communication
  • consumer sends/requests, producer responds with element: "pull" communication
• multiple producers, single consumer (MPSC)
  • push communication works ⇒ producers are senders
  • pull communication: slow producer might block consumer (and thus other producers)
• single producer, multiple consumers (SPMC)
  • push communication: slow consumer might block produce (and thus other consumers)
  • pull communication works ⇒ consumers are senders
• multiple producers, multiple consumers (MPMC)
  • need intermediary: buffer ("distributor", "warehouse")
  • buffer: acts as single consumer to producers, single producer to consumers
  • buffer full or empty: block respective producer(s)/consumer(s)?
    • design decision: blocking vs. non-blocking (return error) operation
  • buffer receives requests, processes request, (delayed?) response
  • buffer never sends, only receives ⇒ server pattern

Server

• execution pattern:
  1. receive request
  2. process request
  3. (delayed) reply
• server always ready or working, never blocked!
• server never in SRR-"send" role

Name Server

• names are null-terminated character arrays
• RegisterAs() overwrites previous registration for same name
• design of name server (data structure and operation):
  • how many names?
  • how often is name server used? when?
  • performance-critical?

Timing Measurements

• duration of operation?
• first approximation:

  start := clock;
  operation;
  stop := clock;
  

  • overhead/duration of clock?
    • could measure as:

      start := clock;
      stop := clock;
      duration := (stop - start) / 2
      

  • accuracy of clock?
  • variations in operation?
• inflate impact of operation:

  start := clock;
  loop N times:
    operation;
  endloop;
  stop := clock;
  

• to be continued...