Re: Question about the need for requeue as described in Rationale

[bobduff@world.std.com (Robert A Duff)]

In article <31DAD51F.40F1@csehp3.mdc.com>,
James A. Squire <m193884@CSEHP3.MDC.COM> wrote:
>In the Ada95 Rationale, II.9 "Protected Types", it says the following:
>
>"Our final example introduces the ability to requeue a call on another
>entry. It sometimes happens that a service needs to be provided in two
>parts and that the calling task has to be suspended after the first part
>until conditions are such that the second part can be done. Two entry
>calls are then necessary but attempts to program this in Ada 83 usually
>run into difficulties; race conditions can arise in the interval between
>the calls and there is often unnecessary visibility of the internal
>protocol."
>
>It goes on to cite an example which does not represent work that needs
>to be provided in two parts, and concludes with this disclaimer:
>
>"The above example has been used for illustration only. The astute
>reader will have observed that the condition is not strictly needed
>inside Signal; without it the caller will simply always requeue and then
>immediately be processed if there are no waiting tasks. But the
>condition clarifies the description. Indeed, the very astute reader
>might care to note that we can actually program this example in Ada 95
>without using requeue at all. A more realistic classic example is the
>disk scheduler where a caller is requeued if the head is currently over
>the wrong track."
>
>I am trying to understand what problem Requeue is trying to solve and
>the above does not help me.

Right -- it's not intended to help you in that way.  This part of the
"Rationale" isn't really rationale at all -- it's a tutorial, and is
trying to explain how requeue works (as opposed to why it's in the
language).

You should instead look at section 9.2 and 9.2.1 in Part 2.  I believe
it answers your questions.  One thing you might want to do is to rewrite
the disk controller example of 9.2.1 without using requeue, but making
sure it's abort-safe and ATC-safe, and the server accepts additional
callers while waiting for interrupts (i.e. while one or more requests
are in the process of being serviced), and there are no race conditions,
etc.

>...  I can see from the example given how it
>would be difficult to do the same thing in Ada83, but as I was trying to
>describe the Ada83 problem that raised the need for this, I found I
>couldn't come up with any good way of describing the problem.
>
>"race conditions can arise in the interval between the calls" - like
>what, for example?  A race condition, AFAIK, is where two tasks are both
>updating the same data object but act as if they are oblivious to it.

A race condition is really any timing-related bug.  Suppose you had a
task that had two entries Do_Part_1 and Do_Part_2, which are really two
parts of the same thing.  It might be considered a race condition if one
task does:

    T.Do_Part_1(...);
    T.Do_Part_2(...);

And another task can sneak in and do something in between the above.
Assuming that causes some damage, of course.

>I'm having trouble seeing how that applies in the context in which this
>quote was used.
>
>"Indeed, the very astute reader might care to note that we can actually
>program this example in Ada 95 without using requeue at all." - Great!
>So why was it used if it wasn't needed?  For that matter, how can I do
>it in Ada 95 without requeue?

The solution is quite tricky, and is shown in 9.2.

>"A more realistic classic example is the disk scheduler where a caller
>is requeued if the head is currently over the wrong track." - Gee, then
>why didn't they?  I have a feeling I would understand the dilemma a lot
>better if they had.

They did.

>Can anybody help me understand what race conditions can't be avoided in
>Ada83 that pertain the situation where a service needs to be provided in
>two parts?  (Frankly, if they had said "deadlock" instead, I might have
>understood that a bit more)
>
>Thank you.

Hope this helps.

- Bob