Re: Question about synchronize_sched_expedited()

[Tejun Heo <tj@kernel.org>]

Hello, Paul.

On 10/25/2010 09:41 PM, Paul E. McKenney wrote:
>> I think your concern is valid and this can happen w/o preemption given
>> enough cpus and perfect timing.  Was the original code free from this
>> problem?
> 
> I believe so -- there was a mutex guarding the whole operation, including
> the increment.

I see.

>> IMHO the counter based mechanism is a bit too difficult to ponder and
>> verify.  Can we do more conventional double queueing (ie. flipping
>> pending and executing queues so that multiple sync calls can get
>> coalesced while another one is in progress)?  That's what the code is
>> trying to achieve anyway, right?
> 
> Hmmm...  But it would be necessary to flip the queues somewhere, and
> wouldn't determining where that somewhere was involve the same analysis
> and complexity as determining where to increment the counter?

I was thinking something like the following.

	lock;
	if (list_empty(running))
		add myself to running
		unlock;
	else
		remember list_empty(pending)
		append myself to pending queue;
		unlock and sleep;
		if (pending wasn't empty)
			return;

	do it;

	lock;
	wake up all on running and clear it;
	list_splice_init(pending, running);
	wake up the first of running;
	unlock;

Thanks.

-- 
tejun