lkml.org 
[lkml]   [2023]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] tools/memory-model: Make ppo a subrelation of po
> It would be nice here to have a separate term for a potentially 
> cross-CPU fence.
>
> In fact, why don't we make a concerted effort to straighten out the
> terminology more fully? Now seems like a good time to do it.
>
> To begin with, let's be more careful about the difference between an
> order-inducing object (an event or pair of events) and the relation of
> being ordered by such an object. For instance, given:
>
> A: WRITE_ONCE(x, 1);
> B: smp_mb();
> C: r1 = READ_ONCE(y);
>
> then B is an order-inducing object (a memory barrier), and (A,C) is a
> pair of events ordered by that object. In general, an order is related
> to an order-inducing object by:
>
> order = po ; [order-inducing object] ; po
>
> with suitable modifications for things like smp_store_release where
> one of the events being ordered _is_ the order-inducing event.
>
> So for example, we could consistently refer to all order-inducing events
> as either barriers or fences, and all order-reflecting relations as
> orders. This would require widespread changes to the .cat file, but I
> think it would be worthwhile.
>
> (Treating "barrier" and "fence" as synonyms seems to be too deeply
> entrenched to try and fight against.)
>
> Once that is straightened out, we can distinguish between fences or
> orders that are weak vs. strong. And then we can divide up strong
> fences/orders into single-CPU vs. cross-CPU, if we want to.
>
> How does that sound?

Sounds like a lot of work, renaming and review, for no clear win
to me. :-) But hey, if other are into it...

Andrea

\
 
 \ /
  Last update: 2023-03-26 23:46    [W:0.506 / U:1.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site