(j3.2006) (SC22WG5.4022) [ukfortran] LOCK/UNLOCK question

[N.M. Maclaren]

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 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679