John Baldwin writes:
> > code would be modified to fit this new behaviour,  besides this, everywhere 
> > callout_stop() is used need to hold sched_lock and do a mi_switch() and
> > modify td_flags is also unacceptable, this SMP race should be resolved in 
> > kern_timeout.c.
> How would you resolve it while still preserving the existing semantics?
> Saying "this race should be resolved" doesn't explain how you would go about
> resolving it.  It's a lot harder than it looks.

I don't know if this is the same problem or a different problem, but FWIW..

In other multi-threaded applications where a timer library is provided,
there's always the race condition between the timer firing in one thread
and the timer being stopped in the other thread.

The best solution I've come up with is to let the timer registration
routine take an optional 'lock *' argument that points to a lock
that should be acquired on behalf of the client code before invoking
the timeout handler, and released when that handler returns.

In addition, the client code acquires this same lock before any calls
to timer_start(), timer_stop(), timer_is_running(), etc. Presumably this
lock protects whatever object the timer is associated with.

This way, the timer is always definitely either running or not.

Some minor trickery is necessary in the timer code to avoid lock
reversal between the client lock and the timer code's own private
lock... but some complexity is unavoidable, and it's simpler and
less error-prone to consolidate it all in the timer library.


Archie Cobbs     *     Packet Design     *

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

Reply via email to