This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Question about Exception and Interrupt default VSR on MPC860


"Tony Ko" <nhko@gctsemi.com> writes:

> hi.
> I look into vectors.S in MBX860 eCos source.
> now I'm confused about 2 thinngs.
> 
> first thing, 
> There is no "scheduler_lock & scheduler_unlock routine" in Excetpion
> VSR routine(cyg_hal_default_exception_vsr).
> I mean there is "scheduler_lock & scheduler_unlock routine" in
> Interrupt VSR routine(cyg_hal_default_interrupt_vsr)
> for scheduling after interrupt service routine finished. 
> (actually, scheduler_unlock routine is inside "interrupt_end" routine )
> 

Exceptions are synchronous with the current thread - they are always
caused by the actions of that thread. So calling an exception handler
is just like making a procedure call, in a somewhat roundabout
manner. Since an exception cannot result in a rescheduling event,
there is no need to lock the scheduler. 


> 
> second thing,
> In Interrupt VSR routine, "interrupt_end" routine is called before
> "restore_state" routine is called.
> It seems that scheduling can occur  in "interrupt_end" routine. 
> ( there is scheduler_unlock routine in "interrupt_end" routine)
> This means context switching may occur before VSR finished. 
> But VSR routine is finished by processing "restore_state" routine.
> 

Rescheduling does occur in interrupt_end(), that is what it is for,
and what you describe above is exactly how it is intended to work. If
rescheduling occurs then the current thread will be descheduled, and
when it wakes up will resume in restore_state, where it will restore
the interrupted thread. 

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]