Re: Ada Protected Object Tutorial #1

[Karel Th�nissen <thoenissen@hello.nl>]

Laurent Guerby wrote:
> Karel Th�nissen <thoenissen@hello.nl> writes:

> > [...] He noticed that protected types are great if the caller
> > needs a single service from the protected type, but they are not that
> > great if you need more than one service from the same protected type.
> > Not only does the protected type solution require locking and unlocking
> > for every single service invocation, instead of one pair for the whole
> > deal, it also cannot avoid the situation that other tasks are serviced
> > in between two calls.
> 
> This claim is wrong, when you're inside a protected procedure, calls
> to other protected procedure on the same object are done
> without locking of course.

You object to a claim that I never made. The difference between the
problem I presented and your observation is that in my problem
description services on the protected instance are strung together by,
and on behalf of, the client code (=caller), whereas your observation is
about stringing together service invocations inside the supplier code.
Totally different piece of cake. However, it provides the solution if
the designer of the protected class can predict all the series of
service invocations that clients are going to make and has freedom to
change the code of the protected class.

> > I am wondering whether there is a clean solution to the problem that Mr
> > Kylheku presented: how can we combine several protected type services
> > into one transaction-like construct without requiring clairvoyance or
> > retrofitting.
> 
> Retrofitting is easy and seems to be the cleaner solution to me
> (that's where I would put the stuff by default).
> 
> protected P is
>    procedure S1;
>    procedure S2;
>    procedure Retrofitted_S1_S2;
> end P;
> 
> package body P is
>   ...
>   procedure Retrofitted_S1_S2 is
>   begin
>      S1; -- no locking happens
>      S2;
>   end Retrofitted_S1_S2;
> 
> end P;

Yes, this works, if you have the source code... And even if you have the
source code, quality assurance policies can inhibit your opening it.
However, I agree that it is easy if you are free to open the code.
 
> > Of course we can always go back and change the code in the
> > protected type and offer the combined invocation of the multiplicity of
> > services as a single integrated service, but this option requires
> > recoding, recompilation and re-verification.

This is the solution that you showed.
 
> You can avoid a bit of it with a "dynamic" clairvoyant solution: you
> define a data structure describing the individual services to be called,
> and have a protected procedure taking the data structure and calling
> whatever it needs according to the parameter. I assume it would do
> most of the job here. You can even use objects and dispatching
> for the data structure ;-).

Well, this is the best I came up with. This is some sort of interpreter!

> The general solution and to have a general transaction type, and to
> manage locks according to what's going on just like a database
> transaction manager would do, it requires lots of code and thinking
> (and I don't think the language matters here if you're
> talking about implementing the scheme).
> 
> What the Ada protected object offer is a clean solution (exclusion
> trivially insured, no need for caller care on mutexes) for 99% of the
> problems, and the remaining 1% is hard in any language I know anyway
> ;-).

I agree completely, and I would not plea for the dismissal of this
feature in Ada.

> > Solutions that do not use protected types are also welcome, if they are
> > safe and clean. So bluntly providing the services without any
> > concurrency protection and counting for the caller's willingness to use
> > a semaphore is outside the competition.
> 
> Unless I'm mistaken, that was the solution Kal proposed (caller
> willingness).

-- 

Groeten, Karel Th�nissen

Hello Technologies develops high integrity software for complex systems