The mechanism used in Figure 13.13 to make scheduler code reentrant employs a single OS-provided lock for all the scheduling data structures of the application. Among other things, this mechanism prevents threads on separate processors from performing P or V operations on unrelated semaphores, even when none of the operations needs to block. Can you devise another synchronization mechanism for scheduler-related operations that admits a higher degree of concurrency but that is still correct?

Figure 13.13

Transcribed Image Text:

shared scheduler.Jock : low_levelJock shared ready Jist : queue of thread per-process private current.thread : thread procedure reschedule() -- assume that scheduler_lock is already held and that timer signals are disabled t: thread loop t:= dequeuelready_list) if t+ null exit -- else wait for a thread to become runnable release lock(scheduler lock) -- window allows another thread to access ready.list (no point in reenabling -- signals; we're already trying to switch to a different thread) acquire Jocklscheduler lock) transfer(t) -- caller must release scheduler.lock and reenable timer signals after we return procedure yield() disable signals() acquire lock(scheduler lock) enqueuelready.list, current.thread) reschedule() release locklscheduler.lock) reenable_signals() procedure sleep.on(ref Q: queue of thread) -- assume that caller has already disabled timer signals and acquired -- scheduler lock, and will reverse these actions when we return enqueue(Q, current thread) reschedule()