Re: Reads kill in Java

pugh@cs.umd.edu (Bill Pugh) writes:
> [...]
> This isn't really a Java issue. This issue arises in any language
> that attempts to give clean semantics to programs with data
> races. However, as far as I know, Java is the only language to try to
> do so.


      Check out section 9.10 of the Ada 95 Reference Manual:


<http://www.adahome.com/rm95/rm9x-09-10.html>


about Shared Variables and task (aka threads) synchronization. If you
want more insight about the Ada 95 way of dealing with this problem,
you can look at the annotations of the Annotated Reference Manual:


<ftp://sw-eng.falls-church.va.us/
public/AdaIC/standards/95lrm/LRMascii/aarm.txt>


or to the various documents produced around the Ada 95 revision
process and language maintenance:


<ftp://sw-eng.falls-church.va.us/public/AdaIC/standards/95com>


    You can also ask on the comp.lang.ada newsgroup, some of the Ada
language designers are actively participating there, and they were
well aware of this kind of issues.


    In short, when variables are shared between multiple threads,
updates made by one thread are guaranteed to be made visible only at
"synchronization points" well defined in the RM. There is also one
"pragma" named Atomic that can be used to make all update to a given
variable visible immediatly (provided that your compiler/target
support this operation for your variable type, if not the compiler
will dutifily report the problem).


    It works quite well due to Ada good capabilities in visibility
control. Java big global shared heap with objects references all over
the place wins in the "simple to define for simple cases" category but
you cannot win on every front ;-).


PS: the synchronization point mechanism also works for distributed
shared memory in Ada 95 (aka Shared_Passive partitions, see Annex E for
details).


--LG

Return to the comp.compilers page.
Search the comp.compilers archives again.