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: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!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: Sun, 31 Aug 2014 18:15:34 +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:188766 Date: 2014-08-31T18:15:34+02:00 List-Id: On Sun, 31 Aug 2014 09:44:26 -0600, Brad Moore wrote: > On 2014-08-31 1:02 AM, Dmitry A. Kazakov wrote: >> 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. > > I don't see this is an obstacle for Ravenscar. The clients could > register their interest in an event type by passing in a reference to > their IO_Response_T object, and when an event of that type occurs, the > server could call 'Set' on the list of all registered IO_Response_T > objects associated with that I/O event type. You mean one request queued in several queues? This would have a race condition and also have no guarantee that no event is lost. The schema has a procedure to pulse the event, as the entry is already spent. So the stuff will leak. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de