Date: Tue, 9 Jul 2002 20:34:51 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: John Baldwin <jhb@FreeBSD.ORG> Cc: David Xu <davidx@viasoft.com.cn>, freebsd-current@FreeBSD.ORG, Julian Elischer <julian@elischer.org> Subject: Re: Timeout and SMP race Message-ID: <200207100334.g6A3Yp323268@arch20m.dellroad.org> In-Reply-To: <XFMail.20020708152722.jhb@FreeBSD.org> "from John Baldwin at Jul 8, 2002 03:27:22 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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 __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207100334.g6A3Yp323268>