COS%20318%20-%20Operating%20System

1
COS 318 - Operating System

• Assignment 4 (Precept 2)
• Inter-Process Communication and Process
  management
• Fall 2004

2
Mailboxes clarification
Empty Unopened Mailbox
3
W1
W1 opens for writing
4
W1
W1 writes message M1
5
W2 opens mailbox
6
W1 closes mailbox
7
R1 opens mailbox
8
R1 will find message M1
9
Same outcome for R2 instead of W2
10
W1
W1 opens for writing
11
W1
W1 writes message M1
12
W1 closes mailbox
13
W2 opens mailbox
14
R1 opens mailbox
15
R1 will not find M1
16
W2 writes M2
17
R1 will receive M2
18
Mailbox state is reset sometime after the last
close and before the first re-open
19
Atomic operations

• Operations on shared state need to be atomic
• Atomicity can be guranteed by the hardware or by
  software
• Hardware a single instruction is always atomic
• Software locks, monitors, semaphores...
• Software atomicity always derived from hardware
  support.

20
Is foo() atomic ?
int foo(void) return global_shared int
foo(void) return global_shared void
foo(void) global_shared
21
Is foo() atomic ?
int foo(void) return global_shared int
foo(void) return global_shared void
foo(void) global_shared
No. No. Depends.
22
Mailbox calls atomic or not ?
Function Void mbox_init(void) Atomic or not
No. Why Does modify global shared state. But is
guranteed to be called in isolation.
23
Mailbox calls atomic or not ?
Function int mbox_open(int key) Atomic or
not Depends upon implementation. Why If shared
state is modified, yes. Otherwise no. Same for
mbox_close()
24
Mailbox calls atomic or not ?
Function int mbox_stat(int q, int count, int
space) Doesnt modify any shared state. Does it
need to be atomic ? Answer Yes. Why For
integrity of the data read. The relation between
count and space should be maintained.
25
Mailbox calls atomic or not ?
Function int mbox_send(int q, msg_t
m) Answer Obviously Yes. Modifies count, head
and tail. Question Is that all or is more
protection needed ? Answer We need more. For
integrity of data write. Message body should be
written in continous chunk and not get
interleaved. Message aaa bbb should get
written as aaabbb or bbbaaa and not abbaba Same
for mbox_recv()
26
Why interrupts shouldnt block
Interrupts can happen anytime and in context of
any process/thread. It runs in the context of
the interrupted process and not its own. Can
deadlock if blocking for event that only
interrupted process can enable. interrupt_handler
() wait for event foobar .
27
Simplest deadlock
foobar is acquire_lock(l) foo()
acquire_lock(l) .. // deadlock on
interrupt region release_lock(l)

28
Little more subtle
foobar is busy_wait(kerry president) foo()
acquire_lock(l) .. //
deadlock on interrupt region
release_lock(l) bar()
acquire_lock(l) . // tamper with ohio
results kerry president
release_lock(l)
29
Keyboard interrupts
putchar() takes no special precaution mbox_send
() can block if buffer is full. mbox_send()
can block waiting for lock being held by
getchar() which got interrupted.
30
Keyboard interrupts
putchar() tries locking putchar() needs some
kind of locking between mbox_stat() and
mbox_send(). Still doesnt fix the problem with
interrupting getchar() Locking alone isnt the
answer.
31
Extra credit Kill

• You also need to take care of doing closing any
  mailbox opened by the process

32
Implementation notes

• Dont assume anything about behavior of other
  modules
• For eg, Mailboxes shouldn't assume anything about
  scheduler or number of processes or threads or
  their access pattern or behavior of block,
  unblock.
• Keep use of MAX_xxx limits to a minimum.