Re: Ada Protected Object Tutorial #1

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

John English wrote:
> 
> Kaz Kylheku wrote:
> > This approach to design is generally wasteful. It's more reasonable to have
> > public methods which always lock and unlock, and unprotected methods which
> > assume that an object is already locked. It's also useful for an object
> > to expose lock and unlock methods, and expose unprotected operations, so that
> > the user of the object can compose a sequence of operations into an indivisible
> > block.
> 
> Congratulations, you've just invented the semaphore... :-)

I noticed the smiley, but to be fair to the original poster this is not
quite true. 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 can make correctness difficult to prove.

Mr Kylheku did not claim any invention, he was just pointing out a
disadvantage of the protected type mechanism. BTW, even the protected
type uses a semaphore so his idea would not have been original and not
patentable (-8

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

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.

-- 

Groeten, Karel Th�nissen

Hello Technologies develops high integrity software for complex systems