You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has been around for a while, but the acquire fences are insufficient for RMO targets (and really dependent on fences in body of core logic of synchronization primitive). In addition to this, full fence is too strict. For this reason, we need to add a critical-section-specific primitive for proper ordering (isync is idiomatic for Power, though there is some interpretation in the architecture specification that allows lwsync in certain instances).
For common use-case, lwsync is fine but perhaps we consider exposing isync. Is it worth it? I will ping LKML folks and see what their thoughts are (in theory, isync should end up being more expensive than lwsync).
If the shared data structure is in storage that is
neither Write Through Required nor Caching Inhibited,
an lwsync instruction can be used instead of the isync
instruction. If lwsync is used, the load from "data1"
may be performed before the stwcx.. But if the
stwcx. fails, the second branch is taken and the lwarx
is reexecuted. If the stwcx. succeeds, the value
returned by the load from "data1" is valid even if the
load is performed before the stwcx., because the
lwsync ensures that the load is performed after the
instance of the lwarx that created the reservation
used by the successful stwcx.
This interface is more relevant to ARM though since we can allow more re-ordering to occur.
The text was updated successfully, but these errors were encountered:
This has been around for a while, but the acquire fences are insufficient for RMO targets (and really dependent on fences in body of core logic of synchronization primitive). In addition to this, full fence is too strict. For this reason, we need to add a critical-section-specific primitive for proper ordering (isync is idiomatic for Power, though there is some interpretation in the architecture specification that allows lwsync in certain instances).
For common use-case, lwsync is fine but perhaps we consider exposing isync. Is it worth it? I will ping LKML folks and see what their thoughts are (in theory, isync should end up being more expensive than lwsync).
For reference (http://download.boulder.ibm.com/ibmdl/pub/software/dw/library/es-ppcbook2.zip):
This interface is more relevant to ARM though since we can allow more re-ordering to occur.
The text was updated successfully, but these errors were encountered: