Date: Mon, 26 Aug 2002 17:56:26 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Archie Cobbs <archie@dellroad.org> Cc: Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG Subject: Re: Process/thread states. Message-ID: <3D6ACE3A.3D17935B@mindspring.com> References: <200208270040.g7R0ehu36981@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Archie Cobbs wrote:
> Julian Elischer writes:
> > #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 {
[ ... ]
> I like your idea.. it makes things clearer because they are more
> explicit. Whenever "implicit developer knowledge" is required to
> do something correctly that's more opportunity for bugs.
>
> If you comment those flags in the header file(s) really well,
> that's even better. Especially all of the cases where there is
> any duplicate or inter-dependent state, which can be evil.
>
> E.g., if TDS_SLP always implies wchan != NULL, then that should be
> commented somewhere.
>
> That is, any 'trickiness' in an object's state like depedence between
> fields or special invariants should either be very clearly documented
> or else hidden behind an object-like functional interface (like Alfred
> suggested).
The part that causes me a little bit of pain is that the compares
will all end up having to be:
if ( (x & VALUE) == VALUE)
or
if ( (x & VALUE) != VALUE)
To get them out of the bitmaps. This makes the compares look a
little cleaner (I guess) but it doubles the number of cycles for
each one, when the common case is/should be that only one bit is
significant (e.g. the use of McCarthy operators like && and ||
save work on failure/success, respectively).
I guess there is no way to refactor the code so that the depndencies
don't have to be tested?
-- Terry
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?3D6ACE3A.3D17935B>