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?

cheers -ben

��