Messages in this thread | | | Date | Tue, 26 Oct 2010 11:25:35 +0200 | From | Tejun Heo <> | Subject | Re: Question about synchronize_sched_expedited() |
| |
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
| |