Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Dec 2005 08:16:11 -0800
From:      Luigi Rizzo <rizzo@icir.org>
To:        Suleiman Souhlal <ssouhlal@FreeBSD.org>
Cc:        current@FreeBSD.org
Subject:   Re: td->td_critnest manipulations do not use atomic_add_int ?
Message-ID:  <20051220081611.A36159@xorpc.icir.org>
In-Reply-To: <43A8166C.9060401@FreeBSD.org>; from ssouhlal@FreeBSD.org on Tue, Dec 20, 2005 at 06:34:20AM -0800
References:  <20051220032538.A33093@xorpc.icir.org> <43A8166C.9060401@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

My understanding is that when critical_enter() returns, everything
in the system should read td->td_critnest >= 1, which may not
be guaranteed by the current implementation (which doesn't have
smp locks).

There might be similar issues in the 1->0 transition.

cheers
luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051220081611.A36159>