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: Wed, 10 May 2017 19:35:19 -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 1494462920 2429 24.196.82.226 (11 May 2017 00:35:20 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 11 May 2017 00:35:20 +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:46755 Date: 2017-05-10T19:35:19-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:oet8mj$13ri$1@gioia.aioe.org... > On 2017-05-09 21:53, Randy Brukardt wrote: ... >> (Except that compilers might not implement it right, as I noted before.) > > So far I didn't experience problems with my implementations of lock-free > FIFO and blackboard compiled with GNAT for x86 and ARM7. > > You are right noting that this is not testable (OK, one could fully test > it under an emulator in simulated time, but who tests the emulator?). > > Yet, surprisingly, on real examples the error shows itself pretty quickly. > The background is that since GNAT does not support pragma Atomic for > 64-bit integers on 32-bit machines I have the implementation varying, > selected by GNAT project scenario. E.g. GCC built-in operations are used > instead of pragma Atomic. When the selected scenario is wrong the error > shows itself almost instantly. That doesn't surprise me that much. If you have a lock-free algorithm that gets used frequently, you're probably going to hit all of the possible states reasonably soon (assuming thousands/millions of operations get tested). The problem of course is that failure just causes erroneous execution, so formally one can't depend on anything that happens -- which of course includes displaying a failure message. 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. That certainly wouldn't catch everything, but it would catch some gross errors and at least put a spotlight on the rules in question. But that isn't my area of expertise; doing it wrong is definitely worse than not doing it at all (because of time investment to issue, then withdraw such a test after it is challenged). If someone submitted a test in this area (hint, hint!) I definitely would be interested. Randy.