Re: Reads kill in Java

Laurent Guerby <>
6 Nov 1998 15:52:06 -0500

          From comp.compilers

Related articles
Reads kill in Java (1998-11-01)
Re: Reads kill in Java (Laurent Guerby) (1998-11-06)
| List of all articles for this month |

From: Laurent Guerby <>
Newsgroups: comp.compilers
Date: 6 Nov 1998 15:52:06 -0500
Organization: Club-Internet (France)
References: 98-11-006
Keywords: Java, optimize, parallel (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:


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:


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


    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


Post a followup to this message

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