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:
   for the previous post
http://sources.redhat.com/ml/ecos-discuss/2002-10/msg00070.html maybe I can
make it a little clear as follows:

when the time thread1 get switched out the context for thread1 would be like
this:

(Sparc target)

Thread1

thread1's actual operation --> "__entry_interrupt" in vectors.S -->
default_interrupt_handler --> interrupt_end( ) --> unlock_inner( ) -->
HAL_THREAD_SWITCH_CONTEXT( )

Q1.  Is the above context get saved onto the thread1's stack when interrupt
happens and makes thread2 ready to run next?

============================================================================
=================
if thread2 has the same saved execution context on thread2's stack as:

thread2's actual operation --> "__entry_interrupt" in vectors.S -->
default_interrupt_handler --> interrupt_end( ) -->
unlock_inner( ) -->HAL_THREAD_SWITCH_CONTEXT( )

Q2.  then does that mean after HAL_THREAD_SWITCH_CONTEXT( )  it will returns
from interrupt and to the actual operation of thread2??

============================================================================
====================

But if thread2's saved execution context on thread2's stack is not the same
as above: (if it is get switched out because of rescheduling as mentioned by
Nick.

thread2's actual operation --> rescheduling code -->  unlock_inner( ) -->
HAL_THREAD_SWITCH_CONTEXT( )

Q3: then when thread1 switched out and thread2 comes in, it won't returns
from the interrupt but return back from the context described above and then
to the actual thread2's operation, so when interrupt happens thread1
switched out, thread2 comes in then continues to execute but not return from
interrupt.   Is this correct?  Or other way the implemented in eCOS I miss
out?

Thanks a lot.

regards.




-----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]