4061 session 23 (4/10). today reader/writer locks and semaphores lock files
Post on 03-Jan-2016
Embed Size (px)
4061 Session 23 (4/10)
TodayReader/Writer Locks and SemaphoresLock Files
Todays ObjectivesDescribe semaphores and reader/writer locksPseudo-code a barrier using synchronization primitivesWrite multi-process code that coordinates file writes to avoid race conditions or interleaved outputWrite code that uses a lockfile to ensure that a single instance is running
AdminScholarshipshttp://www.cs.umn.edu/academics/undergraduate/scholarships.php Quiz 4Homework 4
Readers and Writers ProblemImagine a database system with many processes trying to read and write concurrentlyIts ok if several processes read data at the same timeBut once a process starts to write, it needs a mutexSo perhaps we want to improve on the efficiency of enforcing mutex on all operations
Strong Reader SynchronizationOne solution:ReadersFirst reader locks the write mutex.Subsequent readers allowed in (increment counter). Last reader out releases the write mutexWritersLock write mutex, write, unlockProblems?
Strong Writer SynchronizationAlternate solution:Incoming readers are queued behind any waiting writers
POSIX Read-Write LocksCalls are very similar to mutexThe main difference is that you declare whether you are attempting to obtain a read lock or a write lock (through different calls)
SemaphoresLike an integer, but with some special properties for synchronizationInitialization: any value. Subsequent use: restricted to increment and decrement. Cannot read value.When a thread decrements a semaphore and the result is negative, the thread blocks until the semaphore is no longer negative.When a thread increments a semaphore, one of the waiting threads (if any) gets unblocked.
Semaphore OperationsOperations have many namesdecrement and incrementdown and upDutch: p and vRobbins Book: wait and signalPosix: wait and postWell use wait and signal unless were discussing posix code
Semaphore as Mutexs = Semaphore(1)
Thread 1:s.wait()// critical section
// critical sections.signal()
Exercise: Barriers (1)
Exercise: BarriersSay we have n threads. Our requirement is that all n threads finish their work before our program moves forward.All threads must run the code: rendezvous critical pointNo thread can execute critical point until all threads have executed rendezvousThere are n threads. You can use this variable.When the first n-1 threads arrive they should block until the nth thread arrives, at which point all threads should proceed.
Synchronizing I/OBy default, Unix allows simultaneous, unrestricted access to filesRecall: each process with an open file gets its own entry in the open file table, and its own offset
Concurrent File AccessIf two processes have the same file open for reading, there are no problemsIf one reads and another writes, the reader will see the results of write operations immediatelyIf both are writing to the file, we can have race conditions
Race Condition in File WritesProcess A
lseek 100(context switch)
Write 50 bytesProcess B
lseek 100write 100 bytes
File LockingHow do we coordinate file access?We can use system calls to lock filesWe can lock whole files, or just sections of filesWe can lock files for read, or for write
Mandatory vs. Advisory LockingMandatoryLock enforced by the OSPrevent read() and write() from occurring when a file is lockedWorks by removing the execute permission for group and setting the setgid bitNot on by default. Need to mount the filesystem with -o mandProblems?Non-privileged processes can hold locks indefinitely. Root cannot override (except by killing the process).
Advisory LockingAdvisoryNot enforced by the OSThus, works for cooperating processes onlyProblems?Non-cooperating processes may not ask for the lockGenerally, this is the preferred/standard method for file locking
Locking: Read/WriteRead locks can be shared, but write locks cannotIf theres already a read lock, you can add another read lock, but not a write lockIf theres already a write lock, you cannot add another lock of any kind
LockfilesOpen a file with O_CREAT | O_EXCLAtomic, and fails if the file already existsFor a singleton daemon, if the lockfile creation fails with EEXIST, then the singleton is already runningWhat if the daemon crashed without removing the lockfile?Daemon writes its pid to the fileIf daemon starts up and finds the file, it reads the pidIf the process does not exist (use kill(pid, 0)) then delete the file and try again
Lockfiles (2)But, the sequence (read file, check for process, delete file) is not atomic, and therefore has a race conditionWhat can happen?Lock the file before reading itRequest exclusive lockRead fileIf the process does not exist, write your own pid, then release lock