Re: Timeout and SMP race

2002-07-11 Thread Justin T. Gibbs
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

Re: Timeout and SMP race

2002-07-11 Thread David Xu
--- 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

Re: Timeout and SMP race

2002-07-10 Thread John Baldwin
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

Re: Timeout and SMP race

2002-07-10 Thread Archie Cobbs
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

Re: Timeout and SMP race

2002-07-10 Thread John Baldwin
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

Re: Timeout and SMP race

2002-07-10 Thread Archie Cobbs
[ 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

Re: Timeout and SMP race

2002-07-10 Thread Julian Elischer
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

Re: Timeout and SMP race

2002-07-09 Thread Archie Cobbs
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

RE: Timeout and SMP race

2002-07-08 Thread John Baldwin
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 behaviour, besides this, everywhere callout_stop() is used need

Re: Timeout and SMP race

2002-07-08 Thread David Xu
: 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

Re: Timeout and SMP race

2002-07-08 Thread John Baldwin
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

Re: Timeout and SMP race

2002-07-08 Thread David Xu
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

Re: Timeout and SMP race

2002-07-04 Thread Julian Elischer
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

Re: Timeout and SMP race

2002-07-04 Thread David Xu
- 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

Re: Timeout and SMP race

2002-07-04 Thread Bruce Evans
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

Re: Timeout and SMP race

2002-07-04 Thread David Xu
, 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

Re: Timeout and SMP race

2002-07-04 Thread Jonathan Lemon
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

Re: Timeout and SMP race

2002-07-04 Thread Bruce Evans
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

Re: Timeout and SMP race

2002-07-04 Thread Jonathan Lemon
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

Timeout and SMP race

2002-07-03 Thread David Xu
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 used need to hold sched_lock and do a