Deadlock-avoiding with .equals() (was: Re: Vector (was Re: Change character in string))
Tom Anderson <twic@urchin.earth.li> wrote:
On Sat, 14 Mar 2009, Andreas Leitgeb wrote:
For the philosophers that would mean, that before even taking their
first fork, they'd first have to grab the one napkin in the center of
the table (ugh :-)
Btw., this also extends to that the rivalling school of misosophists at
next table can have their own table's central napkin, and do not need to
go over to their arch-foes' table to take theirs. The misosophists, of
course, also won't borrow any of the philosophers' forks.
Actually, there's another way: if there's a total order on the forks, then
the philosophers just have to agree to always pick them up in that order.
That thought also occurred to me. If java maintains internally some object
identity, that won't change during the whole lifetime of the object,
especially not during any GC'ing. (I don't know if "the internal address
of the object" as mentioned in the javadoc for java.lang.Object really has
that property. It should, but it's not guaranteed to exist) With that,
Java could add a multisync(obj1,obj2,...) feature, that would first make
a consistent re-arrangement of the given objects based on that identity,
and then lock them all in the "same" order.
As a small inconvenience it would be necessary to throw some Exception,
if the current Thread already had any of these objects locks. (Strictly
it could even allow certain held locks (namely if it's the first few
according to the internal arrangement, but that would make it rather
unpredictable for the programmer who doesn't know the internal ordering,
but may vaguely know about this Thread's already held locks. The trivial
cases could even be caught by the compiler.)
I do not propose this feature - just brainstorm what could be possible.
// assume non-identity, non-nullity and listness are known by this point
public boolean equals(List<?> that) {
List<?> first;
List<?> second;
if (order(this, that)) {
first = this;
second = that;
}
else {
first = that;
second = this;
}
synchronized (first) {
synchronized (second) {
return list.equals(that);
}
}
}
That's about what multisync would do just without exposing the
order and with any (>=2) number of objects. And you must be
sure that the calling thread doesn't yet have any of the locks,
or you still may run into deadlocks (namely if you happens to
have the second one).