From owner-sc22wg5@open-std.org Tue Jun 23 10:46:02 2009 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 3DCEDC178E7; Tue, 23 Jun 2009 10:46:02 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by www2.open-std.org (Postfix) with ESMTP id 77830C178E5 for ; Tue, 23 Jun 2009 10:45:34 +0200 (CET DST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40872) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:nmm1) id 1MJ1dE-0002f2-3z (Exim 4.70) for sc22wg5@open-std.org (return-path ); Tue, 23 Jun 2009 09:45:32 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1MJ1dE-0003dx-78 (Exim 4.67) for sc22wg5@open-std.org (return-path ); Tue, 23 Jun 2009 09:45:32 +0100 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 23 Jun 2009 09:45:32 +0100 Date: 23 Jun 2009 09:45:32 +0100 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4020) (j3.2006) LOCK/UNLOCK question Message-ID: In-Reply-To: <20090622221248.1FEF4C178E5@www2.open-std.org> References: <4A38A3BB.9090208@nag-j.co.jp><4A38B917.8080202@llnl.gov> <4A391682.8060208@cray.com> <061720091627.18164.4A39196C000C05A4000046F422230703729B0A02D29B9B0EBF02019C050C079D0B020A08D2050C070B@att.net> <4A3930E3.8070505@cray.com> <061720091851.25112.4A393B4100015BA20000621822228869349B0A02D29B9B0EBF02019C050C079D0B020A08D2050C070B@att.net> <4A397E50.9010406@nag-j.co.jp> <4A3F9897.8010103@llnl.gov> <4A3FA25D.1050507@cray.com> <4A3FF921.9070703@llnl.gov> <20090622221248.1FEF4C178E5@www2.open-std.org> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Jun 22 2009, Van Snyder wrote: > >From 69-79 I did a lot of real-time and OS development for multithread >multiprocessor applications on Univac 1100, in assembler. The only >mutex available was the test-and-set instruction. It was very difficult >to get it right. I decided early on that the biggest threat to >correctness was due to the necessarily unstructured nature of the use of >test-and-set. I was very happy to get back to applied and computational >mathematics. In my experience, the unstructured nature of aliasing control is a more important factor, but I agree that getting unstructured parallelism controls right is error-prone in the hands of experts and completely hopeless in the hands of non-experts. Hoare decided that, too, and went overboard in the other direction (as might be expected) with BSP. >This was at the time when structured programming, as an alternative to >GO TO, was still controversial. I think that controversy has largely >been resolved in favor of structured programming. I see LOCK/UNLOCK as >essentially equivalent to GO TO, so I don't understand why we decided to >regress 30 years. Regrettably, that is out of date. Yes, structured programming 'won' in the 1970s - but then came C, and then POSIX - and most modern languages follow C and parallelism models follow POSIX. There are a few significant exceptions, like Ada, but not many. I don't regard PGAs as being very different from POSIX, as far as error-proneness goes - their real difference is in the way that they require the programmer to think about locality. Leaving that on one side, the big problem is that there are reasonable parallel logics that are not easy to shoehorn into a hierarchical system, of the sort that is imposed by the language syntax. There may be something more flexible that is still 'structured', but most of the attempts I have seen are very nasty and wouldn't fit into Fortran. >I didn't like LOCK/UNLOCK when it was proposed because or that >experience, and because I haven't seen any convincing arguments that you >can't structure a program so that you get what you need with a more >structured approach, such as monitors or critical sections. You probably can, but it may involve completely restructuring the code. That, in turn, may obfuscate the purpose of modules by exposing the structure of the implementation rather than the science. I am thinking of a hierarchy of data structures, where the parallelism is mapped to different levels at different places in the code. I agree that it would be better to separate atomics, SYNC MEMORY and locks out into a separate module, for 'library implementors' only, and keep the basic features at a higher and more robust level. We have already mentioned a locking construct - monitors would be trickier to add but shouldn't be infeasible. However, when that was discussed, nobody could see how to do it. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679