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

Groups > comp.arch > #6283 > unrolled thread

Pseudo-atomic - atomic operations that can fail

Back to article view | Back to comp.arch

Contents

  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

#6283 — Pseudo-atomic - atomic operations that can fail

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.

[toc] | [next] | [standalone]

#6291

On Tuesday, March 6, 2012 10:23:39 PM UTC-6, Andy (Super) Glew wrote:
> 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.

Pseudo atomicity is the only way to extend the instruction set so that one can encode atomic activities that require more than 2 unique memory references and some bookeeping instructions between the starting of the atomic event and the completion thereof.

Mitch

[toc] | [prev] | [next] | [standalone]

#6298

On 3/7/2012 9:59 AM, MitchAlsup wrote:
> On Tuesday, March 6, 2012 10:23:39 PM UTC-6, Andy (Super) Glew wrote:
>> 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.
>
> Pseudo atomicity is the only way to extend the instruction set so that one can encode atomic activities that require more than 2 unique memory references and some bookeeping instructions between the starting of the atomic event and the completion thereof.
>
> Mitch

I believe that I have just discovered a way to prove your statement wrong.

[toc] | [prev] | [next] | [standalone]

#6307

On Thursday, March 8, 2012 12:51:05 AM UTC-6, Andy (Super) Glew wrote:
> On 3/7/2012 9:59 AM, MitchAlsup wrote:
> > Pseudo atomicity is the only way to extend the instruction set so that one can encode atomic activities that require more than 2 unique memory references and some bookeeping instructions between the starting of the atomic event and the completion thereof.

> I believe that I have just discovered a way to prove your statement wrong.

Do I need to add the phrase: "without cluttering up the instruction set" to the previous?

Mitch

[toc] | [prev] | [next] | [standalone]

#6312

On 3/8/2012 11:09 AM, MitchAlsup wrote:
> On Thursday, March 8, 2012 12:51:05 AM UTC-6, Andy (Super) Glew wrote:
>> On 3/7/2012 9:59 AM, MitchAlsup wrote:
>>> Pseudo atomicity is the only way to extend the instruction set so that one can encode atomic activities that require more than 2 unique memory references and some bookeeping instructions between the starting of the atomic event and the completion thereof.
>
>> I believe that I have just discovered a way to prove your statement wrong.
>
> Do I need to add the phrase: "without cluttering up the instruction set" to the previous?
>
> Mitch

No. I believe I have a much more scalable form of Hardware Transactional 
Memory.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web