110 likes | 302 Views
Coordinator: J. Rhett Aultman 11/09/2005. Project 5: Minix Semaphores. Topics. Semaphores System call semantics Providing atomicity Design in MM and kernel. System Call Semantics. Four system calls to implement: semOpen( ) semP( ) semV( ) semClose( )
E N D
Coordinator: J. Rhett Aultman 11/09/2005 Project 5: Minix Semaphores
Topics • Semaphores • System call semantics • Providing atomicity • Design in MM and kernel
System Call Semantics • Four system calls to implement: • semOpen( ) • semP( ) • semV( ) • semClose( ) • Each takes an integer key for the semaphore • Each returns an integer- 0 on success and a negative number (specified in proj. description) on failure
semOpen( ) • Checks the key passed in: • If key denotes a semaphore in use: • Check semaphore's reference count • If less than 2, increment reference count • Else, return failure • Else, determine if all 16 semaphores are in use • If so, return failure • Else, initialize a semaphore and increment its reference count to 1 and return success
semClose( ) • Checks the key passed in: • If no initialized semaphore associated with key, return failure • Else, locate semaphore and decrement reference count • If decremented count == 0, scrap the semaphore • return success
semP( ) • Checks the key passed in: • If no semaphore associated with key, return failure • Else, perform the poll-wait-decrement-return process associated with Dijkstra's P( ) • That is, if the semaphore's value is 0, wait and poll until the value is 1, then decrement the semaphore and return
semV( ) • Checks the key passed in: • If no semaphore associated with key, return failure • Else, perform the increment associated with Dijkstra's V( ) • That is, increment the semaphore's value • The semaphore's value should never be greater than 1
Hey! Where's the Atomicity? • Incrementing, decrementing, and testing a variable are not atomic • Hence special hardware-supported instructions • Are we using special instructions here? No! • Minix system calls provide atomicity • Rendezvous principle- one message at a time processed • Thus, each invocation of _syscall( ) to the MM is atomic • Ensured strict ordering of increments, decrements, and tests
But how do we wait? • Because each _syscall( ) is atomic, if you wait on the semaphore while in the MM, you will wait forever • Where is the waiting done? In the library! • Until the library returns, the application is not in control • Run the polling loop in the library; issue syscalls to the MM to check the state of the semaphore • Return to application only when the syscall reports that the semaphore's value was decremented and the critical section is clear
Semaphore bookkeeping • As in project 4, you must track the reference counts, keys, and values of 16 semaphores: #define MAXSEM 16 struct _semelm { int key; int refcount; int value; } sem_table [MAXSEM]; Don't forget that this array will initially contain random bits and must be initialized!
Getting Started • First, implement the “plumbing”- writing the .s files, editing Makefiles, picking call numbers, etc. • Only once “plumbing” for all four system calls is complete should further implementation be done • Implement and test shmOpen( ) and shmClose( ) • Implement shmV( ) and shmP( )