From owner-sc22wg5@open-std.org Thu Jun 25 06:15:03 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 4AE4BC4596C; Thu, 25 Jun 2009 06:15:03 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 316 seconds by postgrey-1.18 at www2.open-std.org; Thu, 25 Jun 2009 06:15:02 CET DST Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by www2.open-std.org (Postfix) with SMTP id 58ADFC3BB09 for ; Thu, 25 Jun 2009 06:14:37 +0200 (CET DST) Received: from [209.191.108.97] by n14.bullet.mail.mud.yahoo.com with NNFMP; 25 Jun 2009 04:09:20 -0000 Received: from [68.142.201.247] by t4.bullet.mud.yahoo.com with NNFMP; 25 Jun 2009 04:09:20 -0000 Received: from [127.0.0.1] by omp408.mail.mud.yahoo.com with NNFMP; 25 Jun 2009 04:09:20 -0000 X-Yahoo-Newman-Id: 857941.33769.bm@omp408.mail.mud.yahoo.com Received: (qmail 19731 invoked from network); 25 Jun 2009 04:09:20 -0000 Received: from unknown (HELO ?192.168.1.32?) (van.snyder@76.208.178.203 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 25 Jun 2009 04:09:20 -0000 X-YMail-OSG: iEuJ3esVM1mEvOLKhdC.OVkVvvGQdIUmSmwwNKvHqQPjNNNMKi4QRSBxmBt_ZdB49sylLlQQGhJteN1oiLAJYgZ9hSmCEw2TPKqkoAy2g0hkYjz_1GeBtVqFDN_muGtq3DtxnxL9.gwUnZhci93FG3GrZ5hNr.D7QGIZtDbVmTIX54qs0q9Mv0Br3a6vplvuuNpBmBLbcuT4vmqMtrgJng4qwGxxD0L.nQS89eqdg4L.9bdidJsVZKCIBqmZWevtqSCtx_z9yhOHZanr X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A42F628.4030200@jpl.nasa.gov> Date: Wed, 24 Jun 2009 20:59:36 -0700 From: Van Snyder Reply-To: van.snyder@jpl.nasa.gov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: WG5 Subject: Re: (j3.2006) (SC22WG5.4027) [ukfortran] LOCK/UNLOCK question 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> <20090623084602.88A3EC178E5@www2.open-std.org> <20090624020300.8EE77C178E5@www2.open-std.org> <20090625033421.31AAEC3BB09@www2.open-std.org> In-Reply-To: <20090625033421.31AAEC3BB09@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk Malcolm Cohen wrote: > I might not agree with Van that LOCKs are too low-level to be > effectively usable.... It depends upon the definition of "effectively." JPL + Univac got Exec to run for days on a 4-processor 1108 without crashing. The machine typically ran with 50 time-sharing jobs, 10 batch jobs, and an occasional real-time job -- with 262144 36-bit words of core and 11 core loads of 4ms swap drums. This is longer than Windows does on a single processor with a far simpler load. But all too frequently we found a bug having to do with synchronization (usually a deadlock) or we never found it (not revealed on a core dump, and not reproducible). When we started paying more attention to Hoare and Per Brinch-Hansen, and trying to emulate their ideas in assembler with test-and-set, things got better. Test-and-set worked, but if you looked at the labor cost of making it work, and reliability that was probably less than might have been achieved with more structured tools, you might argue against "effectively."