Re: Memory ordering

On 7/31/2024 1:00 AM, Chris M. Thomasson wrote:

On 7/31/2024 12:57 AM, Chris M. Thomasson wrote:

On 7/30/2024 2:47 AM, Michael S wrote:

On Mon, 29 Jul 2024 20:43:47 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:
>

On Mon, 29 Jul 2024 20:08:10 +0000, Chris M. Thomasson wrote:
>

On 7/29/2024 10:49 AM, MitchAlsup1 wrote:
[...]

A MEMBAR dropped into the pipeline, when nothing is speculative,
takes no more time than an integer ADD. Only when there is
speculation does it have to take time to relax the speculation.

>
I am wondering if you were ever aware of the "danger zone" wrt
putting a MEMBAR instruction in a memory delay slot over on the
SPARC? The docs explicitly said not to do it. I guess it can cause
some interesting memory order "issues" that might allow a running
system to last for say, five years before crashing at a random
time... Yikes!

>
Which, btw, is why one should exhaustively test atomic codes before
putting it production. You do not want to chase down a memory ordering
issue that occurs, in production, less than once a month.
>
I did a lot of programming on SPARCs and never needed a MEMBAR....
but the OS guys used them like they were "free".
>

>
Did you do programming on SPARC in RMO mode?
According to my understanding, RMO mode existed only on a couple of
SPARC CPU models (UltraSparc and UltraSparc-II) and was activated only
by OSes others than Solaris. Possibly, only by Linux.
>

All sorts of things were dangerous in the delay slot of a branch,
not the least of which was another branch.
>

>
Chris M. Thomasson wrote "memory delay slot".

>
I was not good to put a MEMBAR instruction in any branch delay slot, or any delay slot...

[...]
 Damn typos!
 It was explicitly mentioned in some docs I read around 18'ish years ago, irrc, to never put a MEMBAR instruction in a branch delay slot.
 

This was back when I getting a feel for SPARC assembly language.