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/18 Message-ID: #1/1 X-Deja-AN: 562428867 Sender: bobduff@world.std.com (Robert A Duff) References: <839toq$pu$1@bgtnsc03.worldnet.att.net> <385AC716.7E65BD5C@averstar.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.programming.threads,comp.lang.ada Date: 1999-12-18T00:00:00+00:00 List-Id: kaz@ashi.footprints.net (Kaz Kylheku) writes: > This is practical. The condition variable wait might be done inside a > protected kernel. It would be impractical to have, say, a UNIX kernel > call back into application code to determine if some predicate is true. Please explain that in more detail. I'm not sure what you're getting at (efficiency, security, something else...). > >in even more unnecessary context switches, and/or bugs if the > >programmer neglects to build the evaluation of the boolean condition > >into a loop around the condition-variable "wait" operation. > > That loop around a condition variable wait is needed to resolve > spurious wakeups and race conditions. But the point is that with an Ada protected object, the loop is *not* necessary -- when the task wakes up after waiting for some barrier condition, it already owns the lock, and the condition is necessarily True, because no other task can sneak in and modify things. To be more precise, I should say that when an entry body is executed, its barrier condition is True -- this execution can be done by any task/thread, so it doesn't necessarily involve "waking up" as I said above. The point is that there's a piece of code depending on (say) the fact that "this queue is empty", and when that code runs, the system ensures that the queue is, in fact, empty -- that piece of code need not check. I understand why the loop is needed with Posix threads. > I believe that providing guarantees against this sort of occurence introduces > overhead; that is, the cure may be worse than the ailment, particularly > on multiprocessors. I'm not convinced. It seems to me that repeatedly checking the same condition is a cost, and the extra context switches (because one thread can't check barriers on behalf of other threads) is another cost, which Ada avoids. Am I missing something? - Bob