[ECOS] Re: question about starting point of thread context switching(sparc target)? Thanks

[Nick Garnett]

"Qiang Huang" <jameshq@liverpool.ac.uk> writes:

> Hi all:
>     could I get some help on this issue? Thanks a lot.  I have spent lots of
> time in figuring out this but I am still quite confused.
> 
> Q1.
> After the scheduler start the context of the thread with the highest
> priority (called thread1)(or maybe ready thread) will be loaded and run so
> it starts from its executing code(point). After a while interrupt happens
> and another thread (called thread2) is made ready to run, so as follow:
> 
> (Note: here thread2 is the first time to run)
> 
> scheduler starts --> thread1 context loaded and runs --> interrupt happens
> (makes thread2 ready to run the first time)--> default interrupt handler -->
> dispatch to actual isr() --> call to interrupt_end( ) --> [ unlock( ) -->
> unlock_inner( ) --> HAL_THREAD_CONTEXT_SWITCH( ) --> save the context of
> thread1--> load the context of thread2 (the context is initialized by the
> time a Cyg_Thread object is constructed)  --> jumps to thread2's executing
> code?? right?? not return back to interrupt_end( ) or executing the rest
> code in interrupt_end( )?? so it is **not** returns from the
> default_isr_handler () int vec_ivsr.S, Am I wrong?? then the "rett" in the
> very end of default_isr_handler( ) in vec_ivsr.S is not executed will that
> be any problem??

The code in the interrupt VSR to restore the state of the interrupted
thread will only be executed when that thread is scheduled again. It
merely consists of pulling register values from the thread's stack and
resuming the interrupted code.

> Q2.
> If both threads have already been started (not the first time to run) so
> when the interrupt happens and make the thread context switching happens:
> ....... as Q1 -->  call to interrupt_end( ) --> [ unlock( ) -->
> unlock_inner( ) --> HAL_THREAD_CONTEXT_SWITCH( ) --> save the context of
> thread1--> load the context of thread2 --> returns to the next instruction
> of HAL_THREAD_CONTEXT_SWITCH( ) in interrupt_end( ) (becauses the return
> address saved in thread2's context is back to the next instruction of
> HAL_THREAD_CONTEXT_SWITCH( ) in interrupt_end( ), because thread2 is ***not
> the first time to run***. Is that right?? --> return from interrpt_end( )
> back to default_isr_handler in vec_ivsr.S --> return back from
> default_isr_handler( ) back to thread2's execution context
> Is the above process for context switching correct??
>

Whether thread2 has run before is totally irrelevant to any of this --
it is initialized to look like any other thread and is resumed in
exactly the same way. Other than that, your description of how an
interrupted thread is resumed is correct.

> Does that mean after the first time of each thread runs, after the thread
> context switching the execution will returns back to the next instruction in
> interrupt_end( )? if the next context switched thread is the first time to
> run then the interrupt is
>

Interrupts are not the only way a thread can give up the
CPU. Threads can also give up the CPU voluntary by calling a
synchronization function, or changing the state of another thread so
that it preempts it. In fact, preemption by interrupt is implemented
by forcing the current thread to voluntarily give up the CPU, so the
same mechanism is used for all scheduling.

> BTW because in sparc I also need to deal with register window and stack for
> the interrupt and context switching, is there any way in understand the
> insight the kernel operation (like thread context switching) easily.
> 

Find some books that cover the subject. The uC/OS book has already
been mentioned, although it is a little light on general concepts and
concentrates on how things work in uC/OS specifically; so it may not
be much help in understanding eCos.


-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss