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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: kaz@ashi.footprints.net (Kaz Kylheku) Subject: Re: Ada Protected Object Tutorial #1 Date: 1999/12/18 Message-ID: #1/1 X-Deja-AN: 562411676 Cache-Post-Path: ashi.FootPrints.net!unknown@localhost Content-Transfer-Encoding: 8bit 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> Content-Type: text/plain; charset=iso-8859-1 X-Complaints-To: abuse@direct.ca X-Trace: brie.direct.ca 945546714 204.239.179.1 (Sat, 18 Dec 1999 11:51:54 PST) Organization: Psycho-Neurotic Institute for The Very, Very Nervous X-Cache: nntpcache 2.3.3b3 (see http://www.nntpcache.org/) Mime-Version: 1.0 User-Agent: slrn/0.9.5.7 (UNIX) NNTP-Posting-Date: Sat, 18 Dec 1999 11:51:54 PST Reply-To: kaz@ashi.footprints.net Newsgroups: comp.programming.threads,comp.lang.ada Date: 1999-12-18T00:00:00+00:00 List-Id: On 17 Dec 1999 20:29:25 +0100, Laurent Guerby wrote: >Karel Th�nissen 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. This requires the procedures to be passed information about whether the object is locked by this thread or not. For example, a hidden parameterr. In C++-like pseudocode, this might look like: void object::frobnicate(bool already_locked = false) { if (!already_locked); lock(); // frobnicate if (!already_locked) unlock(); } That is overhead. 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. 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? The solution is probably to use recursive locks, which check the ID of the calling against an ownership ID stored in the lock. Recursive locks are slightly inefficient because they have to retrieve the ID of the current thread and compare it.