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!news4.google.com!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread4.news.pas.earthlink.net.POSTED!14bb18d8!not-for-mail Sender: Matthew Heaney@MHEANEYIBMT43 Newsgroups: comp.lang.ada Subject: Re: Multitasking and containers References: From: Matthew Heaney Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Nov 2006 12:02:31 GMT NNTP-Posting-Host: 4.238.121.243 X-Complaints-To: abuse@earthlink.net X-Trace: newsread4.news.pas.earthlink.net 1164369751 4.238.121.243 (Fri, 24 Nov 2006 04:02:31 PST) NNTP-Posting-Date: Fri, 24 Nov 2006 04:02:31 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: g2news2.google.com comp.lang.ada:7686 Date: 2006-11-24T12:02:31+00:00 List-Id: Maciej Sobczak writes: > Paragraph 3 in Annex A says that it's OK to call any standard subprogram from > concurrent tasks as long as the parameters do not overlap. John Barnes > ("Progamming in Ada 2005") suggests that in order to (for example) read from > the same container, the operations need to be protected "by using the normal > techniques such as protected objects". Right. > But reading from the protected object is not mutually exclusive (many readers > are allowed) - so where's the gain? What's the difference between concurrent > reads of, say, a Vector via protected object vs. direct access? The reason is a conflict between safety and flexibility, a conflict that was resolved in favor of safety. The container must set some internal state to indicate that Query_Element is executing, in order to prevent you from doing things inside Query_Element that would potentially destroy the element (such as Delete'ing it). Even though Query_Element is technically a read-only operation, that's true only in the logical sense, not the physical sense. It doesn't look like Query_Element modifies the container, but it really does modify the container, to set some state that indicates a Query_Element is in progress. Yes, it would seem as if it should be possible for multiple tasks to all be reading from the container simultaneously. But it's impossible to do that and also satisfy the requirement that the container detect potentially harmful manipulation of the container while Query_Element is executing. So multiple tasks -- even tasks only calling (logically) read-only operations -- cannot simultaneously call container operations without also synchronizing the tasks, by wrapping the container inside a protected object, using a critical section, etc. -Matt