(j3.2006) (SC22WG5.4020) LOCK/UNLOCK question

[Van Snyder]

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 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3