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,e0e1d3b3f7c994b8 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.sun.com!news.sun.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 15 Apr 2008 07:05:30 -0500 Newsgroups: comp.lang.ada Subject: Re: Robert Dewar's great article about the Strengths of Ada over other langauges in multiprocessing! References: <13t4b2kkjem20f3@corp.supernews.com> <89af8399-94fb-42b3-909d-edf3c98d32e5@n75g2000hsh.googlegroups.com> <87bq56peg1.fsf@mid.deneb.enyo.de> <87bq516uri.fsf@mid.deneb.enyo.de> <87prtfzrtl.fsf@mid.deneb.enyo.de> <87wsnmg1ju.fsf@mid.deneb.enyo.de> From: Ole-Hjalmar Kristensen Organization: Sun Microsystems Date: 15 Apr 2008 14:05:27 +0200 Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cache-Post-Path: news1nwk!unknown@astra06.norway.sun.com X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 192.18.43.225 X-Trace: sv3-YCKOjUQJNsHI6FOaGQev+2biTmsXln4aC0R9OFDScN5f0iBKQi+2sUWyRo8dgf8MDl/4kamqJlVfaZi!LsfrPfbF23bplhj84Fu+bT8pPnsqxfpSy9nn1at8ED6GSV8UqAo0NPrauyglbv6fB2gbON39icvQ X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.39 Xref: g2news1.google.com comp.lang.ada:20953 Date: 2008-04-15T14:05:27+02:00 List-Id: After reading your post about use of suspension objects, I looked in the RM to see what guarantees we have about the effect of sharing variables between tasks synchronized with suspension objects. I completely agree that to work reliably on a multiprocessor the suspension operations *has* to impose a memory barrier, but I was unable to find any explicit statement about sharing variables synchronized with suspension objects. The sections I have reproduced below is the closest I could get. Since Suspend_Until_True is potentially blocking, it *could* be signaled (as defined in 9.10), but I find it strange that it is not mentioned explicitly. Also, the statement "can be used for two-stage suspend operations and as a simple building block for implementing higher-level queues", seems to indicate that the intent indeed is to be able to use suspension objects to synchronize access to shared variables. Comments, anyone? >From the AARM: 9.10 Shared Variables 9.a Reason: The underlying principle here is that for one action to ``signal'' a second, the second action has to follow a potentially blocking operation, whose blocking is dependent on the first action in some way. Protected procedures are not potentially blocking, so they can only be "signalers," they cannot be signaled. and D.10 Synchronous Task Control 1 [This clause describes a language-defined private semaphore (suspension object), which can be used for two-stage suspend operations and as a simple building block for implementing higher-level queues.] ... 9 The procedure Suspend_Until_True blocks the calling task until the state of the object S is true; at that point the task becomes ready and the state of the object becomes false. 10 {potentially blocking operation [Suspend_Until_True]} {blocking, potentially [Suspend_Until_True]} {Program_Error (raised by failure of run-time check)} Program_Error is raised upon calling Suspend_Until_True if another task is already waiting on that suspension object. Suspend_Until_ True is a potentially blocking operation (see 9.5.1). >>>>> "(b" == (see below) writes: (b> Following on my second post to the point, I was reminded of the package (b> Ada.Synchronous_Task_Control, which must also impose memory barriers is it (b> is to work reliably on a multiprocessor; so I tried that in my Simpson's (b> algorithm test as well. Here is the code: >> with Ada.Synchronous_Task_Control; >> package body Wait_Free_Atomicity is >> >> procedure Sync is >> use Ada.Synchronous_Task_Control; >> Sema : Suspension_Object; >> Bool : Boolean := Current_State(Sema); -- either this >> begin >> -- Set_True(Sema); -- or >> -- Suspend_Until_True(Sema); -- this >> end Sync; >> >> procedure Update (Atomic_Item : in out an_Atomic; Item : in an_Item) is >> Row : constant a_Bistate := not Atomic_Item.Last_Row_Inspected; >> Col : constant a_Bistate := not Atomic_Item.Last_Column_Updated(Row); >> begin >> Atomic_Item.Data_Slot_Matrix(Row, Col) := Item; >> Atomic_Item.Last_Column_Updated(Row) := Col; >> Atomic_Item.Last_Row_Updated := Row; >> Sync; >> end Update; >> >> procedure Inspect (Atomic_Item : in out an_Atomic; Item : out an_Item) is >> Row : constant a_Bistate := Atomic_Item.Last_Row_Updated; >> Col : a_Bistate; >> pragma Atomic (Col); >> begin >> Atomic_Item.Last_Row_Inspected := Row; >> Col := Atomic_Item.Last_Column_Updated(Row); >> Item := Atomic_Item.Data_Slot_Matrix(Row, Col); >> Sync; >> end Inspect; >> >> end Wait_Free_Atomicity; (b> It works nicely, and is an order of magnitude faster than a protected (b> object: (b> 20_000_000 updates (b> with Suspend_Until_True sync: (b> No consistency failures. (b> 7.30 real 14.14 user 0.04 sys (b> with Current_State sync: (b> No consistency failures. (b> 3.57 real 6.97 user 0.02 sys (b> -- (b> Bill Findlay (b> chez blueyonder.co.uk -- C++: The power, elegance and simplicity of a hand grenade.