COS 318 - Operating System

Assignment 4 (Precept 2)

Inter-Process Communication and Process management

Fall 2004

Mailboxes clarification

Empty Unopened Mailbox

W1 opens for writing

W1

W1 writes message M1

W1

M1

W2 opens mailbox

W1 W2

M1

W1 closes mailbox

W2

M1

R1 opens mailbox

W2 R1

M1

R1 will find message M1

W2 R1

M1

Same outcome for R2 instead of W2

R1

M1

R2

W1 opens for writing

W1

W1 writes message M1

W1

M1

W1 closes mailbox

M1

W2 opens mailbox

W2

M1

R1 opens mailbox

W2 R1

M1

R1 will not find M1

W2 R1

M1

W2 writes M2

W2

M2

R1

R1 will receive M2

W2 R1

M2

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

Atomic operationsOperations on shared state need to be

atomicAtomicity can be guranteed by the

hardware or by softwareHardware – 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++;

}

int foo(void) { return ++global_shared;}

void foo(void) {global_shared++;

}

No.

No.

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 – KillYou also need to take care of doing

closing any mailbox opened by the process

Implementation notesDont assume anything about behavior of

other modulesFor 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.