[lkml]   [2007]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 3/7] barrier: a scalable synchonisation barrier
On Sun, Jan 28, 2007 at 04:24:35PM +0100, Ingo Molnar wrote:
> * Christoph Hellwig <> wrote:
> > On Sun, Jan 28, 2007 at 12:51:21PM +0100, Peter Zijlstra wrote:
> > > This barrier thing is constructed so that it will not write in the
> > > sync() condition (the hot path) when there are no active lock
> > > sections; thus avoiding cacheline bouncing. -- I'm just not sure how
> > > this will work out in relation to PI. We might track those in the
> > > barrier scope and boost those by the max prio of the blockers.
> >
> > Is this really needed? We seem to grow new funky locking algorithms
> > exponentially, while people already have a hard time understanding the
> > existing ones.
> yes, it's needed.

Would it be possible to come up with something common between this primitive
and the one that Oleg Nesterov put together for Jens Axboe?

Oleg's approach acquires a lock on the update side, which Peter would
not want in the uncontended case -- but perhaps there is some way to
make Oleg's approach be able to safely test both counters so as to
avoid acquiring the lock if there are no readers.

Oleg, any chance of this working? I believe it does, but have not
thought it through fully.

If it does turn out that we cannot converge these, I believe that
Peter's implementation needs an smp_mb() at both the beginning
and the end of barrier_sync(). Without the first smp_mb(), the
test in barrier_sync() might precede the prior change, and without
the second smp_mb() the barrier_sync() might slide after the following
cleanup code. (But I could easily be misunderstanding the code
using barrier_sync().)

Thanx, Paul
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-01-31 20:15    [W:0.079 / U:1.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site