Re: About multithreading
Piotr Kobzda wrote:
It tries to acquire a lock on a given object, and than, in a case when a
lock acquiring thread is blocked, makes a use of JMX's ThreadInfo to
find a thread which holds this lock.
Unfortunately again, it introduces a new problem (beside of "mutability"
and "usefulness" problems mentioned by Eric earlier).
Now each thread waiting to acquire a lock (in the Executor's thread
pool) can not be easily canceled.
This is because a thread waiting for monitor on synchronized statement
is not interruptible using its associated Future.cancel() method. It
can not be even canceled using deprecated Thread.stop().
As a result all new threads might remain alive long time (including
infinity) before acquiring a lock, which in turn might result in a lot
of unwanted threads in pool.
This shows important advantage of Doug Lea's Locks over classic Java
monitors -- locks implementing java.util.concurrent.Lock can be acquired
interruptibly. However, there is allowed to change a default locks
semantics in implementation, which makes proposed method generally
useless for this kind of locks too.
So now it seems also to me, there is no general and nice way (unless
some additional assumptions will be provided) to know which thread holds
a lock for any given object.
piotr