> However, we have seen that wait/notify/interrupt is an area where the
> implementations have not always conformed to the specification, even though
> it appears that they could have. In most areas of IT I think one would
> simply consider the implementations to be broken, and fix them. In this
> particular corner, the view seems to be that we change the specification on
> the grounds that it's easier, and existing programs have lived with
> implementations that didn't conform to the old specification.
I guess I regard it more as:
The specification was hopelessly clueless about feasible threading models
on real machines[*].
The implementations have been less clueless and, where necessary, have
conformed to how the universe actually works rather than to a rather
It's about time that the specification got a clue.
[*] Another symptom of the same problem that gave us Thread.stop() et al.
I don't mean to blame the original Java folks for this stuff, because
(1) they were probably getting advice from the Solaris threads folks,
who at the time were still arguing for Pthreads to include stop() etc
and only later recanted, and (2) you can probably make the naive
semantics work on Oak's original target platforms, single-processor
systems with an embedded OS, but now we want it to work on a 64-way
weakly coherent SMP too.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:45 EDT