R. Clayton (rclayton@monmouth.edu)
(no date)
When a disk or terminal read or write is done, we have to unlatch the lock.
Not quite: the operating system (not "we" - watch the anthropomorphism) should
unlatch the lock when it's safe for the user process to access the buffer
included in the system call. As the answer to a question on test 2 pointed
out, this can be after the requested i-o operation is done, but in some cases
it can be sooner.
Do we do this by calling the system call unlock, which then looks for, if
any, a waiting process and makes that process ready so, it can try again?
How the os unlatches the lock is up to the os designers. In general, though,
making a system call from within the os is a tricky and dangerous business, as
well as being unnecessary. Remember what a system call is for: to transfer
control and data from a user process to the os. When it comes time to unlatch
the lock, control is already in the os, and the os has all the data it needs
(the lock id) to unlatch the lock - there is no need to make a system call.
Or do we just unlatch the lock without worrying about any processes that may
waiting to latch the lock?
I'm not understanding this question. If the os unlatches a lock without
unblocking a user process that may be waiting on the lock, how are the user
processes supposed to get unblocked?
This archive was generated by hypermail 2.0b3 on Mon Dec 16 2002 - 22:00:05 EST