On Wed, 7 Jun 2000, Darren Reed wrote:

> In some email I received from Eduardo Horvath, sie wrote:
> [...]
> > 3) What does this gain us over adding an interlock to tsleep()?  I know
> > what we lose: now every structure that a process might want to consider
> > sleeping on will need at least one `condvar_t'.  Each of these
> > `condvar_t's needs to be explicitly created and destroyed, which can
> > add significantly to code complexity.
> 
> This should be no more than an extra `local' variable in the appropriate
> file, along with the appropriate calls in _init(), _attach(), _detach(),
> etc, functions.  Maybe an extra member in structures.

??????  No.

Let's say I want to wait on a particular `vm_page_t'.  The `vm_page_t'
needs to contain a `condvar_t'.  Or more precisely *every* `vm_page_t' in
the system needs to contain a `condvar_t' even if it's only used in one
piece of code.  If you have 1 byte `condvar_t' and 1000 pages of RAM
that's 1K.  If the `condvar_t' is a pointer in LP64 that's 8K.  (Ignoring
structure alignment and packing issues that may waste more space.)

If you want to wait for two different condidions on a single object, say
some code wants to wait until an object is full, and another wants to wait
until it's empty, then the object requires two different condition
variables (or the code needs to check to see if the correct condition
occurred and if not go back to sleep).

(OTOH, I have not audited the kernel to see what's being waited on and
what sort of impact this will have on existing datastructures.)

Eduardo Horvath