On 26 March 2014 15:04, Ben Coman <btc@openinworld.com> wrote:
Eliot Miranda wrote:
On Tue, Mar 25, 2014 at 10:21 AM, Eliot Miranda <eliot.miranda@gmail.com>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.