On 04-Jul-2002 David Xu wrote:
> in RELENG_4, when one calls callout_stop() (not nested in softclock execute
> path
> , I am not talking about this case), after it returns, he can believe that the
> callout is truely stopped, however in CURRENT, this assumption is false, now we
> must care if callout_stop() truely stopped the callout when it returned, this 
> is all difference I see, we bring in this race which not exists in RELENG_4, 
> see what hacking code put in kern_condvar.c and kern_synch.c in CURRENT source,

In 4.x we don't support concurrent threads in the kernel either, so of course
we have new races to deal with.  Unfortunately there is no good way to reliably
try to synchronize callout_stop() with softclock().  The callout function may reuse
the callout structure associated with it, so we can't use that callout structure
to save any state across the call.


John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to