COS 318 Operating System Assignment 4 Precept 2

COS 318 - Operating System Assignment 4 (Precept 2) Inter-Process Communication and Process management Fall 2004

Mailboxes clarification Empty Unopened Mailbox

W 1 opens for writing

W 1 writes message M 1

W 2 opens mailbox

W 1 closes mailbox

R 1 opens mailbox

R 1 will find message M 1

Same outcome for R 2 instead of W 2

W 1 opens for writing

W 1 writes message M 1

W 1 closes mailbox

W 2 opens mailbox

R 1 opens mailbox

R 1 will not find M 1

W 2 writes M 2

R 1 will receive M 2

Mailbox state is reset sometime after the last close and before the first re-open

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.

Is foo() atomic ? int foo(void) { return global_shared++; } int foo(void) { return ++global_shared; } void foo(void) { global_shared++; }

Is foo() atomic ? int foo(void) { return global_shared++; } No. int foo(void) { return ++global_shared; } No. void foo(void) { global_shared++; } Depends.

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.

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();

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.

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();

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 …. }

Simplest deadlock foobar is acquire_lock(l); foo() { acquire_lock(l); …. . // deadlock on interrupt region release_lock(l); }

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); }

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.

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.

Extra credit – Kill You also need to take care of doing closing any mailbox opened by the process

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.