From owner-sc22wg5@open-std.org  Wed Jun 24 10:13:21 2009
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom7
Delivered-To: sc22wg5-dom7@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 692F0C178E7; Wed, 24 Jun 2009 10:13:21 +0200 (CET DST)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135])
	by www2.open-std.org (Postfix) with ESMTP id 6C474C178E5
	for <sc22wg5@open-std.org>; Wed, 24 Jun 2009 10:12:56 +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]:52415)
	by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25)
	with esmtpa (EXTERNAL:nmm1) id 1MJNbD-0003m6-J5 (Exim 4.70) for sc22wg5@open-std.org
	(return-path <nmm1@hermes.cam.ac.uk>); Wed, 24 Jun 2009 09:12:55 +0100
Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk)
	with local (PRAYER:nmm1) id 1MJNbD-0002Fx-TG (Exim 4.67) for sc22wg5@open-std.org
	(return-path <nmm1@hermes.cam.ac.uk>); Wed, 24 Jun 2009 09:12:55 +0100
Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk
	with HTTP (Prayer-1.3.1); 24 Jun 2009 09:12:55 +0100
Date: 24 Jun 2009 09:12:55 +0100
From: "N.M. Maclaren" <nmm1@cam.ac.uk>
To: sc22wg5 <sc22wg5@open-std.org>
Subject: Re: [ukfortran] (SC22WG5.4025) (j3.2006)   LOCK/UNLOCK question
Message-ID: <Prayer.1.3.1.0906240912550.1664@hermes-2.csi.cam.ac.uk>
In-Reply-To: <20090624020300.8EE77C178E5@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>
 <Prayer.1.3.1.0906221229130.26720@hermes-2.csi.cam.ac.uk>
 <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>
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 24 2009, Bill Long wrote:
>> 
>> 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.
>
>I dislike this sort of imperious condescension. While it might be the 
>case that some hapless beginners will get things wrong, there are a lot 
>of very good programmers out there who directly benefit from access to 
>powerful features. They should not have their hands tied. Rather, we 
>should cater to their needs.

Needs?  Or wants?

You have rather jumped to the conclusion that I am claiming that I can
get unstructured parallelism controls right - well, for the record, I
know that I can't.  Over many years, I have learnt that I can write code
that mostly works, but I lack the intellectual ability to be sure that my
logic will behave correctly in all cases.  And it usually doesn't ....

However, I do have the experience to realise that, when I hit trouble, the
solution is to back off, and put draconian self-imposed constraints on my
logic.  In that way, I can simplify the problem enough that I can get my
head around it.  Given that is EXACTLY the same conclusion that Hoare came
to, I don't feel too stupid for doing it :-)

In particular, when I hit that problem, I remove the synchronisation logic
from open code and implement some sort of more structured primitive that
is clean anough for me to reason about.  I can then debug that primitive
on its own.  All classic stuff!

>I also don't entirely agree with the philosophy that all sophisticated 
>coding should be confined in libraries where it is hidden from all but a 
>few self-appointed experts.  It's quite possible that someone else would 
>come up with a new approach that is better - as long as (s)he has access 
>to the tools.

I didn't say that the module should be forbidden to any user who feels
confident enough to use it - I agree that is unreasonable.  But it should
be very clear which were the recommended (i.e. fairly safe) techniques and
which need considerable caution.


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

