Re: [ECOS] Preemptive Scheduling in Multilevel Queue Scheduler

[Bart Veer <bartv@cygnus.co.uk>]

>>>>> "Michael" == Michael Gorlick <gorlick@aero.org> writes:

    Michael> Will someone please straighten me out? After staring at
    Michael> the eCos source code it just isn't clear to me how
    Michael> preemptive (timesliced) scheduling actually works in the
    Michael> multilevel queue scheduler (mlqueue).

    Michael> The expiration of a timeslice results in a DSR being
    Michael> posted on the DSR queue and that DSR, when executed,
    Michael> forces the current thread to relinquish the processor (by
    Michael> invoking "yield()" on the current thread). However (and
    Michael> this is where my confusion arises) DSRs are executed
    Michael> when, and only when, the scheduler lock is about to
    Michael> transition from 1 to 0. Consequently, if a thread running
    Michael> under the multilevel queue discipline NEVER directly or
    Michael> indirectly invokes the scheduler "unlock()" method no
    Michael> DSRs will ever be executed and the thread will never be
    Michael> forced to yield the processor irrespective of the number
    Michael> of timeslices periods that have passed. Is this correct
    Michael> and if not where should I look in the source code to
    Michael> correct my misunderstanding?

    Michael> The same problem exists for DSRs in general since
    Michael> "unlock_inner" is the only component (as far as I can
    Michael> determine) that calls and executes the posted DSRs.
    Michael> Again, how do device drivers and interrupts get their
    Michael> DSRs executed in a timely manner if their execution can
    Michael> be delayed indefinitely by a thread that, for whatever
    Michael> reason, never acquires or releases the scheduler lock?

The missing piece in the puzzle is the routine interrupt_end() in
kernel/v1.1/src/intr/intr.cxx. This gets invoked at the end of ISR
interrupt handling, and includes a call to Cyg_Scheduler::unlock().

If an interrupt happens when the foreground application was executing
ordinary code, and a resulting DSR has invoked yield(), this call to
unlock() will result in a context switch at the end of interrupt
handling. If the foreground application was in a critical section at
the time that the interrupt occurred then the scheduler will be
locked, the interrupt handler will return to the current thread, and
the context switch happens when the thread leaves its critical section
and unlocks the scheduler.

Bart Veer // eCos net maintainer