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: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx18.iad.POSTED!not-for-mail From: Brad Moore User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: STM32F4 Discovery, communication and libraries 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> In-Reply-To: <1xrcksk78afho$.xz6vgakq9o4t.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 68.145.219.148 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: 1409499865 68.145.219.148 (Sun, 31 Aug 2014 15:44:25 UTC) NNTP-Posting-Date: Sun, 31 Aug 2014 15:44:25 UTC Date: Sun, 31 Aug 2014 09:44:26 -0600 X-Received-Bytes: 3764 X-Received-Body-CRC: 1712680828 X-Original-Bytes: 3682 Xref: number.nntp.dca.giganews.com comp.lang.ada:188765 Date: 2014-08-31T09:44:26-06:00 List-Id: On 2014-08-31 1:02 AM, Dmitry A. Kazakov wrote: > On Fri, 29 Aug 2014 19:31:00 +0300, Niklas Holsti wrote: > >> For example (from memory, not tested): > > [...] > >> Did that answer your question? > > Sort of. > > No_Local_Protected_Objects means all requests are pre-allocated at the > library level and distributed by another protected object? Not necessarily, see below. With busy > waiting for a free request? Not necessarily, see below. > > 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. Or am I not understanding your requirements? Incidentally, IO_Response_T could also be modified to be just a regular record type, or private type that contains a reference to a suspension object. There are no Ravenscar restrictions that forbid suspension objects from being declared at nested levels. So, if a particular task can create multiple requests, and does not always have to wait for the request to complete, then it should be able to declare IO_Response_T objects at nested levels, if implemented to use suspension objects instead of protected objects. While the client task is waiting on a suspension object it is blocked, and thus not spin waiting (competing for the available execution resources that it requires to run) > > It seems that Ravenscar has a barrier that does not allow crossing the > border between 1-1 to 1-n or n-1. > > It might do what you wanted, but it does not look scalable for the OP's > purpose. >