> On Sat, 20 Jan 2007, Andrew Doran wrote:
> 
> (thanks for the explanation btw :)
> 
> > CPU1: ltsleep()   -> acquire sched_lock    -> spin on callout_slock
> > CPU2: softclock() -> acquire callout_slock -> spin on sched_lock
> >
> > Maybe another lock could be used to protect the timeout_work queue. I'm not
> > sure how that might look.
> 
> An extra lock won't change anything I think, because it still needs to be
> taken to safely unlink the callout. I looked (superficially) at that
> before.
> 
> of the two calls, the wakeup() is not a problem since we can just
> CALLOUT_UNLOCK/CALLOUT_LOCK around it.
> 
> the ltsleep() is more problematic since I don't want to leave a gap where
> another callout can be inserted on the queue, and unlocking the
> callout_slock (without splx()) would allow another CPU to do that, yes?
> 
> I think the only way this can be integrated cleanly then would be to
> extend the callout structure with a separate link entry, because the
> callout lock is needed to safely access the one we have. But then, I
> think, the overheads start becoming significant which is not likely a good
> idea.
> 
> iain

are you still working on this?
i think something like the following should work.

YAMAMOTO Takashi

thead:
	mutex_spin_enter(&callout_thread_mutex);
	mutex_spin_enter(&callout_mutex);
	process queue
	mutex_spin_exit(&callout_mutex);
	cv_wait(, &callout_thread_mutex);
	mutex_spin_exit(&callout_thread_mutex);

softclock:
	if (thread) {
		put it on the queue
		mutex_spin_exit(&callout_mutex);
		mutex_spin_enter(&callout_thread_mutex);
		cv_signal();
		mutex_spin_exit(&callout_thread_mutex);
		mutex_spin_enter(&callout_mutex);
	}