[ECOS] Thread states

[ECOS] Thread states

[Paleologos Spanos]

 Hi,I have a question regarding the state of thread.

-When a thread finishes its work what is its state? the "EXITED"?
 The question is if the "exited" state is  showing that the thread has
finished execution or it is the state after having exit(with the exit
function) the thread?

-If I want to stop the execution of a thread and then start it again from
the beggining again(not from the point it stopped) which
are the appropriate functions? exit and then resume,or kill and then
resume? 

-Will this thread be present on the wait_queue of the bitmap
scheduler?(assuming that we have the bitmap scheduler)

   Thank you for your interest in advance

Re: [ECOS] Thread states

[Jonathan Larmour]

Paleologos Spanos wrote:
> 
>  Hi,I have a question regarding the state of thread.
> 
> -When a thread finishes its work what is its state? the "EXITED"?
>  The question is if the "exited" state is  showing that the thread has
> finished execution or it is the state after having exit(with the exit
> function) the thread?

The former - although from your description the latter would imply the
former anyway?

> -If I want to stop the execution of a thread and then start it again from
> the beggining again(not from the point it stopped) which
> are the appropriate functions? exit and then resume,or kill and then
> resume?

I think you are a bit confused: you call cyg_thread_exit() to exit the
calling thread; you call cyg_thread_kill() to request another thread exits.

When the thread exits you can call cyg_thread_resume() on it.
 
> -Will this thread be present on the wait_queue of the bitmap
> scheduler?(assuming that we have the bitmap scheduler)

At what point?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] Thread states

[Paleologos Spanos]

 

On Wed, 10 Jan 2001, Jonathan Larmour wrote:

> Paleologos Spanos wrote:
> > 
> >  Hi,I have a question regarding the state of thread.
> > 
> > -When a thread finishes its work what is its state? the "EXITED"?
> >  The question is if the "exited" state is  showing that the thread has
> > finished execution or it is the state after having exit(with the exit
> > function) the thread?
> 
> The former - although from your description the latter would imply the
> former anyway?
> 
> > -If I want to stop the execution of a thread and then start it again from
> > the beggining again(not from the point it stopped) which
> > are the appropriate functions? exit and then resume,or kill and then
> > resume?
> 
> I think you are a bit confused: you call cyg_thread_exit() to exit the
> calling thread; you call cyg_thread_kill() to request another thread exits.
> 
> When the thread exits you can call cyg_thread_resume() on it.
>  
> > -Will this thread be present on the wait_queue of the bitmap
> > scheduler?(assuming that we have the bitmap scheduler)
> 
> At what point?
>
 From what I have understood ,the wait_queue is a number of bits with
every bit to represent a specific thread which is on the scheduler.So
every bit is 1 if the corresponding thread is waiting for execution or 0
if it has finished(EXITED state).Is this correct?
 So,in my previous mail I was asking if after a thread has completed its
execution ,will the corresponding bit on the wait_queue become 0.

     Thank you.
 
> Jifl > -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine
> 

Re: [ECOS] Thread states

[Nick Garnett]

Paleologos Spanos <paleolog@ee.ucla.edu> writes:

>  From what I have understood ,the wait_queue is a number of bits with
> every bit to represent a specific thread which is on the scheduler.So
> every bit is 1 if the corresponding thread is waiting for execution or 0
> if it has finished(EXITED state).Is this correct?

The bit will also be zero if the thread is waiting for some reason, or
has been suspended. The bit is only ever 1 if the thread is ready to
execute.

>  So,in my previous mail I was asking if after a thread has completed its
> execution ,will the corresponding bit on the wait_queue become 0.
> 

Yes, since the thread in no-longer runnable. In addition it also
deregisters itself from the scheduler so another thread could be
created with it's priority. So, if you restart the thread it may be
given a different priority.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] Thread states

[Jonathan Larmour]

Paleologos Spanos wrote:
> >
> > > -Will this thread be present on the wait_queue of the bitmap
> > > scheduler?(assuming that we have the bitmap scheduler)
> >
> > At what point?
> >
>  From what I have understood ,the wait_queue is a number of bits with
> every bit to represent a specific thread which is on the scheduler.So
> every bit is 1 if the corresponding thread is waiting for execution or 0
> if it has finished(EXITED state).Is this correct?
>  So,in my previous mail I was asking if after a thread has completed its
> execution ,will the corresponding bit on the wait_queue become 0.

Yes.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

[ECOS] Thread states

[Paleologos Spanos]

 Hi,I am working on eCos scheduler and I have a question concerning thread
states.A preempted thread is in which state?the "Suspended"?

  Actually I want to have a discrimination between preempted threads and
threads which are just beginn execution.So,for example when there is a
context switch I want to identify if this thread(next) is a preempted
thread which will continue its execution or it is a new thread which is
just beginn execution.Can I do this screening by checking the thread
states?
 If yes,which is the state for the threads in the 2 cases I mentioned?
 
    Does anyone know?
                Thank you.

[ECOS] Thread states

[Paleologos Spanos]

 Hi,I am working on eCos scheduler and I have a question concerning thread
states.A preempted thread is in which state?the "Suspended"?If,yes then in
which state is a thread which is just ready to start execution?

  Actually I want to have a discrimination between preempted threads and
threads which are just beginn execution.So,for example when there is a
context switch I want to identify if this thread(next) is a preempted
thread which will continue its execution or it is a new thread which is
just beginn execution.Can I do this screening by checking the thread
states?
 If yes,which is the state for the threads in the 2 cases I mentioned?
 
    Does anyone know?
                Thank you.

[ECOS] Thread states

[Paleologos Spanos]

 Hi,I am working on eCos scheduler and I have a question concerning thread
states.A preempted thread is in which state?the "Suspended"?Which is the
state of a thread which has finished execution?thr "Exited"?

  Actually I want to have a discrimination between preempted threads and
threads which are just beginn execution.So,for example when there is a
context switch I want to identify if this thread(next) is a preempted
thread which will continue its execution or it is a new thread which is
just beginn execution.Can I do this screening by checking the thread
states?
 If yes,which is the state for the threads in the 2 cases I mentioned?
 
    Does anyone know?
                Thank you.

Re: [ECOS] Thread states

[Jonathan Larmour]

Paleologos Spanos wrote:
> 
>  Hi,I am working on eCos scheduler and I have a question concerning thread
> states.A preempted thread is in which state?the "Suspended"?Which is the
> state of a thread which has finished execution?thr "Exited"?

If a thread is timesliced, but would otherwise still have been runnable, it
will stay in the runnable state. The full states are described in this
extract from kernel/VERSION/include/thread.hxx:

        RUNNING    = 0,          // Thread is runnable or running
        SLEEPING   = 1,          // Thread is waiting for something to
happen
        COUNTSLEEP = 2,          // Sleep in counted manner
        SUSPENDED  = 4,          // Suspend count is non-zero
        CREATING   = 8,          // Thread is being created
        EXITED     = 16,         // Thread has exited

>   Actually I want to have a discrimination between preempted threads and
> threads which are just beginn execution. So,for example when there is a
> context switch I want to identify if this thread(next) is a preempted
> thread which will continue its execution or it is a new thread which is
> just beginn execution.Can I do this screening by checking the thread
> states?
>  If yes,which is the state for the threads in the 2 cases I mentioned?

Threads are created in the suspended state, which is why they must be
explicitly resumed before they start running. And you _can_ tell the
difference between a suspended thread and a running thread, although there
is no official API to do this (it's easy for you to add yourself though).

But once the thread is resumed, you won't be able to tell. But in that
case, why not just make the thread put something in a message box (or
something similar) when the thread starts?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine