Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: After aliassing -- parallelisation?
Message-ID: <5476@lanl.gov>
Date: 9 Nov 90 19:38:22 GMT
References: <1990Nov8.183058.25045@maths.nott.ac.uk>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 25

From article <1990Nov8.183058.25045@maths.nott.ac.uk>, by anw@maths.nott.ac.uk (Dr A. N. Walker):
> [... lots of stuff about functions with side-effects in parallel ...]
> [... ending with a solution involving explicit semaphores        ...]
> 	sema s = 1;
> 	f() { int k; down s; k = i++; up s; return k; }
> 
> but who is going to go to so much trouble [and why will we think of
> it in the first place]?  What should users of C and Fortran do?
> Pray?

Hard to tell.  The problem, as stated, is beyond the language
definitions of either language (and most other popular languages as
well).  Certainly the semaphore idea will work (since semaphores are
presumed to be an extension available on all parallel machines).

My own opinion is that functions with side-effects should be
explicitly identified and the the compiler should be responsible for
them.  On a serial machine, the compiler would just be constrained
against reordering or eliminating calls of such functions.  On a
parallel machine, the compiler would be required, not just to
exclude concurrent operations on side-effect functions, but to
enforce a specific order on them.  This means that side-effects
would be expensive - but we knew that already.

J. Giles