Date: Sat, 5 Mar 2005 05:16:01 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Scott Long <scottl@samsco.org> Cc: Colin Percival <cperciva@freebsd.org> Subject: Re: cvs commit: src/sys/kern kern_sig.c Message-ID: <20050305045443.H18897@delplex.bde.org> In-Reply-To: <422891E5.3040402@samsco.org> References: <Pine.GSO.4.43.0503031020180.2058-100000@sea.ntplx.net> <200503031116.22840.jhb@FreeBSD.org> <20050305032619.K18638@delplex.bde.org> <42288FA6.7010102@freebsd.org> <422891E5.3040402@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050305045443.H18897>