From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Portable memory barrier? Date: Mon, 15 May 2017 17:53:43 -0500 Organization: JSA Research & Innovation Message-ID: References: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1494888824 19841 24.196.82.226 (15 May 2017 22:53:44 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 15 May 2017 22:53:44 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:46793 Date: 2017-05-15T17:53:43-05:00 List-Id: "Dmitry A. Kazakov" 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.