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,16594902ce57591b
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!postnews.google.com!h54g2000cwb.googlegroups.com!not-for-mail
From: "Matthew Heaney" <mheaney@on2.com>
Newsgroups: comp.lang.ada
Subject: Re: Multitasking and containers
Date: 28 Nov 2006 09:12:27 -0800
Organization: http://groups.google.com
Message-ID: <1164730840.554295.78960@h54g2000cwb.googlegroups.com>
References: <ek6bqd$prc$1@cernne03.cern.ch>
   <b62ajtddi0xt.5azckp3k6y3u.dlg@40tude.net>
   <ek6hsv$t1o$1@cernne03.cern.ch>
   <143yx0dos45nx.159wpxvfevtt8.dlg@40tude.net>
   <u8xi1hwk5.fsf@earthlink.net>
   <bFtah.295754$1i1.172141@attbi_s72>
   <1164623427.5986.11.camel@localhost>
   <YiGah.160827$aJ.83689@attbi_s21>
   <1164656708.657952.123430@j72g2000cwa.googlegroups.com>
   <pan.2006.11.28.01.45.08.406000@linuxchip.demon.co.uk.uk.uk>
   <uvel0qpmi.fsf@earthlink.net>
   <zq2w04z5om85.1adxu3bs3a773$.dlg@40tude.net>
NNTP-Posting-Host: 66.162.65.129
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Trace: posting.google.com 1164733952 12892 127.0.0.1 (28 Nov 2006 17:12:32
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 28 Nov 2006 17:12:32 +0000 (UTC)
In-Reply-To: <zq2w04z5om85.1adxu3bs3a773$.dlg@40tude.net>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.8.0.8) Gecko/20061025 Firefox/1.5.0.8,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: h54g2000cwb.googlegroups.com; posting-host=66.162.65.129;
   posting-account=Zl1UPAwAAADEsUSm1PMMiDjihtBlZUi_
Xref: g2news2.google.com comp.lang.ada:7728
Date: 2006-11-28T09:12:27-08:00
List-Id: <comp.lang.ada>


Dmitry A. Kazakov wrote:
> 2. Using a protected object's procedure/entry would kill concurrency by
> serialization of the action to undertake.

There is a difference between "synchronizing access to a shared
resource" and "waiting for a resource to become available".

Calling a protected function or procedure is an example of the former.
Calling a protected procedure would hardly "kill concurrency".  In a
monitor there is only synchronization.  (I think it's the case that the
task stays in a running state.)

Calling a protected entry whose barrier condition is false is an
example of the latter.  If the barrier condition were false this would
mean the task waits (it transitions to a blocked state).  I would be
loathe to say that that would "kill" concurrency since in typical
designs that's exactly what the task is supposed to do.