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!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!news.tele.dk!news.tele.dk!small.news.tele.dk!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: STM32F4 Discovery, communication and libraries
Date: Fri, 29 Aug 2014 19:31:00 +0300
Organization: Tidorum Ltd
Message-ID: <c6bo5nF23tiU1@mid.individual.net>
References: <60a42dc6-d8d0-4432-ae5a-86de18b82840@googlegroups.com>
 <5kkrv9hejn2qhdckkeo8lidkbh3bkme1gn@4ax.com>
 <5b91313c-acf9-4a6e-b157-6ba7c8021567@googlegroups.com>
 <ru1tv9p9g8gtd7aijug3j2eojdpdgvhihk@4ax.com>
 <0513ad07-6fbe-463a-be6f-097cd5113f52@googlegroups.com>
 <e8yq8rtj1pcm$.glzqqjd7ulsi.dlg@40tude.net>
 <4f1ec65a-d66a-40bf-a0d6-278fde206e70@googlegroups.com>
 <uxgn4sadwori$.7fnns7uw9q79$.dlg@40tude.net>
 <c69kifFfr6sU1@mid.individual.net>
 <1cjwzr30b24xy.11kpydntxhfo5$.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: individual.net C6zcx9ZD2ZHCZVkbI2byugX4TdJoiGBxqDlryVnHe+7CQcwJWK
Cancel-Lock: sha1:3DlXNI799rFBu8rgCileyl59CY4=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <1cjwzr30b24xy.11kpydntxhfo5$.dlg@40tude.net>
Xref: number.nntp.dca.giganews.com comp.lang.ada:188736
Date: 2014-08-29T19:31:00+03:00
List-Id: <comp.lang.ada>

On 14-08-29 10:41 , Dmitry A. Kazakov wrote:
> On Fri, 29 Aug 2014 00:17:12 +0300, Niklas Holsti wrote:
> 
>> On 14-08-28 23:09 , Dmitry A. Kazakov wrote:
> 
>>> You could not implement an equivalent of I/O queueing under the Ravenscar
>>> constraints.
>>
>> It is certainly possible to implement an I/O request queue in Ravenscar;
>> I have done so for the platform SW on ESA's GOCE satellite. Multiple
>> client tasks, one server (interface driver) task. An I/O request
>> contains (or is, or refers to) a client-specific protected object (PO)
>> with an "I/O completed" entry, on which the client task waits after
>> enqueueing the I/O request. The server task processes submitted I/O
>> requests in any order and concurrency it chooses; when an I/O request is
>> done, the server task calls an operation on the request's PO, which
>> unblocks the entry, resuming the client task.
> 
> Looks ugly to me.

In the eye of the beholder :-)

> But I don't understand how the server's queue is accessed
> by multiple tasks concurrently? And how could you cancel a pending request
> in this schema?

For example (from memory, not tested):


   protected type IO_Response_T
   -- Each client task has an instance of this PO type.
   is

      procedure Set (Result : in  ...);
      -- Called by server task when the I/O is done.
      -- Stores the Result in the PO and unblocks Get_Result.

      entry Get (Result : out ...);
      -- Called by client to wait for I/O completion
      -- and then get the result.

   end IO_Response_T;


   type IO_Response_Ref is access all IO_Response_T;


   type IO_Request_T is record
      Xxx : ... I/O request data;
      Response : IO_Response_Ref;
   end record;


   protected Server_Queue
   -- A single instance (for one server).
   is

      procedure Enqueue (
         Request : in     IO_Request_T;
         Success :    out Boolean);
      -- Called by clients to request some I/O.
      -- If the queue was full, Success is set to False.

      entry Dequeue (Request : out IO_Request_T);
      -- Called by Server task, returns when the queue has
      -- some request(s).

   end Server_Queue;


A client task does:

   Response : aliased IO_Response_T;
   ...
   Server_Queue.Enqueue (
      Request => ( ... , Response => Response'Access),
      Success => ...);

   if Success then

      Response.Get (Result => ...);

   else
      -- Queue full.
      ... perhaps delay and retry?

   end if;

The server task does:

   Request : IO_Request_T;
   ...
   loop

      Server_Queue.Dequeue (Request => Request);

      .. perform the I/O according to the Request.

      Request.Response.Set (Result => ...);

   end loop;

A request in the queue can be cancelled by adding such an operation to
Server_Queue, for example:

   procedure Cancel (Response : in IO_Response_Ref);
   -- Scans the queue for a request with the given Response object,
   -- then deletes it from the queue and signals (using
   -- Response.Set, or some added Response.Cancelled) the
   -- client.

Did that answer your question?


-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .