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.

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

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

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

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

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

--LG