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,904e84d5dc020db1 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.106.73 with SMTP id gs9mr4456189wib.2.1361288832564; Tue, 19 Feb 2013 07:47:12 -0800 (PST) Path: g1ni20557wig.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.130.MISMATCH!xlned.com!feeder1.xlned.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.thorslund.org!news.jacob-sparre.dk!hugin.jacob-sparre.dk!nuzba.szn.dk!pnx.dk!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Question about concurrent access to array Date: Thu, 14 Feb 2013 23:41:07 +0200 Organization: Tidorum Ltd Message-ID: References: <947b0951-54e4-4a4d-bd26-760eb66390c3@googlegroups.com> Mime-Version: 1.0 X-Trace: individual.net k3ZtUWPyLZwIXjxxxqX9qgi89IjUwXj2xvBSs3mejiFMFuAVwjul4VdxxJWzGUHgdX Cancel-Lock: sha1:fqJTsTBHtXhKzXt0YuAfBAC2BWE= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 In-Reply-To: <947b0951-54e4-4a4d-bd26-760eb66390c3@googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2013-02-14T23:41:07+02:00 List-Id: On 13-02-14 22:39 , john@peppermind.com wrote: > I'd like like several tasks to share an unpacked array of a definite > discriminant record type. > > 1.) Is this possible? Yes. > 2.) Do I need any kind of synchronization if I can guarantee that > every task can only write and read to a different area (different > range of indices) in the array? See section 9.10 in the RM. The crucial part is this: "If two different objects, including nonoverlapping parts of the same object, are independently addressable, they can be manipulated concurrently by two different tasks without synchronization." For arrays, independent addressability can be specified with the aspect Independent_Components; see RM C.6, 6.8/3 and 6.9/3. This is new in Ada 2012. For earlier Ada versions, I don't know how to specify independent addressability of array components, but the Ada 2005 RM says in 9.10 that components are "normally" independently addressable, unless packing or Component_Size is specified. To be safe, I would make sure that the size of an array component is a multiple of the machine word size, perhaps by adding padding components. > Performance matters a lot in this case, which is why I would prefer > not to use a protected object or any other synchronization mechanism. > I can't imagine how a problem could occur if every task only accesses > his own part of the array, but perhaps there is still one? The computation could go wrong if the program for some reason uses memory accesses that are wider than one array component. For example, if the array components are 16 bits (unlikely in this case), and are aligned to 16 bits, a task that updates a given component might still use 32-bit accesses and could therefore interfere with concurrent updates of the adjacent component. I'm not sure if Ada standards before 2012 really forbade such interference. >From the performance point of view, if you intend to gain performance by running tasks in parallel on several cores, you should probably ensure (by padding) that an array component fits exactly in one or more cache lines. Alternatively, if a cache line holds more than one component, then the tasks updating those components should run in the same core if possible. The goal is to avoid "false sharing" that makes the cores compete for ownership of cache lines. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .