> However, the problem is not the same, and the belief would
> not have been well founded, since it appears that the Java
> version of the problem is indeed amenable to an acceptable solution.
This is a fruitless exercise.
If you look at the early Java threads whitepapers you'll see an
idealized threading system that was near impossible to implement on
existing native threading systems. Just prior to the release of the
JLS 1.0 nearly all of the scheduling rules for threads were relaxed to
what we now know. Part of that early idealized system was the nice
neat spec for wait/notify that makes no mention of spurious wakeups. I
speculate (because I wasn't there) that a similar relaxation in this
area was simply an oversight - and it was later confirmed that there
was no conscious decision to disallow spurious wakeups.
I still argue from a software engineering perspective that spurious
wakeups enforce good programming practice in the use of conditions.
It's only the experience of the past 6 years that has shown that on
mainstream systems (ignoring signal handling bugs in Linux threads)
there's no actual source for these spurious wakeups. That said, the
ability to perform a spurious wakeup has enabled monitor optimisations
that would otherwise not be feasible. This flexibility in a spec can
greatly ease the burden of implementation and it doesn't have any real
cost for the programmer.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:54 EDT