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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news4.google.com!news2.volia.net!keepthis.news.telefonica.de!telefonica.de!news.belwue.de!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Multitasking and containers Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <143yx0dos45nx.159wpxvfevtt8.dlg@40tude.net> <1164623427.5986.11.camel@localhost> <1164656708.657952.123430@j72g2000cwa.googlegroups.com> <1164730840.554295.78960@h54g2000cwb.googlegroups.com> Date: Tue, 28 Nov 2006 19:21:42 +0100 Message-ID: NNTP-Posting-Date: 28 Nov 2006 19:21:36 CET NNTP-Posting-Host: b3c8383f.newsspool3.arcor-online.net X-Trace: DXC=UM>9n023dI?gP]QSEBQ^d4McF=Q^Z^V384Fo<]lROoR1gUcjd<3m<;2MUZ;RCm1@E:[6LHn;2LCV>[ On 28 Nov 2006 09:12:27 -0800, Matthew Heaney wrote: > 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.) Ah, you mean: in absence of preemptive scheduling. > 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. No difference if the above premise holds, i.e. no task switches as long as the barrier is closed. But, the above is true *only* for a single-CPU system. So for a truly parallel system it could become a problem. Dual-cores aren't that expensive in these days. Further, even on a single CPU, where protected functions and procedures are equivalent, the requirement "no task switches while lock held" might be unacceptable if you hold it for too long. Searching a container within a protected action ... well, one should be a quite strong believer for this. I wouldn't dismiss it completely, but I definitely don't like it. For hashes I would at least take one with an external hash function computed outside the protected action. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de