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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!gegeweb.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: How to: communication between multiple tasks using protected objects - with no polling? Date: Wed, 21 Jan 2015 21:02:29 +0100 Organization: cbb software GmbH Message-ID: References: <32208488-3a04-4d2a-8c64-840502dcf96d@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 0MSBVPcE8EdvhPFyEbPM4g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:24675 Date: 2015-01-21T21:02:29+01:00 List-Id: On Wed, 21 Jan 2015 09:34:51 -0800 (PST), Esa Riihonen wrote: > keskiviikko 21. tammikuuta 2015 10.28.08 UTC+2 Dmitry A. Kazakov kirjoitti: >> On Tue, 20 Jan 2015 14:36:20 -0800 (PST), Esa Riihonen wrote: >> >>> Here is the problem. My typical C-process 'listens' to several FIFOs >>> connected to separate processes. This is realized using a ppoll-type >>> 'reactor' - so in essence the process is sleeping until there is some >>> activity in any of the monitored file descriptors (I guess this is in >>> essence quite basic arrangement in the 'C-world'). >>> >>> I first thought I can implement this by the 'select' - something like this: >>> >>> PO1 and PO2 are instantiations of a protected type with entry 'Get'. >>> >>> ... >>> loop >>> ... >>> select >>> PO1.Get(...); >>> or >>> PO2.Get(...); >>> or >>> ... >>> end select; >>> ... >>> end loop; >> >> The typical design of 1-n is reverse: the publisher queues request to the >> consumer rather than lets the consumer to come and pick it. >> >> The publisher may call the consumer's entry or else queue the request into >> a queue. If publishers shall not be blocked (e.g. in order to prevent >> priority inversion or due to time constraints), also when it is n-m, use >> the blackboard instead of a queue. > > Thansk for the answer - and yes, the last one is my situation: the > publishers just report their state on certain points and then proceed > immediately in their more important stuff and should not be blocked. > I effect there is no queue inside my POs - just the most recent status > information from the associated task - I guess this is at least some kind > of a 'blackboard'. > > So - in my mind I have a small number of students each with a separete > blackboard. And instead of my teacher walking around checking whether the > answer of any of the sudents is ready - I wan't to let the teacher doze in > his/her chair and only be woken up when any of the students have their > answer ready. And after the student briefly nudges the teacher he/she must > be free to immediately continue with his/her other exams. > > I guess I just don't know how this 'blackboard' model should be implemented? You can use one blackboard for all. The item would contain the student identity, reference etc. For an implementation of lock-free blackboard see: http://www.dmitry-kazakov.de/ada/components.htm#10.2 Since you have many publishers you must lock the blackboard when writing it. Readers are still non-blocking. OK, you have just one. Now you want have a non-busy wait for an event when somebody writes something into the blackboard. That is a pulse event, see example here: http://www.dmitry-kazakov.de/ada/components.htm#11.2.2 The reader reads the blackboard until there is no new items (the reader's cursor is behind the cursor to the last item on the blackboard). Then the reader waits for an event pulsation. Note that this is a race condition. So you cannot directly use the pulse event described above (and also for reasons described below). You should modify it in a way that it would test if the reader's cursor indeed points after the blackboard end and only then enter waiting. Since this is a protected action, the event will not be signaled during the test and the race condition is eliminated. Naturally you would use a single PO for the pulse event and the write-mutex in order to minimize the number of protected actions. Protected actions are expensive. The action releasing the write-mutex will as well pulse the event [and also release the publisher's object, if reference counting used for dynamically allocated publishers.] I know it may look complicated, but it only looks so. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de