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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Portable memory barrier? Date: Thu, 11 May 2017 09:36:07 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> <7b0c08eb-be62-4d14-ae99-cad038ad0a62@googlegroups.com> <077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com> <3edf3e1a-e823-40f5-9227-04642101895b@googlegroups.com> NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:46762 Date: 2017-05-11T09:36:07+02:00 List-Id: On 11/05/2017 00:56, Jere wrote: > On Wednesday, May 10, 2017 at 1:26:00 AM UTC-4, J-P. Rosen wrote: >> Le 10/05/2017 à 02:51, Jere a écrit : >>> Is there a method besides Atomic? If I am implementing a generic FIFO (lock >>> free) and the FIFO elements are complex data types that may not be able to be >>> atomic, do I have any other options or are protected objects my only way out? >> >> Protected objects, or for a lower level, Synchronous_Task_Control. I >> know that you want lock free algorithms, but out of curiosity, did you >> measure the cost of locking algorithms? IOW, is all of this worth the >> trouble? > I wasn't necessarily aiming for a specific speed/cost. I know I can easily > find a standard task safe container and use that and it might be faster (or at > least fast enough) on various platforms. This is more for a different option > from the normal. It might be faster on some platforms or slower, but it is > mostly meant to be a tool in toolkit. One issue is granularity of locking. If container operation is not instant, and that depends on the nature of the elements, doing that on the context of protected action is a bad idea. The solution for protected objects is of using a mutex to guard the operation outside the protected action. The cost is two protected actions per operation instead of one. A lock-free implementation does not have this issue. Note that whether the FIFO index is atomic or in a protected object is no matter. In both cases the method is lock-free. So, Jere, when you become ARG (:-)), please, push for requirement to support Atomic for all scalar objects. If the machine lacks corresponding instructions the compiler must fall back to a protected object. And conversely, if there is a strong case that using a protected action might be more efficient than machine's atomic access instructions, the compiler should use the former. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de