[lkml]   [2010]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.

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

do it;

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



 \ /
  Last update: 2010-10-26 11:29    [W:0.117 / U:2.296 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site