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: cheduler unlock function



On Sun, 15 Jul 2001 08:36:08 +0900
"Tony Ko" <nhko@gctsemi.com> wrote:

> hi..
> 
> //This is only called when the lock is to be decremented to zero and
> there
> // is the potential for real work to be done. Other cases are handled in
> // Cyg_Scheduler::unlock() which is an inline.
> 
> sched.cxx shows the sentence above. 
> this sentence tells when  ::unlock_inner( ) called.
> 
> But I'm confused about what if lock is NOT to be decremented to zero.
> 
> for example,
> suppose that a thread lock scheduling before doing job for his critcal
> region.
> sched_lock is going to be 1.
> and while the thread doing job for its critical region, INTERRUPT occur
> !!
> then, KERNEL ISR routine probably will lock scheduling once more.
> now, sched_lock is going to be 2.
> after KERNEL finish ISR routine, KERNEL will unlock scheduling.
> now,  sched_lock is going to be 1.
> 
> in this case, lock is not to be decremented to zero. 
> But anyway, ::unlock function is called by Kernel_isr_exit_routine.
> then ::unlock_inner( ) is called or not ?.

Nope...

In fact, if I Remenber correctly, unlock_inner is where rescheduling ,
context_switching occurs. Since you wanted to avoid this when you first
called lock, not calling unlock_inner is correct. It will be called when
your thread unlock the scehduler and count falls to 0


-- 
Fabrice Gautier <gautier@email.enstfr>


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