Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #6283

Pseudo-atomic - atomic operations that can fail

Show all headers | View raw

http://semipublic.comp-arch.net/wiki/Pseudo-atomic

[[Pseudo-atomic]] is a term that I (Glew) have coined to refer to atomic 
operations that can fail to be atomic, such as:
* [[Load-linked/store-conditional (LL/SC)]]
* IBM z196's [[LOAD PAIR DISJOINT]]
* even [[hardware transactional memory]]
** such as [[Intel Transactional Synchronization Extensions (TSX)]]'s 
[[Restricted Transactional Memory (RTM)]], where "the [[XBEGIN]] 
instruction takes an operand that provides a relative offset to the 
fallback instruction address if the RTM region could not be successfully 
executed transactionally."

Q: what does IBM transactional memory provide? Is it pseudo-atomic, or 
does it provide guarantees?

I.e. these [[pseudo-atomic]] operations do not guarantee completion.
At least not at the instruction level.
While it is possible to imagine implementations that detect use of 
pseudo-atomic instruction sequences
and provide guarantees that certain code sequences will eventually complete.
such mechanisms are
(1) not necessarily architectural
and (2) more complicated that non-pseudo[-atomic instructions.

E.g. for [[LL/SC]] hardware could "pick up" the instructions that lie 
between the load-linked and the store-conditional,
and map them onto a vocabulary of atomic instructions such as 
[[fetch-and-op]] that is supported by the memory subsystem.
Similarly, [[LL/SC]] might be implemented using [[transactional memory 
(TM)]].

Intel's TSX documentation says

<UL>
RTM instructions do not have any data memory location associated with 
them. While
the hardware provides no guarantees as to whether an RTM region will 
ever successfully
commit transactionally, most transactions that follow the recommended 
guidelines
(See Section 8.3.8) are expected to successfully commit transactionally.
However, programmers must always provide an alternative code sequence in 
the fallback
path to guarantee forward progress. This may be as simple as acquiring a 
lock
and executing the specified code region non-transactionally. Further, a 
transaction
that always aborts on a given implementation may complete 
transactionally on a
future implementation. Therefore, programmers must ensure the code paths 
for the
transactional region and the alternative code sequence are functionally 
tested.
</UL>

GLEW OPINION: requiring alternate code paths has historically been a bad 
idea.
E.g. [[Intel Intanium ALAT]]. Now [[RTM (Restricted Transactional Memory)]]

Why, then, provide pseudo-atomicity?

* Pseudo-atomic operations allow complicated atomic operations to be 
built up out of simpler
* Plus, of course, it is easier than providing real atomicity.  Most of 
the time it works.  Most of the time may be good enough for many people, 
who may not care if it occasionally crashes when the seldom used 
alternate path is exercised.

Back to comp.arch | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Pseudo-atomic - atomic operations that can fail "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-06 20:23 -0800
  Re: Pseudo-atomic - atomic operations that can fail MitchAlsup <MitchAlsup@aol.com> - 2012-03-07 09:59 -0800
    Re: Pseudo-atomic - atomic operations that can fail "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-07 22:51 -0800
      Re: Pseudo-atomic - atomic operations that can fail MitchAlsup <MitchAlsup@aol.com> - 2012-03-08 11:09 -0800
        Re: Pseudo-atomic - atomic operations that can fail "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-08 17:14 -0800

csiph-web