lkml.org 
[lkml]   [2018]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH] riscv/locking: Strengthen spin_lock() and spin_unlock()
On Mon, Feb 26, 2018 at 6:21 AM, Luc Maranget <luc.maranget@inria.fr> wrote:
>
> That is, locks are not implemented from more basic primitive but are specified.
> The specification can be described as behaving that way:
> - A lock behaves as a read-modify-write. the read behaving as a read-acquire

This is wrong, or perhaps just misleading.

The *whole* r-m-w acts as an acquire. Not just the read part. The
write is very much part of it.

Maybe that's what you meant, but it read to me as "just the read part
of the rmw behaves as a read-acquire".

Because it is very important that the _write_ part of the rmw is also
ordered wrt everything that is inside the spinlock.

So doing a spinlock as

(a) read-locked-acquire
modify
(c) write-conditional

would be wrong, because the accesses inside the spinlock are ordered
not just wrt the read-acquire, they have to be ordered wrt the write
too.

So it is closer to say that it's the _write_ of the r-m-w sequence
that has the acquire semantics, not the read.

> - A unlock behaves as a store release.

Yes.

Linus

\
 
 \ /
  Last update: 2018-02-26 17:07    [W:0.082 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site