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 opens for writing W1

4. W1 writes message M1 W1 M1

5. W2 opens mailbox W1W2 M1

6. W1 closes mailbox W2 M1

7. R1 opens mailbox W2 R1 M1

8. R1 will find message M1 W2 R1 M1

9. Same outcome for R2 instead of W2 R1 M1 R2

10. W1 opens for writing W1

11. W1 writes message M1 W1 M1

12. W1 closes mailbox M1

13. W2 opens mailbox W2 M1

14. R1 opens mailbox W2 R1 M1

15. R1 will not find M1 W2 R1 M1

16. W2 writes M2 W2 M2 R1

17. R1 will receive M2 W2 R1 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. 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 doesn’t fix the problem with interrupting getchar(); Locking alone isn’t 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.