From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,INVALID_MSGID,
	PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII
X-Google-Thread: ffc1e,fb45e48e8dddeabd
X-Google-Attributes: gidffc1e,public
X-Google-Thread: 103376,fb45e48e8dddeabd
X-Google-Attributes: gid103376,public
From: Laurent Guerby <guerby@acm.org>
Subject: Re: Ada Protected Object Tutorial #1
Date: 1999/12/17
Message-ID: <86aen9z7qi.fsf@ppp-111-13.villette.club-internet.fr>#1/1
X-Deja-AN: 562055643
References: <839toq$pu$1@bgtnsc03.worldnet.att.net>
 <slrn85h77n.68i.kaz@ashi.FootPrints.net> <3858E5B3.9AB004E9@bton.ac.uk>
 <385984BC.1FB1@hello.nl>
X-Trace: front6.grolier.fr 945458699 173 194.158.111.13 (17 Dec 1999 19:24:59
 GMT)
Organization: Club-Internet (France)
NNTP-Posting-Date: 17 Dec 1999 19:24:59 GMT
Newsgroups: comp.programming.threads,comp.lang.ada
Date: 1999-12-17T19:24:59+00:00
List-Id: <comp.lang.ada>

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