Re: Problem with task component

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

On Wed, 26 Sep 2012 13:49:09 +0200, Georg Bauhaus wrote:

> On 26.09.12 09:27, Dmitry A. Kazakov wrote:
> 
>> The weakness of this approach is that the client must know its master. It
>> is almost never the case. And it is tight coupling from the software design
>> POV.
> 
> But from the software design POV, the client, or its programmer,
> always does know that there is an operational dependence if the client
> should react to the master's life cycle. I don't understand why this
> should not be made explicit?

Because it is not same as to know who is the master. We have an example at
hand: a task component. Who is the master? It could be any because the
object can be instantiated anywhere.

> Also, arguably, a master knowing the clients will create tight coupling
> too, for it could otherwise be replaced with some other master.

Master must know them at least in order to be able to spawn these tasks. 

The point is that bidirectional exchange between two tasks, e.g. when both
calls entries of each other is a bad idea anyway you turn it. Good design
always tries to have only unidirectional relationships.

>    task body Server is
>       Master_Task : M_CRef;
>    begin
>       accept Master (Master_Task : M_CRef) do

Error-prone and does not work for task components anyway.

What you indeed could do is to add a task attribute T'Master or equivalent
to get the ID of the master and then to use it as:

   Is_Callable (T'Master); -- See Ada.Task.Identification

I don't see how this is cleaner than more explicit constructs for querying
if the task is wished to terminate.

Anyway the problem is not much task termination but construction of
class-wide objects. You want to communicate with a task component that
dispatches on the container's tag upon container initialization and
finalization. That is the core problem. (BTW, note bidirectional
relationship: container -> task (component), task -> container (access
discriminant), which expectedly causes troubles).

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