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!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Launching background job from Ada.Real_Time.Timing_Events Date: Fri, 3 Jun 2016 09:26:48 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: vFKDMXWEWKqnQQwESBoFfw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:30568 Date: 2016-06-03T09:26:48+02:00 List-Id: On 02/06/2016 23:25, Alejandro R. Mosteo wrote: > I'm sorry but I don't follow your explanation. To make things simpler, > let's consider only the 1-to-1 case. How's this protected used without a > blocking operation? If you have FIFO, a lock-free implementation is a buffer with one read and one write index (mod buffer length). The read index never advances beyond the write index. Reader updates the read index and looks at the write index, and conversely the writer. Indices must have pragma Atomic, and the buffer not cached. For example: http://www.dmitry-kazakov.de/ada/components.htm#10.1.1 Of course if you want to wait for a FIFO state, e.g. 'not full' or 'not empty' you will need an event (a protected object). But you don't need to have the FIFO a protected object. It is an important point not to have containers protected. Operations on container might be quite expensive depending on the element types and the container structure. As a rule you should not maintain containers on the context of a protected action. E.g. if you have to do a binary search to get an element, that is not to do in a protected action. >>> Any ideas? Basically, how to trigger another task (without creating it) >>> from within a protected handler? By changing an entry barrier, of course. The task to trigger waits for a protected entry to open, it is released after leaving the entry. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de