Jonathan Larmour <jlarmour@redhat.com> writes:
> Rafael Rodríguez Velilla wrote:
> > 
> >   I'm working with eCos 1.3.1 and I have a question about
> > Cyg_Scheduler::unlock_inner.
> > 
> >   This method is only called when  calling Cyg_Scheduler::unlock with
> > sched_lock=1; (so it should become 0)
> >   I have seen in the code that it first calls any pending DSR (if there
> > is any) and then it checks if there's a new thread that reclaims the
> > CPU.
> >   Why is the context of the new thread restored before decrementing
> > sched_lock?
> 
> You can't be in the process of switching the context when there's a chance
> the system could be rescheduled again (e.g. due to a new interrupt).
> 
> >   Why is not the new thread run with the scheduler unlocked?
> 
> Once it is restored, it unlocks the scheduler almost straight away.

Yup.  To clarify, the new thread context is not just some random location
in the thread's execution.  It can only be either that very same location
in Cyg_Scheduler::unlock() or a similar piece of code used at the very
start of a thread's life.

You would expect that a thread which is interrupted and descheduled by a
real hardware IRQ, such as timer ticks, had a saved context that points to
what the thread was doing at the time.  But it's not so, the saved context
is in the middle of the interrupt-handling code, doing the same unlock()
call as a "normal" yield of the CPU.

So when an interrupted thread restarts, it restarts in the middle of the
normal interrupt sequence, and does all of: unlocks the scheduler, restores
the interrupted state and returns from interrupt, and thus continues where
it was interrupted.

HTH,
	- Huge