Sujet : Re: Memory ordering
De : mitchalsup (at) *nospam* aol.com (MitchAlsup1)
Groupes : comp.archDate : 29. Jul 2024, 21:43:47
Autres entêtes
Organisation : Rocksolid Light
Message-ID : <ec5f62a06185b38d1624803a0d0adf29@www.novabbs.org>
References : 1 2 3 4 5 6 7 8
User-Agent : Rocksolid Light
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".
All sorts of things were dangerous in the delay slot of a branch,
not the least of which was another branch.
Prior to the introduction of multi-threaded cores, the rounding
modes of the FPU status register were hard wired to the FU.
Afterwards, they became "just another piece of state" that got
pipelined down instruction execution.
>
[...]