Re: How to acquire object's monitor optionally?
On Sun, 28 Sep 2008, Chris wrote:
Mark Space wrote:
Chris wrote:
I've tried implementing some complex locking schemes, including one based
on ReentrantLock, and another using a roll-your-own scheme with
AtomicBoolean. Each has failed for its own reasons. (I've got a lot of
hours in this).
I think my answer is that I doubt I could do better than the functionality
provided by ReentrantLock and tryLock(). Why did these fail? I really
curious what could be the issue here.
If these really did fail then I don't think there's much hope of providing
you with a better alternative.
The problem with ReentrantLock is that the same thread that locks the lock
must unlock it.
I've got one main thread that spins off other threads that execute the
method. It's not possible for the main thread to lock, and then the spun-off
thread to unlock when it's done.
It's also not possible with java monitors, so to return briefly to your
original question, using those here wouldn't help.
If I have the spun-off thread do the locking and unlocking, then I get a
problem where the main thread spins off the thread, a condition changes
and I no longer want to execute the method (basically the app needs to
shutdown), then the spun off thread tries to lock and I get errors. I
really need to have the main thread attempt to lock before it spins off
the other thread.
I'm still a bit unclear about your system (not that this thread is for my
benefit, of course). What is the lock protecting? Why does the attempt to
lock fail when shutdown is happening?
The answer, perhaps, is to have the spun-off thread check to see if
we're in shutdown mode before it runs. But I get errors there, too --
I've got to create a "shutting-down" flag, and have a synchronized {}
around that, and for some reason things aren't happening in the right
sequence.
How about just catching those exceptions and responding by doing whatever
the worker thread has to do to shut down?
If I could have a ReentrantLock where the locking and unlocking threads
were different, then I think things would work ok.
What if you had something that was like a ReentrantLock but had a
lockOnBehalfOf(Thread t) method? Your main thread could use that to obtain
the lock for the worker thread before handing off. Such a thing probably
wouldn't be too hard to write.
tom
--
I am predictable. I worry about this, but then I think, "I am predictable
but right, so I don't care." -- coffeeandink