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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fb45e48e8dddeabd X-Google-Attributes: gid103376,public X-Google-Thread: ffc1e,fb45e48e8dddeabd X-Google-Attributes: gidffc1e,public From: Laurent Guerby Subject: Re: Ada Protected Object Tutorial #1 Date: 1999/12/18 Message-ID: <86u2lgvumy.fsf@ppp-116-44.villette.club-internet.fr>#1/1 X-Deja-AN: 562428866 References: <839toq$pu$1@bgtnsc03.worldnet.att.net> <3858E5B3.9AB004E9@bton.ac.uk> <385984BC.1FB1@hello.nl> <86aen9z7qi.fsf@ppp-111-13.villette.club-internet.fr> X-Trace: front3.grolier.fr 945550104 21988 194.158.116.44 (18 Dec 1999 20:48:24 GMT) Organization: Club-Internet (France) NNTP-Posting-Date: 18 Dec 1999 20:48:24 GMT Newsgroups: comp.programming.threads,comp.lang.ada Date: 1999-12-18T20:48:24+00:00 List-Id: kaz@ashi.footprints.net (Kaz Kylheku) writes: > >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. > > This requires the procedures to be passed information about whether > the object is locked by this thread or not. For example, a hidden > parameterr. No, the Ada compiler can statically make the difference between an internal and external call. There is no locking involved at all for internal calls. That is the fundamental point of protected procedures, they are lightweight and efficient, but you are of course restricted on what you do inside them. If you need to do more things, you use an entry, and then there are locks and all the stuff you mention. > Another thing that is possible is that the compiler might generate > two function images: one that assumes the lock and one that does > not. When a protected procedure calls another one for the same > object, the compiler will generate a call to the variant which does > not acquire the lock. That is exactly what GNAT does (and I assume other Ada compilers do the same). > These solution requires some measure of clairvoyance: what if the > protected procedure calls into another subsystem which then calls > back into a protected procedure on the same object? How do you pass > the ``already_locked'' knowledge across calls to foreign subsystems? There is no clairvoyance involved, it is just that the Ada language is designed to allow an efficient implementation of protected procedures. The language defines as a bounded error when potentially blocking operation is called from a protected procedure, or when jumping around brings you back to the original protected object. See RM 9.5.1 for details. --LG