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>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0208281417451.93005-100000>
