How to use LL/SC in C++???

[Nemo Yu]

(LL/SC refers to Load-Linked/Store-Conditional)

As known std::atomic provides only CAS without more flexible LL/SC.

In my humble opinion, for the efficiency of my concurrent algorithm, I would rather write two pieces of code one for RISC using LL/SC and the other for CISC using x86's strong memory order, but not std::memory_order which is trying to unify RISC and CISC slowing programs down.

Inline assembly works, but breaks the optimization in some cases.

Thank you all in advance. Happy new year.

[Jens Maurer]

There is no abstraction for LL/SC in standard C++. All we have
are the atomic operations in clause 29 [atomics].

If you can make a case you need LL/SC, feel free to write a paper
to propose it. Examples welcome.

Questions I have:

- Which operations keep vs. destroy the link from the load? How do you
express that in C++, aware of potential reordering by the compiler?

- How do you implement LL/SC on a platform that has CAS only?

Jens

[Nemo Yu]

Hi Maurer,

Although you are asking me how to do it, instead of where to find it, I would still answer those questions in order.

1)

- Which operations keep vs. destroy the link from the load?  How do you
express that in C++, aware of potential reordering by the compiler?

Abstracting, not a big problem. Reordering, assembly may suffer from that.

2)

- How do you implement LL/SC on a platform that has CAS only?

Two ways. The one is providing a platform-relative library. The other is simulating, where we can use a global variable, a trigger.

I mean, it is doable, so there must be someone built a library already, isn't it? 

Jens

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.

[Andrey Semashev]

There was this discussion which can answer some of these questions:

http://lists.boost.org/Archives/boost/2015/09/225202.php

Unfortunately, I didn't get around to implement that proposal, but still
it should be doable.

[Thiago Macieira]

Em segunda-feira, 9 de janeiro de 2017, às 03:32:47 PST, Nemo Yu escreveu:
> In my humble opinion, for the efficiency of my concurrent algorithm, I
> would rather write two pieces of code one for RISC using LL/SC and the
> other for CISC using x86's strong memory order, but not std::memory_order
> which is trying to unify RISC and CISC slowing programs down.

Can you give us an example of what algorithm would benefit from an LL/SC
implementation, when compared to the weak CAS?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Victor Dyachenko]

On Monday, January 9, 2017 at 8:55:58 AM UTC+3, Thiago Macieira wrote:

Can you give us an example of what algorithm would benefit from an LL/SC
implementation, when compared to the weak CAS?

 
Second this! Is there any practical benefit? Even regardless of portability issue, e.g. if I interested only in LL/SC-platforms. Can it improve performance? If so, how much?

Disclaimer: I'm not trying to argue. Just want to hear (competent) people's opinions.

[Thiago Macieira]

I have implemented LL/SC algorithms in the past and they usually fall into one
of three categories:

1) simple compare-and-exchange, which we have (compare_exchange_weak)
2) read-modify-update, which we have (fetch_add, fetch_sub, fetch_xor, etc.)
3) ABA-prevention

I'm guessing the OP wants to do #3. With LL/SC, you can technically flag an ABA
update and reload the operation, avoiding a resource leak. The problem with
this algorithm is that LL/SC cannot guarantee success in the absence of ABA
(read: it has false negatives). And the more code you add between the LL and
the SC, the greater the chance of a false negative. Therefore, it's very
uncommon to do this in higher-level languages, where the compiler is free to
reorder and reschedule code around.

That said, the solution for ABA on CAS platforms may not apply to LL/SC
platforms: the double-wide CAS. ARMv7 has the wider LL/SC, but MIPS doesn't
have it (which is why std::atomic<uint64_t> is backed by a library).

Not to mention we don't have uint128_t in the standard anyway. So solving ABA
is difficult *anyway*.