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,a6fa29aa44e074d8 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Can a protected action tie up the calling task? Date: 1997/10/28 Message-ID: #1/1 X-Deja-AN: 285591135 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <6331fk$nm0$1@prime.imagin.net> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1997-10-28T00:00:00+00:00 List-Id: Samuel Mize (smize@news.imagin.net) wrote: : I need to verify a point on how protected actions work. Please email : me, as my news feed provides *very* variable delays. : My understanding is that, after an entry or procedure completes, the : queues for that object are serviced as far as possible before the : protected action completes. This is done by any convenient thread of : control (ARM 9.5.3(22)). This permission ALLOWS but does not REQUIRE : that the task calling the entry or procedure be released before the : protected action completes. The task may continue before the overall protected *action* completes, but certainly not before its own protected *operation* completes. A protected *action* is a sequence of protected operations all done under a single locking of the protected object. As soon as the protected operation associated with a given caller is complete, that caller may continue (unless of course the protected operation ends with a requeue). : Thus, in the following example, if another task has already called : Complete before task T1 calls Prepare: : - T1's thread of control can execute Complete; : - this COULD keep T1 suspended until Complete terminates. If T1's thread of control is executing Complete, then that thread is certainly not suspended. If T1's thread of control is *not* executing Complete, then there would be no reason why it would be suspended any longer than absolutely necessary (and I wouldn't waste any energy in trying to account for that possibility -- that is like worrying that computing 2+3 might take 2 hours). : Example: : protected Monitor is : entry Prepare (D: in Data); : entry Complete; : private : Ready_To_Complete: boolean := false; : end Monitor; : protected body Monitor is : entry Prepare (D: in Data) : when not Ready_To_Complete is : ... : entry Complete : when Ready_To_Complete is : ... : end Monitor; It is a little hard to know how Prepare and Complete are related since you don't show what they do to the "Ready_To_Complete" flag, but I will presume that Prepare sets it True, and Complete sets it back to False. : So to ENSURE that T1 can continue processing IMMEDIATELY on completion : of Prepare, we must ensure that Complete is not called before Prepare. I can't quite imagine why you care so much. Even if T1 *can* continue processing immediately, there is no reason why it will if its priority is lower. And remember that when a task holds a protected object lock, it inherits the ceiling priority of the protected object, so whichever task that executes Complete will inherit a priority that is definitely not lower than T1's priority. : A third entry is probably the simplest way to do this (task T2 calls : Wait_For_Preparation, then Complete). : protected Monitor is : entry Prepare (D: in Data); : entry Wait_For_Preparation; : procedure Complete; : private : Ready_To_Complete: boolean := false; : end Monitor; : protected body Monitor is : entry Prepare (D: in Data) : when not Ready_To_Complete is : ... : entry Wait_For_Preparation : when Ready_To_Complete is : ... : procedure Complete is : ... : end Monitor; : Is this correct? Have I missed something? The only thing missing is the background for the problem. What is it that Complete is doing that you want to be sure that T1 doesn't execute or wait for? Given inheritance of ceiling priority, it is a little hard to imagine how you could ever guarantee that T1 will continue first. : Thanks, : Sam Mize : -- : Samuel Mize -- smize@imagin.net -- Team Ada : (personal net account) -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA