This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: ecos questions:kill safty
- From: Nick Garnett <nickg at calivar dot demon dot co dot uk>
- To: zhlg_shuhan <zhlg_shuhan at sina dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: 27 Jun 2002 10:26:37 +0100
- Subject: Re: [ECOS] ecos questions:kill safty
- References: <20020627055654.19494.qmail@sina.com>
Please always CC messages to the ecos-discuss list. This way others
may benefit from the discussion, and the messages will also be
archived for future readers.
zhlg_shuhan <zhlg_shuhan@sina.com> writes:
> Thank you ,Sir! I have get it according your hint!
> i feel you are the only engineer i can communicate with,for not many people will think so more about RTOS!
> another question:
> Is it possible that sched_lock<0?
> for example,a thread runnig with no lock(sched_lock=0 ),at that
> time,a interrupt occurs,so interrupt get cpu and runing till
> interrupt_end() in which unlock() was called,so shed_lock<0. right?
No. The scheduler lock is incremented by the HAL interrupt handling
code. The unlock in interrupt_end() just undoes this.
> running unlock_inner() and HAL_THREAD_SWITCH_CONTEXT( ¤t->stack_ptr,&next->stack_ptr )
> Is it possible that interrupt occurs? because before entering HAL_THREAD_SWITCH_CONTEXT(),it seem that interrupt maybe keep enable.(except came from ISR)
> unlock()
> |
> unlock_inner(){//sched_lock=1
>
> HAL_THREAD_SWITCH_CONTEXT<--interrupted by ISR(******)
> |
> isr_end(){
>
> unlock()<-attention!!
> |
> unlock_iner()//sched_lock=1
>
> loop once
> }
> }
> i "assume" that context (note as *******) can be saved by cpu automatically,but maybe dangerous!
>
> right?
> zhlg
Again no. You have missed the lock increment in the HAL.
--
Nick Garnett - eCos Kernel Architect
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss