Re: How to acquire object's monitor optionally?
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.
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.
Sounds like you're making it more complicated than you need to, but read
on.
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.
If I could have a ReentrantLock where the locking and unlocking threads
were different, then I think things would work ok.
You can try using Semaphores. If all your using this for is a "shutting
down" flag, you can use a "volitial boolean shuttingDone = false"; and
consider having your threads setDaemon(true).
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>