Re: Structure of the multitasking server

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 21 Sep 2008 14:27:13 -0700 (PDT), Maciej Sobczak wrote:

> On 21 Wrz, 21:24, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Sun, 21 Sep 2008 10:30:37 -0700 (PDT), Maciej Sobczak wrote:
> 
>>> No problem with that. With separate protected object (instead of
>>> rendezvous) it is enough to do this:
>>
>> Of course there is a problem because conditional and timed entry calls may
>> not contain a "terminate" alternative.
> 
> They don't have to. Again:
> 
>       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.

I don't like an extra output parameter, it is error-prone. Therefore I used
a special value of Job_Type. There also exists a third variant with an
exception propagation. (Note that an exception from an rendezvous
propagates on both sides)

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

>> you have server, workers, channels and management stuff.
> 
> Because it *is* there anyway.
> Trying to hide it? 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. Anyway there is little sense to queue jobs to busy workers. 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. Depending on the nature of
the jobs source, Server and Scheduler can be merged (see below).

> This is not so easy in your version with rendezvous, where the main
> task has to always *wait* until some of the worker will be willing to
> pick up the new job (that's the whole point of rendezvous).

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

Queueing jobs postpones the problem but that by no means solves it. If
workers are incapable to process the jobs, the server must wait for them.
The only reason why job queueing might become necessary is a need to make
the server asynchronously working. (Remember our recent discussion?
Buffering = wasting resources, unless decouples.)

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;

> Obviously,
> there are fewer opportunities for concurrency in your version.
> What would you have to do to have this increased concurrency in your
> version? Would you still claim it to be simpler?

Certainly yes. If I wished to collect jobs at the server I would just add a
FIFO of jobs there, like above.

>> The second problem which adds complexity is server to worker 1-n
>> communication. Should be n-1 worker to server, simpler (classic
>> client-server) and more efficient too.
> 
> I'd prefer producer + queue + N consumers. Still a protected object in
> the middle.

What you describe is my design (the queue is held by the producer).Your
design was:

   producer + N queues of size 1 + N consumers

It is not a problem to me to split the producer into server and scheduler.
I object mainly to moving *parts* of the scheduler (as protected objects)
into the consumers. It makes no sense.

>>> There is no need to introduce any special type of job ("poison pill").
>>
>> Job carries the parameters of a worker. You used it too, under the name
>> Job_Type.
> 
> But in my case the Job_Type need not contain the special "poison"
> value.

See above. You can use either of three variants with my design. This is an
independent issue.

> Let's say that the Job_Type is a matrix that has to be
> reversed. There is no place for the "poison" value in the matrix
> itself, so the Job_Type would need to be extended (a record with
> additional flag, perhaps?) to cover it, but then the pollution of the
> type would be very explicit.

If it were large objects, I would not use copying anyway. So it would
become a referential object moving around. These would have enough place
for "poison". Further, don't forget that Ada has variant records.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de