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: a07f3367d7,385c146dd3112519 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx01.iad01.newshosting.com!209.197.12.246.MISMATCH!nx02.iad01.newshosting.com!newshosting.com!198.186.194.249.MISMATCH!transit3.readnews.com!news-out.readnews.com!news-xxxfer.readnews.com!panix!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Private or public task ? Date: Tue, 09 Feb 2010 10:20:03 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <38a0a3f9-b4a0-48f3-98c9-63b03fe03aca@q4g2000yqm.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: pcls6.std.com 1265728789 20601 192.74.137.71 (9 Feb 2010 15:19:49 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 9 Feb 2010 15:19:49 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:Zrz8fqRHL0Bs1fNg0MtZVc8106M= Xref: g2news1.google.com comp.lang.ada:9042 Date: 2010-02-09T10:20:03-05:00 List-Id: "Hibou57 (Yannick Duch�ne)" writes: > Let temporarily suppose so. But remains another wolf in the wood : > what if the application is running in a multiprocessors environment > and its thread are not executed on the same CPU ? If one task on CPU#1 > was to enter a procedure of a protected object while a task on CPU#2 > is actually running a procedure on the same protected object, then, > the task running on CPU#1 must be delayed, and thus, the procedure is > blocking. > > Sure a procedure of a protected type or object should be short and > quick to execute, but it seems to still remains potentially blocking. You should read all the stuff in the Real Time annex about priorities and ceilings and policies and whatnot. No, protected procedures and functions are not potentially blocking. In your multiprocessor example, task#1 cannot procede into the protected procedure until task#2 lets go of it, but that's not blocking. No lower-or-equal priority task can preempt task#1. One possible implementation is that task#1 spins on the lock, which is OK because you made sure your protected procedure executes in a short bounded time. This all depends on using the right real-time policy. Other policies are possible -- and likely, when running on top of a desktop OS. Protected entries, on the other hand, are potentially blocking, because they put the task to sleep for an arbitrarily long time (until the barrier becomes True). - Bob