Re: Structure of the multitasking server

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 22 Wrz, 10:12, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> >       entry Get_Job (J : out Job_Type; Finished : out Boolean);
>
> Which is a bad pattern because it propagates task termination requests to
> an entry point of some object (or another task) which usually have little
> or nothing to do with the task termination issue.

How is the special job any different in this aspect? It has exactly
the same properties, just implicitly.

> I don't like an extra output parameter, it is error-prone. Therefore I used
> a special value of Job_Type.

In what way is a special value less error-prone than a separate flag?

> There also exists a third variant with an
> exception propagation.

This assumes rendezvous.

> This all is a matter of taste, because the (poor) pattern is same: the
> knowledge about caller's termination is moved to the callee.

In the version with protected objects the entity that triggers
termination might be different from the one that invents job.
In your version these different responsibilities are mixed.

> > What about the following: in my version the main
> > task (the one that invents jobs) can give the job to the worker task
> > when it is still working on the previous one, so that the main task
> > need not be blocked and can go on inventing more jobs.
>
> This is a very different task. You didn't say that you wanted to queue
> jobs.

And this is exactly the advantage of separate protected object - I
didn't have to state all aspects and I was free to invent the part
with queues later on. This flexibility is not provided by rendezvous,
which would then require massive rework.

> Anyway there is little sense to queue jobs to busy workers.

There is a lot of sense. In particular, in my version the task that
invents jobs is never blocked on interactions with workers. This is a
big advantage, because such a blocking would disturb its own
interactions with the environment and reduce its responsiveness.
In your version with rendezvous the task that invents jobs has to
block and during that time it cannot react to the events that drive it
(keyboard input, network transmission, etc.).

> A better
> design would be:
>
>    Server --> Scheduler <-- Worker
>
> The jobs are queued to the scheduler. Workers ask it for jobs to do.
> Scheduler could be a protected object or a task.

Isn't it what I have proposed?

> You *have* to wait, or else you must drop jobs.

Which might be a perfectly legal handling policy.
Or the main task could promptly reject requests so that clients can
back off or try to find another, less busy server.

> Anyway it is no problem in my design. Use selective accept (RM 9.7.1):
>
>    select
>       when not Empty (Queue)  => accept Get (Work : out Job) do
>          ... -- A worker is here to get a job from the FIFO
>       end Get;
>    or when not Full (Queue) => accept Put (Work : out Job) do
>          ... -- A new job is to queue into the FIFO
>       end Put;
>    or when Full (Queue) => delay Time_Out;
>       ... -- Go to hell with your jobs!
>    end select;

But this looks like part of a separate task and the third branch still
causes someone else to block.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada