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]
Other format: [Raw text]

RE: question about starting point of thread context switching(sparc target)? Thanks


Hi all, Nick:
   Thanks a lot for your help on this question. but I still have a little
question abou it:
If the Whether thread2 has run before is totally irrelevant, in Q1 when
thread1 runs and interrupt happens (thread2 ready to run next the first
time) then goes into the default_interrupt_handler() calls to
HAL_THREAD_SWITCH_CONTEXT( ) (in interrupt_end() ) so the execution context
up to the point where HAL_THREAD_CONTEXT_SWITCH( ) is called except isr( )
and dsr( ) (which run on a seperate interrupt stack if one is avaliable).
will be saved to the stack for thread1, then load the execution context of
thread2 from the stack of thread2, then when goes to the end of
HAL_THREAD_LOAD_CONTEXT where a jump will be called directly ( if thread2 is
first time called) where will it go to? not back to the next instruction
after HAL_THREAD_SWITCH_CONTEXT( ) then does it means not returning back
from the default_interrupt_handler( ) and exit from there.  because when the
time initialising thread2 context, the return address will be to the thread2
entry point.  Is that the way interrupt cause the thread to switch?
or
thread2 should be run **after** the exiting the default_interrupt_handler?

Another question is:
If that's the way of context switching, if thread1 is switched out because
interrupt then the saved context is from before entering the interrupt and
up to the point HAL_THREAD_SWITCH_CONTEXT( ), then thread2 switched in.  if
thread2 is preempted by thread1 for no-interrupt reason, then the execution
context saved for thread2 is obviously **not** like thread1 from before
entering the interrupt and up to the point where HAL_THREAD_CONTEXT( ) is
called, but this time thread1 switched in with saved execution context
includes the interrupt return code, then it first exit the interrupt and
continue the actual thread1's operation. but the context switching for this
is not because of the interrupt but it does execute a return from interrupt
instruction where already saved as execution context for thread1 when the
time thread1 is preempted by thread2 because of interrupt.

I am so sorry about this unclear explainning coz I am so confused about
this.

also can anybody give me some help on the following topic.
http://sources.redhat.com/ml/ecos-discuss/2002-10/msg00056.html



-----Original Message-----
From: Nick Garnett [mailto:nickg@ecoscentric.com]
Sent: 02 October 2002 15:51
To: Qiang Huang
Cc: Ecos-Discuss
Subject: Re: question about starting point of thread context switching(sparc
target)? Thanks


"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


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