Re: Structure of the multitasking server

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

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);

They have *no choice* but to get the Finished flag. Well, they don't
have to react to it, but that seems to be very easy to spot in the
code review or during the data flow analysis.

> But the way you used protected
> object looks like a design noise. Technically you just replaced a
> rendezvous queue with a protected entry queue.

The fact that this replacement is so obvious is exactly the reason why
rendezvous as a language-level mechanism is nothing but a syntax
sugar.

> Instead of just server and
> workers

There is never "just server and workers". There are also jobs, queues
(even if implicit) and lifetime management (your "poison pills").

> 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. In other words,
main task and worker tasks need not wait for each other. This is not
obvious from the state transitions that I've shown, but can be
trivially implemented this way, without any massive modification of
the tasks themselves:

   protected type Channel_State is
      procedure Post (J : in Job_Type);
      procedure Finish;
      entry Get_Job (J : out Job_Type; Finished : out Boolean);
      function Can_Accept_New_Job return Boolean;
   private
      Job_Pending : Boolean := False;
      Should_Finish : Boolean := False;
      Job_To_Do : Job_Type;
   end Channel_State;

This code makes it easy to go to real queue with capacity > 1.

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). 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?

> 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.

> Due to complexity you have overlooked to make a channel idle again after a
> job is done.

Yes, I have overlooked it, but now I would not make it this way. I
would make it as describe above, to benefit from the increased
concurrency.

> And note,
> that the type Channel cannot call to the procedure Finish to set Shut_Down
> from its Finalize (if it were controlled).

That's right and this is why I asked here about different design
options.

> > 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. 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.

> > Above, the job space is not polluted with task lifetime management
> > concepts - these should be kept separate.
>
> You have polluted it with the procedure Finish, that has to be called
> outside the worker tasks.

I did not pollute the Job_Type (the matrix to be reversed), only the
Channel_State - which is there exactly for everything that is related
to managing the pipeline.

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

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