On 26 March 2014 15:04, Ben Coman <[email protected]> wrote: > Eliot Miranda wrote: > > > > > On Tue, Mar 25, 2014 at 10:21 AM, Eliot Miranda > <[email protected]>wrote: > >> Hi Igor, >> >> >> you have a point but I disagree. The scheduler is defined in the >> implementation section of the blue book. It could be more explicit, but >> the blue book scheduler is a known and simple system. In my threading work >> I've made sure to preserve its semantics (cooperative within priorities, >> preemptive across priorities, thread switch at activation of non-primitive >> sends and backward branches). The only serious bug I know of (that >> preempting sends a process to the back of its run-queue) was addressed in >> Cog and the VW VM. We can and should write up the semantics, but they're >> not undefined, they're simple and they do work. >> > > Oops. I lie. There is a serious bug with Semaphore>>critical: and the > like. There's a suspension point after signal and before block evaluation > that can result in deadlock if a higher priority process signals the > semaphore. Since the higher priority process is running the lower priority > process never makes progress to run the ensure block or cvlear the flag or > whatever it needs to do, and hence the system deadlocks. This requires > thought ;-) So I do know of one outstanding bug. > > My grasp of concurrency controls hasn't been tested in 20 years, so > naively I would say: If a lower priority process "L" holds** a semaphore > when the higher priority process "H" signals the semaphore, temporarily > raise the priority of the "L", or temporarily lower the priority of "H". > Is there something simple that I missing? > > It really depends what you put into "priority" thing. In preemptive scheduling policy it means: threads with higher priority always preempt ones with lower one. That means that any low-priority task has no chances to advance, if there even single higher priority task that never stops.
In shared-time scheduling that means: threads with higher priority has higher % of computing resources allocated (the exact amount/ratio can depend on policy). But shared-time scheduling good in another aspect: all tasks has chance to advance, if observed over some finite time frame, regardless of their priority. The semaphores and other synchronizing primitives is not really related to scheduling. They are orthogonal, as they just giving a control over yielding execution of task (basically halting it) until some condition met. > cheers -ben > > -- Best regards, Igor Stasenko.
