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: border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!news.stack.nl!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: STM32F4 Discovery, communication and libraries Date: Mon, 1 Sep 2014 18:42:19 +0200 Organization: cbb software GmbH Message-ID: References: <60a42dc6-d8d0-4432-ae5a-86de18b82840@googlegroups.com> <5kkrv9hejn2qhdckkeo8lidkbh3bkme1gn@4ax.com> <5b91313c-acf9-4a6e-b157-6ba7c8021567@googlegroups.com> <0513ad07-6fbe-463a-be6f-097cd5113f52@googlegroups.com> <4f1ec65a-d66a-40bf-a0d6-278fde206e70@googlegroups.com> <1cjwzr30b24xy.11kpydntxhfo5$.dlg@40tude.net> <1xrcksk78afho$.xz6vgakq9o4t.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: etnUhctbDQ6U1zAlbX4CBw.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: number.nntp.dca.giganews.com comp.lang.ada:188775 Date: 2014-09-01T18:42:19+02:00 List-Id: On Sun, 31 Aug 2014 21:41:15 +0300, Niklas Holsti wrote: > On 14-08-31 10:02 , Dmitry A. Kazakov wrote: >> No_Local_Protected_Objects means all requests are pre-allocated at the >> library level and distributed by another protected object? With busy >> waiting for a free request? > > No, the _request_ in my example code is not a protected object; it is an > ordinary record type. It _refers_ to a protected object which is a kind > of "I/O wait object". That was clear. >> When I evaluated Ravenscar for our middleware (long ago), the concern was >> publisher/subscriber services. I/O queue viewed as one of them. I didn't >> consider a solution like yours because the requirement was that more than >> one task could await for same I/O event. You reserve the event for single >> task and other publisher/subscriber services (e.g. the data logger, network >> data server, health monitor etc) may not use it because of >> Max_Protected_Entries = 1. The event cannot propagate because of >> No_Requeue_Statements. Tasks could flood the queue with their >> requests/events but they cannot do that for more than one queue. > > You list a lot of things there... I don't really see how they are > related to each other, or if they are separate problems. > > If for some reason you want to wake up two tasks when one I/O finishes, > the sample principle can be used: record two references, to two > protected objects - one per task - in the I/O request, and signal both > of them when the I/O completes. That is what I said. But this is only one queue. > For publish/subscribe, I would do something like this (not tested): [...] You don't need anything this complex so long you monitor a single channel. The challenge is to subscribe to several channels and also to avoid unnecessary copying of I/O data. Theoretically you could create channels that are combinations of queues of events to monitor register them by the queues. I don't know how much overhead it will be (I was trying to reduce number of protected actions per event), but it looks ugly and overly complicated. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de