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: ffc1e,fb45e48e8dddeabd X-Google-Attributes: gidffc1e,public X-Google-Thread: 103376,fb45e48e8dddeabd X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Ada Protected Object Tutorial #1 Date: 1999/12/17 Message-ID: #1/1 X-Deja-AN: 561752044 Sender: bobduff@world.std.com (Robert A Duff) References: <839toq$pu$1@bgtnsc03.worldnet.att.net> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.programming.threads,comp.lang.ada Date: 1999-12-17T00:00:00+00:00 List-Id: kaz@ashi.footprints.net (Kaz Kylheku) writes: > What if a protected procedure of an object calls another > protected procedure? Presumably this is allowed, which means that some > recursive lock has to be used for the implementation, or else the compiler has > to generate code that passes around secret ``already locked'' flags into > procedures. No, there's no such fancy run-time stuff in Ada 95's protected objects. The rules ensure that it is known at compile time whether a lock should be grabbed. (And there is, of course, some potential for deadlock.) > What if you want to block for something in the middle of the critical region? > I assume that you can call a protected entry from within a protected procedure. No, you can't. If you want to block in the middle, then you have to call the thing an "entry" and not a "procedure". One common thing to do is to have an entry with a True barrier, so it always goes right ahead, but then it can block by requeuing to a different entry (of the same protected object, or a different one); it will then block on a new barrier. Protected procedures, on the other had, can't block. - Bob