From owner-sc22wg5@open-std.org Tue Jun 23 00:12:47 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 9B962C178E7; Tue, 23 Jun 2009 00:12:47 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by www2.open-std.org (Postfix) with ESMTP id 6DB78C178E5 for ; Tue, 23 Jun 2009 00:12:22 +0200 (CET DST) Received: from mprox1.jpl.nasa.gov (mprox1.jpl.nasa.gov [137.78.160.140]) by mail.jpl.nasa.gov (Switch-3.3.3mp/Switch-3.3.2mp) with ESMTP id n5MMC4HI011984 for ; Mon, 22 Jun 2009 22:12:20 GMT Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) (authenticated bits=0) by mprox1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id n5MMC2wE003875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 22 Jun 2009 15:12:03 -0700 Subject: Re: (j3.2006) LOCK/UNLOCK question From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 In-Reply-To: <4A3FF921.9070703@llnl.gov> 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> Content-Type: text/plain Organization: Yes Date: Mon, 22 Jun 2009 15:12:02 -0700 Message-Id: <1245708722.5080.854.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.3) Content-Transfer-Encoding: 7bit X-Source-IP: math.jpl.nasa.gov [137.79.7.57] X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Mon, 2009-06-22 at 14:35 -0700, Aleksandar Donev wrote: > Bill Long wrote: > > > If I recall, CRITICAL(lock) failed before since the effect can be > > simulated easily with already available constructs (block; lock() ... > > unlock(); end block) > Of course it can trivially be simulated with lock/unlock...the point is > not to achieve its effects, but to do it safely. We can achieve if with > goto but chose to go beyond that... > > > (probably most important) at some > > point the door has to close on new features for f08. > That one will not hold in court---the discussion in question happened > after it was decided to add locks and the issue was how to add it, not > whether to. The decision was to choose between: > 1) Only lock/unlock > 2) Only a paired construct (say critical(lock)) > 3) Both > Of course, 1 subsumes the others. >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. 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. 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. > Best, > Aleks > _______________________________________________ > J3 mailing list > J3@j3-fortran.org > http://j3-fortran.org/mailman/listinfo/j3