Upload
aria-newton
View
223
Download
0
Embed Size (px)
Citation preview
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.