[concurrency-interest] When do you use wait/notify?

Larry Riedel larryr@saturn.sdsu.edu
24 Jan 2004 20:31:56 -0000

> We'd like to know, given what is in JSR166, what kinds of cases
> might still arise where application writers will use error-prone
> code involving especially wait/notify rather than higher-level
> constructions. [...] (As in my last mail, atomics, park/unpark,
> and other lower-level features in the subpackages exist for the
> sake of infrastructure developers who we expect to write customized
> synchronization code, but this is a very different audience.)

Since I as an "application" and "infrastructure" developer have no
appreciation for the idea that application developers should not
want/expect/plan to be directly using those nominally "lower-level"
features, or for the idea that "higher-level" constructs built on them
are inherently less error prone in general practice for application
developers, it seems to me there may be significant misapprehensions
about Java application developers, and if so I think correcting those
misapprehensions may have the most significant positive effect on design
of the JDK APIs, assuming the measure of success is that the JDK APIs
are put to use in delivering new value to people.

I think the presentation via the JDK APIs of the capabilities provided
by the nominally "lower-level" constructs should be expected to be
used equally as well directly by "application" developers as through
"higher-level" constructs formed by "infrastructure" developers.  Since
many/most(/all?) of the capabilities provided by the JSR166 APIs are
fairly fundamental, as are the capabilities provided by the Java
language facilities and the java.lang.Object and java.lang.Thread
classes, I expect all of them to continue to be regularly directly used
by application developers, and I hope the JDK APIs will have been
designed with consideration that this is normal, natural, and desirable.