cvs commit: src/sys/kern kern_sig.c

[Bruce Evans]

On Fri, 4 Mar 2005, Scott Long wrote:

> Colin Percival wrote:
>> Bruce Evans wrote:
>> 
>>> Sleeping on a stack address is just a bug [...]
>> 
>> I was told that this was the canonical way to say "go to sleep and don't
>> wake up until the timo expires" was to tsleep() with ident equal to
>> something from the stack.
>> 
>> If this isn't correct, what is the correct way to do this?  I've seen
>> some code which does tsleep(NULL, ... ), but I was told that was also
>> wrong.

> The first argument to tsleep/msleep is just a cookie that is supposed to
> uniquely identify the sleeper for when you want to wake it up. Having
> colliding cookies isn't terrible, but it means that the other colliding
> sleepers might get woken up when they don't expect it.

It might be fatal for the other sleepers, since they can legitimately assume
that they never get woken up except under conditions under their control.

> Using NULL is no
> different than using a cookie with a very high probability of collision.

Except msleep() KASSERT()s that the cookie is not null.

> The suggestion to use a stack address from the local frame was made
> because it gives you a fairly good chance of obtaining a unique value.
> However, as Bruce points out, it's really just a side effect of the MD
> stack allocation scheme, and is no way a guarantee.  Using an address
> from the global heap is probably a better choice, but since the stacks
> are also allocated from the global heap now, there really isn't much of
> a difference.

Perople have pointed out that sleeping on the address of user struct was
common (when there was a user struct), and sleeping on the address of a
softc is a good choice for device drivers.  If you don't care about
uniqueness or about the exact timeout, then you can sleep on &lbolt.
This would give some extra wakeups, but relatively few except for very
long sleeps.

The scd driver gives another example of a bad choice.  It sleeps on the
address of a function!  This shouldn't even compile, since tsleep() takes
a "void *" and function pointers are incompatible with "void *".  Even
when the function pointer can be converted to an object pointer without
problems, its uniqueness as a cookie depends on functions being in the
same address space as objects.

Bruce