Re: Combining entry_call, accept_statment and terminate_statment

[Lutz Donnerhacke <lutz@iks-jena.de>]

* Randy Brukardt wrote:
> "Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
>> Unfortunly this is not allowed. Either accept and terminate or an
>> entry_call and a delay can be combinded. I wonder how to solve such as
>> deadlock. It should be a common idiom, but I had no luck in choosing
>> searching keywords.
>
> I can't tell you how to work around it, but I can tell you why it's not
> allowed - the implementation would be very slow.

IBTD. accept_statements and entry_call_statements as well as the
terminate_statement deal with queuing (wait queues). AFAIK the linux kernel
does implement all such "select" constructs by such wait queues and does not
have much trouble with it.

Of course accept and terminate queues are the other way around than entry
calls.

> During the Ada 9X process, there was a proposal for a multi-way entry
> call. (A more limited version of what you're asking for here.) The three
> User-Implementer teams were asked to analyze the implementation effort.
> (The reports are somewhere in the AdaIC archives, if you're interested.)
> All three teams decided that the run-time cost of the feature would be
> high (it would be close to polling). Since the real-time users that were
> requesting the feature need high performance, it was eventually dropped
> as impractical.

I do see the problem now: entry_barriers on entry_calls to protected types
or guarded task accepts are evaluated by the calling task. Therefore wait
queues are not possible. Polling is required.

This explains an other problem, I came across:

>     loop
>          select
>              accept Quit;
>              exit;
>          else null;
>          end select;
>          select
>              PO.Get_New_Operation (...);
>              Do_Operation (...);
>          or
>              delay 0.06;
>          end select;
>     end loop;

That's exactly my current implementation. But I increased the delay and
noticed, that the entry_barrier of the delayed entry_call is evaluated only
once on startup of the timed entry call. If the barrier becomes true while
the delay is running, the delay is not aborted.

A reason for this strange behavior might be a call to a protected function
in the entry_barrier itself.

> But I'd say that you probably have a design problem if you have a task that
> is both calling and accepting at the same time. That's pretty weird (unless
> the accepts are purely for task control, as above). It's preferable that
> each task be either a server (accepting entries) or a client (calling
> entries), but not both. Analysis is complicated if you have both.

I have a buffer, filled by a single task an read by an unknown number of
tasks. It's a stream multiplier implemented using a ringbuffer structure.

The writer task fills a proteced type (ringbuffer) using an protected
procedure, while the reader tasks call the protected procedure to get there
data.

In order to prevent polling, I implemented a second protected type
(constraint with an anonymous access to the ringbuffer) to encapsulate the
reader position variable and use it for an entry barrier on this second type.

If I had to stick to polling anyway, I can drop the second proteced type and
poll the protected ringbuffer directly.