lkml.org 
[lkml]   [2016]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] mips: Fix arch_spin_unlock()
Hi Maciej,

On Wed, Jan 27, 2016 at 12:41:29PM +0000, Maciej W. Rozycki wrote:
> On Wed, 27 Jan 2016, Will Deacon wrote:
>
> > > Overall I think it should be safe after all to use SYNC_RELEASE and other
> > > modern lightweight barriers uncondtionally under the assumption that
> > > architecture was meant to remain backward compatible. Even though it
> > > might be possible someone would implement unusual semantics for the then
> > > undefined `stype' values, I highly doubt it as it would be extra effort
> > > and hardware logic space for no gain. We could try and reach architecture
> > > overseers to double-check whether the `stype' encodings, somewhat
> > > irregularly distributed, were indeed defined in a manner so as not to
> > > clash with values implementers chose to use before rev. 2.61 of the
> > > architecture specification.
> >
> > Do you know whether a SYNC 18 (RELEASE) followed in program order by a
> > SYNC 17 (ACQUIRE) creates a full barrier (i.e. something like SYNC 16)?
>
> By my reading of architecture specifications it does. Specifically
> SYNC_RELEASE (18) applies to older loads and stores, and newer stores, and
> SYNC_ACQUIRE (17) applies to older loads, and newer loads and stores. So
> the two combined ought to be the equivalent to SYNC_MB (16), which applies
> to both older and newer loads and stores. Of course care has to be taken

Hmm.. so the following reordering couldn't happen?

Program order:

LOAD A
SYNC_RELEASE
STORE B
LOAD C
SYNC_ACQUIRE
LOAD D

First becomes:

LOAD C <------------ SYNC_RELEASE doesn't order newer loads.
LOAD A
SYNC_RELEASE
STORE B
SYNC_ACQUIRE
LOAD D

And then becomes:

LOAD C
<SYNC_ACQUIRE> <---- SYNC_ACQUIRE still affect those loads.
LOAD D <------------ SYNC_RELEASE doesn't order newer loads.
LOAD A
SYNC_RELEASE
STORE B
SYNC_ACQUIRE

<SYNC_ACQUIRE> here doesn't mean that SYNC instructions can be
reordered, it here means that the reordering doesn't break
SYNC_ACQUIRE's guarantee.

I ask this because some architectures(e.g. PPC) allows this kind of
reordering. Please see "ACQUIRING FUNCTIONS" in memory-barriers.txt for
more information. Thank you ;-)

Regards,
Boqun

> about what happens between SYNC_RELEASE and SYNC_ACQUIRE. This is still
> more lightweight than classic SYNC (0). See the architecture documents,
> e.g. the MIPS32 one[1] for details.
>
> References:
>
> [1] "MIPS Architecture For Programmers, Volume II-A: The MIPS32
> Instruction Set", MIPS Technologies, Inc., Document Number: MD00086,
> Revision 5.04, December 11, 2013, Table 4.7 "Encodings of the
> Bits[10:6] of the SYNC instruction; the SType Field", p. 305
>
> HTH,
>
> Maciej
>
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2016-01-28 02:41    [W:0.171 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site