jmanson@cs.umd.edu wrote,
> But as far as data race free languages being the way of the future -
> you have to come up with a way to express no data races in the
> language AND have the freedom to "roll your own synchronization" the
> way advanced concurrent programmers want to. There is too much you
> can't do with the current state of the art of these languages (double
> checked locking springs to mind for some perverse reason).
I think I have a better example: I/O.
I've spent the last couple of days putting together an implementation of
java.lang.isolate.IsolateMessageDispatcher for the JSR-121 reference
implementation, and whilst the mechanisms described in Boyapati, Lee
and Rinard's paper would have been extremely useful (eg. my lock-order
comments at the head of methods could be checked and enforced by the
compiler) their type system isn't able to express the fact that from a
synchronization point of view,
// Thread A
selector.select()
// Thread B
channel.write(...) // where channel is registered with selector
// Thread C
selector.wakeup()
is roughly equivalent to,
// Thread A
synchronized(selector)
{
selector.wait();
}
// Thread B/C
synchronized(selector)
{
selector.notify();
}
This equivalence pretty clearly has the potential to interact with lock-
order assertions. I'd like to think that their scheme could be extended
to cover these implicit forms of synchronization.
More generally, I really like these type-based approaches (for
synchronization as here, and also for memory management and Ambient-
style location) and I'm sympathetic to Bart's "goto of the '90s"
slogan. But to do this properly (ie. with enough expressiveness to
allow useful work to be done, yet with enough consiseness to keep the
language usable) would take such drastic changes to Java's type system
that it wouldn't really make a lot of sense to call the resulting
language "Java" any more.
Cheers,
Miles
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:42 EDT