Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / May 2007

Tip: Looking for answers? Try searching our database.

ID of thread that waken up by notify()

Thread view: 
Yao Qi - 12 May 2007 16:12 GMT
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.

Signature

Yao Qi <qiyaoltc@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.

Gordon Beaton - 12 May 2007 19:44 GMT
> 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
[quoted text clipped - 3 lines]
> feasible way to achieve this. I could not find answer from google
> either.

The thread that gets woken up will know.

/gordon

--
Patricia Shanahan - 12 May 2007 20:05 GMT
>> 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
[quoted text clipped - 5 lines]
>
> 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
Yao Qi - 13 May 2007 10:39 GMT
>>> 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
[quoted text clipped - 13 lines]
> 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"?

Signature

Yao Qi <qiyaoltc@gmail.com>    GNU/Linux Developer
http://duewayqi.googlepages.com/

Charles Briscoe-Smith <cpbs@debian.org>:
 After all, the gzip package is called `gzip', not `libz-bin'...

James Troup <troup@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

Mike Schilling - 13 May 2007 19:09 GMT
>>>> 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
[quoted text clipped - 23 lines]
>
> 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 - 13 May 2007 19:51 GMT
> 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 - 13 May 2007 19:56 GMT
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.

>> 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 

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.

Signature

Lew

Yao Qi - 14 May 2007 15:53 GMT
>> We are writing a tool to check the events among threads in the
>> application, and synchronization event is one of these events.  We
[quoted text clipped - 7 lines]
> 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.

>> There is a concept "wait set" in JVM spec,
>>
[quoted text clipped - 4 lines]
> 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.

Signature

Yao Qi <qiyaoltc@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)

Piotr Kobzda - 18 May 2007 15:48 GMT
> 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
Mike Schilling - 13 May 2007 07:24 GMT
> 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
[quoted text clipped - 3 lines]
> 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.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.