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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e6066104d6deadff X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!tiscali!newsfeed1.ip.tiscali.net!proxad.net!proxad.net!oleane.net!oleane!hunter.axlog.fr!nobody From: Jean-Pierre Rosen Newsgroups: comp.lang.ada Subject: Re: protected type interrupts Date: Fri, 25 Aug 2006 08:42:53 +0200 Organization: Adalog Message-ID: References: <1156430839.745932.279060@75g2000cwc.googlegroups.com> <1156436616.384632.192250@h48g2000cwc.googlegroups.com> <1156443355.219906.237190@h48g2000cwc.googlegroups.com> <1156446985.794916.61470@74g2000cwt.googlegroups.com> NNTP-Posting-Host: mailhost.axlog.fr Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: s1.news.oleane.net 1156489268 20165 195.25.228.57 (25 Aug 2006 07:01:08 GMT) X-Complaints-To: abuse@oleane.net NNTP-Posting-Date: Fri, 25 Aug 2006 07:01:08 +0000 (UTC) User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) In-Reply-To: <1156446985.794916.61470@74g2000cwt.googlegroups.com> Xref: g2news2.google.com comp.lang.ada:6369 Date: 2006-08-25T08:42:53+02:00 List-Id: REH a �crit : > I don't understand. How can a procedure within a protected object > modify data internal to the object in a thread-safe way without the > potentially blocking effect of enforcing mutual exclusion? If one task > is "using" the object, and another calls one of the object's > procedures, would the second task not be blocked until the first one > exits the object? > The goal of the "potentially blocking" rule is to prevent *unbounded* blocking. Short blockings, such as those require to provide mutual exclusion, are OK, because thay are bounded. Think of it this way: if it can be implemented on a multi-processor by a simple spin-lock, it is not potentially blocking. If it requires a queue, and being awaken depends on some non determinable condition, it is potentially blocking. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr