From: user5857@newsgrouper.org.invalid
scott@slp53.sl.home (Scott Lurndal) posted:
> MitchAlsup writes:
> >
> >David Brown posted:
> >
> >> On 05/12/2025 18:57, MitchAlsup wrote:
> >> >
> >> > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >> >
> >> >> David Brown writes:
> >> >>> "volatile" /does/ provide guarantees - it just doesn't provide enough
> >> >>> guarantees for multi-threaded coding on multi-core systems.
Basically,
> >> >>> it only works at the C abstract machine level - it does nothing that
> >> >>> affects the hardware. So volatile writes are ordered at the C level,
> >> >>> but that says nothing about how they might progress through storage
> >> >>> queues, caches, inter-processor communication buses, or whatever.
> >> >>
> >> >> You describe in many words and not really to the point what can be
> >> >> explained concisely as: "volatile says nothing about memory ordering
> >> >> on hardware with weaker memory ordering than sequential consistency".
> >> >> If hardware guaranteed sequential consistency, volatile would provide
> >> >> guarantees that are as good on multi-core machines as on single-core
> >> >> machines.
> >> >>
> >> >> However, for concurrent manipulations of data structures, one wants
> >> >> atomic operations beyond load and store (even on single-core systems),
> >> >
> >> > Such as ????
> >>
> >> Atomic increment, compare-and-swap, locks, loads and stores of sizes
> >> bigger than the maximum load/store size of the processor.
> >
> >My 66000 ISA can::
> >
> >LDM/STM can LD/ST up to 32 DWs as a single ATOMIC instruction.
> >MM can MOV up to 8192 bytes as a single ATOMIC instruction.
> >
> >Compare Double, Swap Double::
> >
> >BOOLEAN DCAS( type oldp, type_t oldq,
> > type *p, type_t *q,
> > type newp, type newq )
> >{
> > type t = esmLOCKload( *p );
> > type r = esmLOCKload( *q );
> > if( t == oldp && r == oldq )
> > {
> > *p = newp;
> > esmLOCKstore( *q, newq );
> > return TRUE;
> > }
> > return FALSE;
> >}
> >
> >Move Element from one place to another:
> >
> >BOOLEAN MoveElement( Element *fr, Element *to )
> >{
> > Element *fn = esmLOCKload( fr->next );
> > Element *fp = esmLOCKload( fr->prev );
> > Element *tn = esmLOCKload( to->next );
> > esmLOCKprefetch( fn );
> > esmLOCKprefetch( fp );
> > esmLOCKprefetch( tn );
> > if( !esmINTERFERENCE() )
> > {
> > fp->next = fn;
> > fn->prev = fp;
> > to->next = fr;
> > tn->prev = fr;
> > fr->prev = to;
> > esmLOCKstore( fr->next, tn );
> > return TRUE;
> > }
> > return FALSE;
> >}
> >
> >So, I guess, you are not talking about what My 66000 cannot do, but
> >only what other ISAs cannot do.
>
> In my 40 years of SMP OS/HV work, I don't recall a
> situation where 'MoveElement' would be useful or
> required as an hardware atomic operation.
The question is not would "MoveElement" be useful, but
would it be useful to have a single ATOMIC event be
able to manipulate {5,6,7,8} pointers in one event ??
> Individual atomic "Remove Element" and "Insert/Append Element"[*], yes.
> Combined? Too inflexible.
BOOLEAN InsertElement( Element *el, Element *to )
{
tn = esmLOCKload( to->next );
esmLOCKprefetch( el );
esmLOCKprefetch( tn );
if( !esmINTERFERENCE() )
{
el->next = tn;
el->prev = to;
to->next = el;
esmLOCKstore( tn->prev, el );
return TRUE;
}
return FALSE;
}
BOOLEAN RemoveElement( Element *fr )
{
fn = esmLOCKload( fr->next );
fp = esmLOCKload( fr->prev );
esmLOCKprefetch( fn );
esmLOCKprefetch( fp );
if( !esmINTERFERENCE() )
{
fp->next = fn;
fn->prev = fp;
fr->prev = NULL;
esmLOCKstore( fr->next, NULL );
return TRUE;
}
return FALSE;
}
>
> [*] For which atomic compare-and-swap or atomic swap is generally sufficient.
>
> Atomic add/sub are useful. The other atomic math operations (min, max, etc)
> may be useful in certain cases as well.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
