Date: Tue, 20 Dec 2005 11:39:33 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Luigi Rizzo <rizzo@icir.org>, Suleiman Souhlal <ssouhlal@freebsd.org> Subject: Re: td->td_critnest manipulations do not use atomic_add_int ? Message-ID: <200512201139.35723.jhb@freebsd.org> In-Reply-To: <20051220081611.A36159@xorpc.icir.org> References: <20051220032538.A33093@xorpc.icir.org> <43A8166C.9060401@FreeBSD.org> <20051220081611.A36159@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 20 December 2005 11:16 am, Luigi Rizzo wrote: > On Tue, Dec 20, 2005 at 06:34:20AM -0800, Suleiman Souhlal wrote: > > Hello Luigi, > > > > Luigi Rizzo wrote: > > > as in the subject... i see that td->td_critnest (used to determine > > > whether a thread can be preempted or not) is manipulated using > > > plain ++ or -- instruction instead of the atomic_add_int(). > > > > This should be fine as it only gets modified by the current thread. If > > an interrupt comes while we are decreasing td_critnest back to 0, then > > we just don't get preempted immediately, but at the end of our quantum, > > or when someone else tries to preempt us, whichever comes first, which > > should be totally harmless. > > i think that there are still some potential race conditions if > the variable is read from another processor to make a decision > based on its value. It's not, that's the key. It's only read by the current thread. Because of sched_lock being held when a thread context switches (and thus anytime it migrates) and the membars it contains, no other locking is needed for data that only curthread accesses. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512201139.35723.jhb>