Re: atomic.h cleanup

[Markus Wichmann <nullplan@gmx.net>]

On Sun, Jan 10, 2016 at 11:57:18AM -0500, Rich Felker wrote:
> On Sun, Jan 10, 2016 at 01:21:39PM +0100, Markus Wichmann wrote:
>> [...]
>> What do you say to this design?
> 
> Have you read this thread? :)
> 
> http://www.openwall.com/lists/musl/2015/05/20/1
> 
> I thought at one point it was linked from the wiki but maybe it got
> lost.
> 

Well, at least it's not on the Roadmap page. There should probably be a
wiki page for such open questions. Then people like me wouldn't have to ask
(or do extended searches in the mailing list archives, which at the
moment is only possible through your favorite search engine, BTW, which
is why I've not been doing that so often).

> Basically I have this done already outside of musl as an experiment,
> but there are minor details that were holding it up. One annoyance is
> that, on some archs, success/failure of "sc" comes via a condition
> flag which the C caller can't easily branch on, so there's an extra
> conversion to a boolean result inside the asm and extra conversion
> back to a test/branch outside the asm. In practice we probably don't
> care.
> 

Yes, and my original message showed how to deal with that:

| static inline int a_sc(volatile int* p, int x)
| {
|     __asm__ goto ("stwcx. %0, 0, %1\n\tbne- %l2" : : "r"(x), "r"(p) : "cc", "memory" : fail);
|     return 1;
| fail:
|     return 0;
| }

I tested the assembler output from both gcc and clang and it looks
alright to me (testcase attached).

As I said, we typically want to branch if SC fails, so that's how these
snippets should be written (not "branch if it succeeds", because AFAICS
the compiler can't rewrite the ASM snippets).

> One other issue is that risc-v seems to guarantee, at least on some
> implementations, stronger forward-progress guarantees than a normal
> ll/sc as long as the ll/sc are in order, within a few instruction
> slots of each other, with no branches between. Such conditions cannot
> be met without putting them in the same asm block, so we might need to
> do a custom version for risc-v if we want to take advantage of the
> stronger properties.
> 

Oh goodie, another term to research...

As far as I can see, RISC-V is another architecture. Since the scheme
I'm proposing is strictly opt-in, we can cross that bridge once we come
to it. For instance, this scheme is insufficient to support SuperH and
its three different versions of a_cas(). So I'd just leave that be for
the moment.

Ciao,
Markus