Re: Locking objects in an array
Philipp wrote:
Hello,
I've come accross a threading problem for which I can't find a nice
solution. (SSCCP at end of post)
I have a bidimensional array of objects (view it as a 2D lattice). I
want to make atomic operations on random square 2x2 regions of the
lattice. Thus I want to lock the 4 objects of the region, then perform
the change, then unlock those objects. Several threads should be
allowed to work on the array at the same time, if each thread is
accessing a 2x2 region which does not overlap with that of another,
they should be capable of doing the work in a parallel way.
How should I design the code to achieve this?
My solution (which may be misguided) so far is that, each object of
the lattice contains a Lock and has a lock() and unlock() method which
delegate to the lock.
So the approach is basically:
1. call lock() on each of the 4 objects (always in the same order)
2. make change
3. call unlock() on each of the 4 objects
What I don't like about this, is that
a) lock and unlock really have nothing to do in the API of the objects
in the lattice. Would it be possible to achieve the same result
without using an explicit Lock (thus no lock() method), but using the
Java synchronized() mechanism?
b) if an exception is thrown anywhere, eg. where only a part of the
lattice region has been locked, the cleanup is ugly because you can't
test if a lock is presently locked. You have to rely on unlock() to
throw.
c) An exception may leave the lattice in an inconsistent state.
As to (a), I don't see why plain "synchronized" wouldn't work:
synchronized (lattice[i][j]) {
synchronized (lattice[i][j+1]) {
synchronized (lattice[i+1][j]) {
synchronized (lattice[i+1][j+1]) {
// do the dirty deed
}
}
}
}
.... and this would also address (b), because each lock will be
released when control leaves its "synchronized" block, whether
by exception, return, break, drop-through, ...
As far as I know, there's no built-in solution for point (c).
You would need to enforce your own notion of "transaction" on the
multiple updates to the lattice elements. One way to do this would
be to capture the "before" state of all four objects and to restore
all of them if anything throws (this assumes getters and setters for
the objects' state, and that it's harmless to "restore" a state
that hasn't actually been changed):
Value v00 = lattice[i][j].get();
Value v01 = lattice[i][j+1].get();
Value v10 = lattice[i+1][j].get();
Value v11 = lattice[i+1][j+1].get();
try {
// do the dirty deed
}
catch (Exception ex) {
// undo any partial update:
lattice[i][j].set(v00);
lattice[i][j+1].set(v01);
lattice[i+1][j].set(v10);
lattice[i+1][j+1].set(v11);
throw ex; // re-throw the Exception
}
If you can be sure the set() operations won't throw, you could
instead compute the new values without changing what's in place,
and if nothing untoward has happened do all the updates:
// these might throw, but it's harmless:
Value v00 = lattice[i][j].get().nextValue();
Value v01 = lattice[i][j+1].get().nextValue();
Value v10 = lattice[i+1][j].get().nextValue();
Value v11 = lattice[i+1][j+1].get().nextValue();
// we're confident the following won't throw:
lattice[i][j].set(v00);
lattice[i][j+1].set(v01);
lattice[i+1][j].set(v10);
lattice[i+1][j+1].set(v11);
--
Eric.Sosman@sun.com