This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: cheduler unlock function
- To: "Tony Ko" <nhko at gctsemi dot com>
- Subject: Re: [ECOS] cheduler unlock function
- From: Fabrice Gautier <gautier at email dot enst dot fr>
- Date: Sun, 15 Jul 2001 01:55:23 +0200
- Cc: <ecos-discuss at sources dot redhat dot com>
- References: <9860C773D04D834D83FD6FAD00A61E9311B70F@gctsemi.gctsemi.com>
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>