CS 452/652 Fall 2019 - Lecture 20

October 25, 2019 prev next

Software Design

Basics

each problem presents a complexity floor
- how many inputs?
- timing requirements?
- computational complexity?
- load & performance requirements?
no software design/engineering in the world can produce a simpler solution
but: it is possible to screw up and build an even more complex solution!

Patterns

scope of patterns
- control flow
- concurrency
- communication
- synchronization
patterns must be restrictive to be useful
- simplicity can only be attained by excluding functionality

Objectives

correctness → here: deadlock avoidance
efficiency/performance → here: maximize concurrency
maintenance: multiple developers over time
⇒ use simplest possible patterns!

Task Types

client - local logic; typically blocks on send
server - backend logic; typically blocks on receive
worker - anything else

Server Patterns

proprietor
- controls access to backend server(s)
- typically no internal buffering, serial execution
- reply before processing request
- if exclusive client to back-end server: can use Send()
```
for (;;) {
  Receive(msg)
  Reply()
  Process(msg) // interact with back-end server
}
```
administrator
- generalization of proprietor
- reorder requests, buffer requests, and/or park clients
- interact with multiple clients and servers

Worker Patterns

notifier - blocks on events (interrupts)
```
for (;;) {
  AwaitEvent()
  Send()
}
```

courier - transmits data between servers

for (;;) {
  Send(server1, req, msg); // pull from server1
  Send(server2, msg);      // push to server2
}

Suggestions

deadlock avoidance
- avoid circular send
- avoid circular receive
- ⇒ do not mix Send() & Receive() in same task!
  - notwithstanding exception in proprietor pattern (see above)
possible reference design - early paper (accessible from UW IP addresses):
- Message passing between sequential processes: The reply primitive and the administrator concept (W. Morven Gentleman)
- take it as one design idea - not necessarily perfect!