Re: STM32F4 Discovery, communication and libraries

[Brad Moore <brad.moore@shaw.ca>]

On 2014-08-31 10:15 AM, Dmitry A. Kazakov wrote:
> 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.
>

No, I mean one request queued in one queue, where the processing of that 
request involves calling registered callbacks in some callback list for 
other clients that are interested in hearing about the servicing of that 
request.