Re: Portable memory barrier?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:of174q$13o7$1@gioia.aioe.org...
> On 11/05/2017 02:35, Randy Brukardt wrote:
>
>> Still, it would be nice to try something in this area. One could imagine
>> creating an Annex C test that implemented a lock-free algorithm and just
>> tried to see if it worked properly.
>
> The real application used socked communication. The problem I suspect is 
> that artificial tests would not show problems full-size application have. 
> Maybe, a better strategy could be specific low-level tests for atomic 
> objects used in lock-free algorithms.

That's what I was thinking. But I'm not really the person to propose such 
tests, I know just enough to be dangerous. ;-) I'd be much better served 
being just an editor on such tests, as I wouldn't have too much trouble 
seeing things that need to be more portable (I have a lot of experience 
doing that).

> And we really should extend the Annex C with some basic atomic operations 
> like atomic increment, test-then-increment, test-then-exchange etc, all 
> falling back to protected objects if the machine lacks corresponding 
> instructions.

I think you are right about that. Supposedly, implementations are supposed 
to provide access to such things via machine code insertions, but that is 
never going to be portable (even to other implementations for the same 
target). So that's not really helpful.

Perhaps you could to send a problem statement and brief proposal to 
Ada-Comment? There's still time to make suggestions for Ada 2020, and 
tasking issues of all kinds are right in the wheelhouse of what we're hoping 
to accomplish. (As always, the ARG can find ways to solve problems, the real 
issue is knowing what the problems are. I believe that you are saying that 
creating portable lock-free algorithms are harder than necessary because of 
limitations in what can be atomic and what can be safely done with atomic 
objects. That seems like an important problem for the ARG to spend some time 
on.)

                                  Randy.