I believe I had this conversation with Justin Gibbs earlier; he told
me that the callout consumers (network, cam) had to be aware of the
race and handle this if it matters. I don't particularly like complicating
the callout handlers as illustrated above, though, so if a better scheme
is
--- Justin T. Gibbs [EMAIL PROTECTED] wrote:
I believe I had this conversation with Justin Gibbs earlier; he told
me that the callout consumers (network, cam) had to be aware of the
race and handle this if it matters. I don't particularly like complicating
the callout handlers as
On 10-Jul-2002 Archie Cobbs wrote:
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
John Baldwin writes:
It is the same problem. What we do is change callout_stop() to let you know if
it actually stopped the timeout or not. You then have to use your own locking
and synchronization in the timeout function and yourself to close the rest of
the race.
OK, thanks.
What do you
On 10-Jul-2002 Archie Cobbs wrote:
John Baldwin writes:
It is the same problem. What we do is change callout_stop() to let you know if
it actually stopped the timeout or not. You then have to use your own locking
and synchronization in the timeout function and yourself to close the rest of
[ NOTE: I'm moving this discussion to [EMAIL PROTECTED] ]
John Baldwin writes:
What do you think of the idea of letting the timer code (optionally)
handle all the locking and race conditions?
I'm not sure it can in a clean fashion since of the few cases I've known
so far each client
On Wed, 10 Jul 2002, Archie Cobbs wrote:
John Baldwin writes:
It is the same problem. What we do is change callout_stop() to let you know if
it actually stopped the timeout or not. You then have to use your own locking
and synchronization in the timeout function and yourself to close
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
: Tuesday, July 09, 2002 3:27 AM
Subject: RE: Timeout and SMP race
On 04-Jul-2002 David Xu wrote:
while we are getting rid of Giant, current race condition between
softclock()
and callout_stop() is unacceptable. the race causes two many places in
source
code would be modified to fit this new
On 08-Jul-2002 David Xu wrote:
I want to set an flag bit CALLOUT_PROCESSING in callout.c_flags,
before softclock() releases callout_lock and start requesting
callout.c_func(), so callout_stop can find that callout is processing
by softclock and wait, after softclock processed the callout, it
I'll work out a patch to see if my idea works.
David Xu
--- John Baldwin [EMAIL PROTECTED] wrote:
On 08-Jul-2002 David Xu wrote:
I want to set an flag bit CALLOUT_PROCESSING in callout.c_flags,
before softclock() releases callout_lock and start requesting
callout.c_func(), so
On Thu, 4 Jul 2002, David Xu wrote:
while we are getting rid of Giant, current race condition between softclock()
and callout_stop() is unacceptable. the race causes two many places in source
code would be modified to fit this new behaviour, besides this, everywhere
callout_stop() is
- Original Message -
From: Julian Elischer [EMAIL PROTECTED]
To: David Xu [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, July 04, 2002 4:36 PM
Subject: Re: Timeout and SMP race
On Thu, 4 Jul 2002, David Xu wrote:
while we are getting rid of Giant, current race
On Thu, 4 Jul 2002, David Xu wrote:
- Original Message -
From: Julian Elischer [EMAIL PROTECTED]
To: David Xu [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, July 04, 2002 4:36 PM
Subject: Re: Timeout and SMP race
On Thu, 4 Jul 2002, David Xu wrote:
while we
, I must send
it from yahoo. :(
-David Xu
- Original Message -
From: Bruce Evans [EMAIL PROTECTED]
To: David Xu [EMAIL PROTECTED]
Cc: Julian Elischer [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, July 04, 2002 7:02 PM
Subject: Re: Timeout and SMP race
On Thu, 4 Jul 2002, David
after calling callout_stop().
--
Jonathan
- Original Message -
From: Bruce Evans [EMAIL PROTECTED]
To: David Xu [EMAIL PROTECTED]
Cc: Julian Elischer [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, July 04, 2002 7:02 PM
Subject: Re: Timeout and SMP race
On Thu, 4 Jul 2002, David Xu
On Thu, 4 Jul 2002, Jonathan Lemon wrote:
In article
local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
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
On Fri, Jul 05, 2002 at 02:38:08AM +1000, Bruce Evans wrote:
On Thu, 4 Jul 2002, Jonathan Lemon wrote:
In article
local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
in RELENG_4, when one calls callout_stop() (not nested in softclock execute
path
, I am not talking about this
18 matches
Mail list logo
