Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Aug 2002 17:43:20 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        Jon Mini <mini@freebsd.org>
Cc:        arch@FreeBSD.ORG
Subject:   Re: Process/thread states.
Message-ID:  <Pine.BSF.4.21.0208281417451.93005-100000@InterJet.elischer.org>
In-Reply-To: <20020828205908.GB3751@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help


On Wed, 28 Aug 2002, Jon Mini wrote:

> Julian Elischer [julian@elischer.org] wrote :
> 
> > #define TD_ST_SUSPQ        0x01    /* uses runq field */
> > #define TD_ST_RUNQ         0x02    /* uses runq field */
> > #define TD_ST_RUNNING      0x03    /* uses no (virtual) field */
> > #define TD_ST_MTX          0x04    /* uses mtx field */
> > #define TD_ST_RQ_MASK      0x07    /* mask of non sleep states */
> > #define TD_ST_SLPQ         0x08    /* uses slpq field */
> + #define TD_ST_UNBOUND      0x10    /* not bound to a KSE */
> + #define TD_ST_UPCALL       0x20    /* scheduled for upcall */
> > enum thread_state {
> >         TDS_UNQUEUED    = 0x00,
> >         TDS_SLP         = TD_ST_SLPQ,
> >         TDS_RUNQ        = TD_ST_RUNQ,
> >         TDS_RUNNING     = TD_ST_RUNNING,
> >         TDS_SUSPENDED   = TD_ST_SUSPQ,
> >         TDS_MTX         = TD_ST_MTX,
> >         TDS_SUSP_SLP    = TD_ST_SUSPQ|TD_ST_SLPQ,
> >         TDS_RUN_SLP     = TD_ST_RUNNING|TD_ST_SLPQ,
> >         TDS_RUNQ_SLP    = TD_ST_RUNQ|TD_ST_SLPQ, 
> >         TDS_MTX_SLP     = TD_ST_MTX|TD_ST_SLPQ,
> >         TDS_SWAPPING    = TD_ST_SLPQ|TD_ST_RQ_MASK + 1,
> >         TDS_IWAIT,	/* needed? */
> |         TDS_SURPLUS	  = TDS_UNQUEUED|TD_ST_UNBOUND,
> +	  TDS_UPCALLING	  = TD_ST_RUNQ|TD_ST_UPCALL
> > };
> 
> This would make upcalls walk through the states like this:
> 	- In the UMA slab, the thread is TDS_SURPLUS

The value there is "undefined". The CTOR should give it a known value.


> 	- allocated as kse->ke_tdspare, still TDS_SURPLUS

TDS_UNQUEUED.

> 	- thread_schedule_upcall() grabs it, and it becomes TDS_UPCALLING

No I think it's TDS_RUNQ then.. with a qualifier in the flags of
"Upcalling".
Upcalling is not a scheduler  (run/stop/sleep/runq) state in my opinion.
It is a qualifier on how it where it will run but not how/when/if.


> 	- thread_userret() sees it, it gets bound to a KSE, and becomes
> 	  TDS_RUNNING just like any other currently running thread.

It MUST already be running by that time.
Anything that is running must be in state RUNNING.. (please!)

> 
> I hate to add another state, especially for one so fleeting, but the current
> use of td_flags for this strikes me as a bit bogus.

I think is is a flag to control it's flow of execution, and not
a shceduling state... differnt thing. I think..


> 
> OTOH, "unused" (TDS_SURPLUS) is a totally valid state.

I think that UNQUEUED could be it.. it means Not at all under the control
of the scheduler or friends.


What makes it even worse is that it looks like it MAY have to look like
this:

#define TD_ST_SUSPQ        0x01    /* uses runq field */
#define TD_ST_RUNQ         0x02    /* uses runq field */
#define TD_ST_RUNNING      0x03    /* uses no (virtual) field */
#define TD_ST_MTX          0x04    /* uses mtx field */
#define TD_ST_RQ_MASK      0x07    /* mask of non sleep states */
#define TD_ST_SLPQ         0x08    /* uses slpq field */
#define TD_ST_SWAPPPED     0x10    /* uses slpq field */
enum thread_state {
        TDS_UNQUEUED    = 0x00,
        TDS_SLP         = TD_ST_SLPQ,
        TDS_RUNQ        = TD_ST_RUNQ,
        TDS_RUNNING     = TD_ST_RUNNING,
        TDS_SUSPENDED   = TD_ST_SUSPQ,
        TDS_MTX         = TD_ST_MTX,
        TDS_SUSP_SLP    = TD_ST_SUSPQ|TD_ST_SLPQ,
        TDS_RUN_SLP     = TD_ST_RUNNING|TD_ST_SLPQ,
        TDS_RUNQ_SLP    = TD_ST_RUNQ|TD_ST_SLPQ,
        TDS_MTX_SLP     = TD_ST_MTX|TD_ST_SLPQ,
        TDS_SWAP_SLP    = TD_ST_SWAPPED|TD_ST_SLPQ,
        TDS_SWAP_SUSP   = TD_ST_SWAPPED|TD_ST_SUSPQ,
        TDS_SWAP_SUSP_SLP = TD_ST_SWAPPED|TD_ST_SLPQ|TD_ST_SUSPQ,
};

This is because threads may be on their processes suspended queue
AND on a sleep queue, (due to catching a SIGSTOP in msleep) AND
be swapped out.  It is important that the fact that they are on these two
queues NOT BE LOST, in fact while the thread is swapped out
(i.e. kernel stack and pcb are swapped out), a wakeup() event 
may occur, and it needs to be able to remove it from the sleep queue
at that time. The SIGCONT couls also occur which means that the threads 
should be taken off the suspended queue as well. All while 'swapped out'

the only thing that can't be done is to put it on the run queue
or to run it while it's swapped out, (or probably be blocked on a mutex).

Now, if a thread is unsuspended and woken up while swapped out,
then when swapped in again how do we work out what to do with it?
"if not asleep or blocked it must be runnable?"

I guess that's what happens now,..

anyhow look at teh diagram I just posted to -arch.





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0208281417451.93005-100000>