ID of thread that waken up by notify()

[Yao Qi]

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 <[email protected]> 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.

 

[Gordon Beaton]

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.

/gordon

--

 

[Patricia Shanahan]

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?

Patricia

 

[Mike Schilling]

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.

I'd be interestind in knowing why you need this.

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.

 

[Yao Qi]

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.html#21294

and could we get the information of "wait set"?

--
Yao Qi <[email protected]> GNU/Linux Developer
http://duewayqi.googlepages.com/

Charles Briscoe-Smith <[email protected]>:
After all, the gzip package is called `gzip', not `libz-bin'...

James Troup <[email protected]>:
Uh, probably because the gzip binary doesn't come from the
non-existent libz package or the existent zlib package.
-- debian-bugs-dist

 

[Mike Schilling]

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.html#21294

and could we get the information of "wait set"?

The best you can do, I think, is to log the interesting events (thread A
notifies monitor M, thread B waits on monitor N, thread B is awakened) and
then analyze the log.

 

[Piotr Kobzda]

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.

There is a concept "wait set" in JVM spec,
http://java.sun.com/docs/books/jvms/second_edition/html/Threads.doc.html#21294

and could we get the information of "wait set"?

Examine the code from there:
http://groups.google.com/group/comp.lang.java.programmer/msg/5d7d2ade8ecdaec1


piotr

 

[Lew]

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/5d7d2ade8ecdaec1

Woudln't the JPDA help? It's supposed to have low-level hooks for all kinds
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.

 

[Yao Qi]

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.

I think Bytecode instrumentation could do the same thing as your
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.

Examine the code from there:
http://groups.google.com/group/comp.lang.java.programmer/msg/5d7d2ade8ecdaec1

I read that code before, and that code is based on jdk 6. However, our
target jdk is jdk 5.

--
Yao Qi <[email protected]> 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)

 

[Piotr Kobzda]

I think Bytecode instrumentation could do the same thing as your
mentioned above, and currently, we are using ASM to do instrumentation.

Yes. But I'm afraid that it won't work in your situation.

To wrap the original native methods of Object, there is required support
for a native methods prefix change, which is a new instrumentation 1.6
feature (setNativeMethodPrefix()).

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.

For me, it seams to be easiest part of your problem. Patricia already
suggested a solution based on queues. You may also consider using a Map
of Sets of Threads keyed by objects for which wait() has been called.
Or develop some other method...

I still thinking how to solve this problem by means of instrumentation.

I think it's impossible because of the following requirement:

our
target jdk is jdk 5.

With that, probably the only way to solve it, is to use JPDA (already
pointed out by Lew).


piotr