From owner-freebsd-arch Mon Aug 26 17: 0:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C452237B400 for ; Mon, 26 Aug 2002 17:00:14 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D20343E3B for ; Mon, 26 Aug 2002 17:00:14 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020827000013.PIEY11061.sccrmhc01.attbi.com@InterJet.elischer.org> for ; Tue, 27 Aug 2002 00:00:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA84369 for ; Mon, 26 Aug 2002 16:42:56 -0700 (PDT) Date: Mon, 26 Aug 2002 16:42:55 -0700 (PDT) From: Julian Elischer To: arch@freebsd.org Subject: Process/thread states. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok so I've mentionned this to a few peopel at different times and not got any real feedback/pushback.. time fopr a wider audience. Lookingf at teh states that a thread can be in, I've come to teh conclusion that it;s not really just one easy set of states, but a graph which includes 2 and posssibly 3 independent orthogonal componets. One of my aims during teh KSE changes was to make the td_state variable truely represent the state of the thread when not under the sched lock. (Under Schedlock there can be transitional inconsitancies). However the more I look at it I see that what used to be a simple selection of: SSLEEP SRUN SSTOP SINTR is really a tremdous simplification, and often incorrect. The state is suplementted by such things as: the non-NULL-ness of th wchan field and other information regarding the swap state. As a result of this, many places that wnat to make a decision based on state of the thread (was process in 4.x) need to make extra tests which are easy to leave out.. e.g. something like: if ((td->td_state == TDS_RUNQ) && (td->td_wchan == NULL)) This is how you see if the thread is on teh run queue but not on the sleep queue.. yet teh fact that td->td_wchan == NULL isn a rather unintuative way of suplementing the state to discover if the process/thread is sleeping, especially if later on the test becomes if (td->td_state == TDS_SLP) If the test is REALLY (td->td_wchan != NULL) then why bother having a state SSLEEP (or TDS_SLP) at all? the best answer I think is to extent the state definitions to include the possibility of some orthogonal components.. e.g. something like: (yeah I know its messy but...): #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 */ 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 /* needed? */ }; this is becasue it is quite legal for the thread to be on the suspended queue AND on the sleep queue.. (!) this happens during msleep (and the CV code) and NOT under the sched lock either.. During this time the process can be 'awakened' by a 'wakeup()' which will take it off the sleep queue so that when the suspension ends, the thread does not continue into teh full sleep, but instead returns. Similarly, the thread can be on the sleep queue AND on the run queue, or even on the sleep queue but actually running. All outside of the protection of the schedlock. By allowing code to set and clear jsut the bit that represents the presense on teh sleep queue, teh sorrect state can be maintained, and the thread state can actually be used to make decisions. It is possible that the SWAPPING state may be expanded in a similar manner as well. (I haven't really examined it recently) I think the following thread state components are mutually exclusive: On the run queue. Actually running. On the processes suspend queue. On a mutex's blocked queue. orthognal to those might be:: On the sleep queue. (which can and does occur while in the above states) Not Fully swapped in, (which MAY (not sure yet) occur to a thread that is a in at least one of the basic states, and the sleep state). I'm not sure if TDS_IWAIT is needed any more and TDS_SURPLUS can pretty surely go away I think. anyway.. I'm, puting this out in -arch because I'm sure this would create howls of complaint from people if I "just did it". It seems to me that it may clean up quirte a bit of code around the sleeping and suspension parts of the system, and remove some "traps for young players" (I ran into one last week hence this RFC). over to you guys.. Particularly those who HATE the idea. p.s. for bonus points: could the mutex blocked chain be implemented using the linkage field in teh thread struct already used by the suspend and run queues, since they are all (I think) mutually exclusive..? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message