Re: Requeue

["Pat Rogers" <progers@classwide.com>]

"Anatoly Chernyshev" <rhezusfactor@yahoo.com> wrote in message
news:3CB0CD37.52B43088@yahoo.com...
> Hello, everybody,
>
> Actually, this question is for Ada gurus. I've read in two places
> (Coronado tutorial and J. English's "The craft of object oriented
> programming") that there is a reserved word "requeue" used in task
> programming, but this is so much advanced, tricky and deep technique
> that it isn't even worthy of mention. So, eventually I've got concerned
> about what is this word used for.
> Could someone post a simple yet practical example of using that
> statement in Ada programming?

Think of various tasks interacting in a client-server organization.  These tasks
synchronize and communicate via the language's mechanisms to implement this
relationship, in which client tasks request a service of the server task.  For
example, imagine a server task that allocates discrete resources upon request.
These resources can be anything, but there is a finite number of them.  As such,
not all requests can be satisfied when received, for example because the
requested allocation is larger than the amount currently available.

One way to program this is to use a form of synchronization in which the client
is held pending when a request cannot be satisfied.  In this approach, the
server has determined that the request cannot be satisfied and simply suspends
the caller in the middle of the service request.  Eventually (presumably) some
other event will occur, such that the pending request can now be satisfied, and
the service resumes for the original caller.  The primary characteristic is that
the server suspends the service execution on behalf of the client until the
request can be satisfied.  ("Condition variables" are a way of implementing this
approach. This can be messy but it works.)

Ada uses "avoidance synchronization", which means that the service requested is
not supposed to start before the request can be fulfilled.  That's a problem for
Ada's mechanisms because they use the parameters of the synchronization
mechanism to communicate the requested allocation -- but there is no way to read
the parameters until the mechanism executes, so it is too late to stop if the
request cannot be fulfilled.  (The guards on select statements, for example,
cannot refer to the formal parameters of accept statements.)  In Ada 83 this led
to a two-rendezvous approach -- one to get the request via the parameters, and a
second to actually satisfy the request when the conditions allow.  That's both
inefficient and open to issues of abort: what if the second call never comes in?

So, enter the requeue statement for Ada 95.  You can think of a requeue as being
similar to what happens when you call a large corporation.  The first person to
answer is a receptionist -- they have no idea how to handle your request, but
they can send you to the person who does, so they forward your call to the
proper person and then hang up.  The receptionist is done with you, and can go
on to answer the next incoming call.  But from your point of view, you've made
one call and are now waiting for the other person to answer your (forwarded)
call.  You've been requeued.

There are other details, such as being able to say whether or not abort is
deferred, but that is the gist of it.

I recommend this book for concurrent programming with Ada:
A. Burns and A. J. Wellings, Concurrency In Ada, Second ed: Cambridge University
Press, 1998.

It talks about this issue -- and any other aspect of concurrency in Ada -- in
lucid detail.  You can find examples there too.

Hope that helps,

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance