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: How do I get an enctry in a protected object to block until a certain item arrives from a producer task? Date: Tue, 23 Aug 2016 21:44:20 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: xelDFTENDI+dlkJFd2Ot2w.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 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:31522 Date: 2016-08-23T21:44:20+02:00 List-Id: On 2016-08-23 19:15, john@peppermind.com wrote: > Hi! I've also asked this on Stackoverflow because I'm really stuck > with this. I have a protected object that contains an ordered hash map. > It stored events by their id as they are provided by some producer task. > Now one or more consumer tasks can obtain these events, but I need a > call that blocks the consumer until a given id has arrived while the > producer continues producing. So a simple barrier doesn't work. > > I can't find a directly applicable design pattern in my Ada books > for this, although I imagine this is some kind of FAQ. The universal pattern for this I call the "lounge pattern". It allows waiting for some condition that cannot be evaluated as a barrier or requires too many different entries (a large family of entries). Examples are waiting for a combination of events or for a specific real value or set of values, etc. The idea is as follows. You have the original entry with the parameter that is used to evaluate the condition ending waiting. The entry has no barrier. Then you have two private entries with the same parameter or a family of entries parametrized by Boolean, these are the "lounge". The lounge entries have the barrier that is True for one and False for another. You call the public entry. Within it you evaluate the condition. If satisfied you are done. If not you requeue to the lounge entry that is currently closed. You toggle barriers of the lounge entries when it makes sense to reevaluate a condition. That opens the closed lounge entry. In the entry you evaluate the condition using the parameter. Again if not satisfied you requeue to another entry and keep on waiting. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de