lkml.org 
[lkml]   [2013]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC ticketlock] v2 Auto-queued ticketlock
On Tue, Jun 11, 2013 at 10:35:53AM -0700, Linus Torvalds wrote:
> Hmm. Something just struck me when reading this patch..
>
> Our memory ordering semantics in our *current* locks are very very
> subtle. We have just a "barrier()" between the
>
> inc.head = ACCESS_ONCE(lock->tickets.head);
> if (inc.head == inc.tail)
> break; /* success */
>
> and the inside of the locked region.
>
> I think it's safe because of the new memory ordering semantics (loads
> are in-order, and stores only move *down*), but there's not even a
> comment about it.
>
> So let's at least comment the current locks before making them even
> more complex and subtle..

Would it make sense to have something like an smp_tso() that was a
compiler barrier for TSO systems (x86, s390, sparc, etc.) but that
emitted the needed memory-barrier instruction for weakly ordered systems?

Seems to me to be easy to do, and helps describe the intent better.

Thanx, Paul



\
 
 \ /
  Last update: 2013-06-11 20:01    [W:0.568 / U:0.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site