|
|
 |
 |
 |
 |
ID of thread that waken up by notify()
The notify method will wake up one thread waiting to reacquire the
monitor for the object. How could I know which thread is waken up by
this notify method called by another thread?
I looked at java.lang.management.* and JVMTI, but I could not find a
feasible way to achieve this. I could not find answer from google
either.
Any comments on this are appreciated. Thanks.
--
Yao Qi <qiyao@gmail.com> GNU/Linux Developer
http://duewayqi.googlepages.com/
Returning is the motion of the Tao.
Yielding is the way of the Tao.
The ten thousand things are born of being.
Being is born of not being.
On Sat, 12 May 2007 23:12:33 +0800, Yao Qi wrote: > The notify method will wake up one thread waiting to reacquire the > monitor for the object. How could I know which thread is waken up by > this notify method called by another thread? > I looked at java.lang.management.* and JVMTI, but I could not find a
> feasible way to achieve this. I could not find answer from google
> either.
/gordon
--
Gordon Beaton wrote: > On Sat, 12 May 2007 23:12:33 +0800, Yao Qi wrote: >> The notify method will wake up one thread waiting to reacquire the >> monitor for the object. How could I know which thread is waken up by >> this notify method called by another thread? >> I looked at java.lang.management.* and JVMTI, but I could not find a
>> feasible way to achieve this. I could not find answer from google
>> either.
> The thread that gets woken up will know.
which caller of notify caused it to wake up.
It might help to describe the higher level objective. If it matters
which one gets woken up, why are they all waiting for the same monitor?
Would it be enough to have each thread put a message, identifying
itself, on a queue when it gets woken?
Patricia
"Yao Qi" <qiyao @gmail.com> wrote in message
> The notify method will wake up one thread waiting to reacquire the
> monitor for the object. How could I know which thread is waken up by
> this notify method called by another thread?
> I looked at java.lang.management.* and JVMTI, but I could not find a
> feasible way to achieve this. I could not find answer from google
> either.
A common pattern, that avoids race conditions, is something like
Requesting thread:
synchronize(monitor)
{
do something to indicate what you want
the worker thread to do, e.g. put an
entry in a work queue;
monitor.notify();
}
Worker thread:
while (true)
{
synchronize(monitor)
{
if (there's work to do)
{
grab it (e.g. pull the entry off the work queue)
}
else
{
monitor.wait();
}
}
do the work;
}
It's quite possible that the monitor.notify() will take place while all
worker threads are busy doing work, that is, that it won't wake up any of
them. Still, the work gets done by the first worker thread to finish its
currrent work and look for more. If you want to connect the worker thread
with the thread that made the request, a simple, reliable method is to put
the requesting and worker thread IDs in the work queue entry.
Patricia Shanahan <p @acm.org> writes: > Gordon Beaton wrote: >> On Sat, 12 May 2007 23:12:33 +0800, Yao Qi wrote: >>> The notify method will wake up one thread waiting to reacquire the >>> monitor for the object. How could I know which thread is waken up by >>> this notify method called by another thread? >>> I looked at java.lang.management.* and JVMTI, but I could not find a
>>> feasible way to achieve this. I could not find answer from google
>>> either.
>> The thread that gets woken up will know.
> Or at least each thread knows when it wakes up, but not necessarily
> which caller of notify caused it to wake up.
> It might help to describe the higher level objective. If it matters
> which one gets woken up, why are they all waiting for the same monitor?
> Would it be enough to have each thread put a message, identifying
> itself, on a queue when it gets woken?
application, and synchronization event is one of these events. We want
to know something like this, Thread A calls notify() and then Thread B
is waken up from wait() by Thread A.
There is a concept "wait set" in JVM spec,
http://java.sun.com/docs/books/jvms/second_edition/html/Threads.doc.h...
and could we get the information of "wait set"?
--
Yao Qi <qiyao@gmail.com> GNU/Linux Developer
http://duewayqi.googlepages.com/
Charles Briscoe-Smith <c@debian.org>:
After all, the gzip package is called `gzip', not `libz-bin'...
James Troup <t@debian.org>:
Uh, probably because the gzip binary doesn't come from the
non-existent libz package or the existent zlib package.
-- debian-bugs-dist
"Yao Qi" <qiyao @gmail.com> wrote in message
> Patricia Shanahan <p @acm.org> writes: >> Gordon Beaton wrote:
>>> On Sat, 12 May 2007 23:12:33 +0800, Yao Qi wrote:
>>>> The notify method will wake up one thread waiting to reacquire the
>>>> monitor for the object. How could I know which thread is waken up by
>>>> this notify method called by another thread?
>>>> I looked at java.lang.management.* and JVMTI, but I could not find a
>>>> feasible way to achieve this. I could not find answer from google
>>>> either.
>>> The thread that gets woken up will know.
>> Or at least each thread knows when it wakes up, but not necessarily
>> which caller of notify caused it to wake up.
>> It might help to describe the higher level objective. If it matters
>> which one gets woken up, why are they all waiting for the same monitor?
>> Would it be enough to have each thread put a message, identifying
>> itself, on a queue when it gets woken?
> We are writing a tool to check the events among threads in the
> application, and synchronization event is one of these events. We want
> to know something like this, Thread A calls notify() and then Thread B
> is waken up from wait() by Thread A.
> There is a concept "wait set" in JVM spec,
> http://java.sun.com/docs/books/jvms/second_edition/html/Threads.doc.h...
> and could we get the information of "wait set"?
notifies monitor M, thread B waits on monitor N, thread B is awakened) and
then analyze the log.
Yao Qi wrote:
> We are writing a tool to check the events among threads in the
> application, and synchronization event is one of these events. We want
> to know something like this, Thread A calls notify() and then Thread B
> is waken up from wait() by Thread A.
Possibly most accurate approach would be to provide your own
implementation of java.lang.Object to the JVM (using e.g.
-Xbootclasspath/p:... option) which will record all calls of wait(),
notify() and notifyAll(), together with a references to the object and a
current thread info. And then analyze recorded entries.
Examine the code from there:
http://groups.google.com/group/comp.lang.java.programmer/msg/5d7d2ade...
piotr
Yao Qi wrote: >> We are writing a tool to check the events among threads in the >> application, and synchronization event is one of these events. We want >> to know something like this, Thread A calls notify() and then Thread B >> is waken up from wait() by Thread A. Piotr Kobzda wrote: > Possibly most accurate approach would be to provide your own > implementation of java.lang.Object to the JVM (using e.g. > -Xbootclasspath/p:... option) which will record all calls of wait(), > notify() and notifyAll(), together with a references to the object and a > current thread info. And then analyze recorded entries. >> and could we get the information of "wait set"? > Examine the code from there: > http://groups.google.com/group/comp.lang.java.programmer/msg/5d7d2ade...
of stuff in there. I do not know if it will help with your thread needs, but
it's one place I'd research if I were writing such a tool.
<http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jpda.html>
I imagine you could write a tool that sets breakpoints on the Object thread
calls of interest and then "checks" the "events" before returning control to
the target app.
--
Lew
Piotr Kobzda <p @gazeta.pl> writes: > Yao Qi wrote: >> We are writing a tool to check the events among threads in the
>> application, and synchronization event is one of these events. We
> want
>> to know something like this, Thread A calls notify() and then Thread B
>> is waken up from wait() by Thread A.
> Possibly most accurate approach would be to provide your own
> implementation of java.lang.Object to the JVM (using
> e.g. -Xbootclasspath/p:... option) which will record all calls of
> wait(), notify() and notifyAll(), together with a references to the
> object and a current thread info. And then analyze recorded entries.
mentioned above, and currently, we are using ASM to do instrumentation.
I think the only problem in on notify(), because one thread is picked up
from "wait set", and is resumed to run, but we could not know which thread is
picked up and resumed to run.
I still thinking how to solve this problem by means of instrumentation.
I read that code before, and that code is based on jdk 6. However, our
target jdk is jdk 5.
--
Yao Qi <qiyao@gmail.com> GNU/Linux Developer
http://duewayqi.googlepages.com/
"Computers and autmation have become so ingrained and essentaial to day-to-day business that a sensible business should not rely on a single vendor to provide essential services........Thus is is always in a customers' interests to demand that the software they deploy be based on non-proprietary platforms."
-- Brian Behlendorf on OSS (Open Sources, 1999 O'Reilly and Associates)
|
 |
 |
 |
 |
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc