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 / Tools / September 2004

Tip: Looking for answers? Try searching our database.

A good Java thread analysis tool?

Thread view: 
Paul Farwell - 16 Sep 2004 14:52 GMT
Can anyone recommend a good thread analysis tool for an application
that runs in a web app environment (JRun/JBoss)? I'm interested in
something that points out places where multiple threads are contending
for the same unsynchronized objects.

I'm mostly interested in a run-time tool. But does anyone know of a
good static (code analysis) tool for multithreading, too?
Robert Klemme - 17 Sep 2004 13:43 GMT
> Can anyone recommend a good thread analysis tool for an application
> that runs in a web app environment (JRun/JBoss)? I'm interested in
> something that points out places where multiple threads are contending
> for the same unsynchronized objects.

Did you really mean to say "multiple threads are contending for the same
<<unsynchronized>> objects"?  Contention normally arised if multiple
threads wait for the same synchronization lock.

> I'm mostly interested in a run-time tool.

Optimizeit has some nice features for this.

> But does anyone know of a
> good static (code analysis) tool for multithreading, too?

Dunno whether a static analysis tool would be feasible at all.  Personally
I don't know any such tool.

Kind regards

   robert
Stephen Kellett - 17 Sep 2004 23:18 GMT
>Can anyone recommend a good thread analysis tool for an application
>that runs in a web app environment (JRun/JBoss)? I'm interested in
>something that points out places where multiple threads are contending
>for the same unsynchronized objects.

Java Thread Validator
http://www.softwareverify.com/publicBeta.html

No idea if it works on a web app - works on Java apps.

Stephen
Signature

Stephen Kellett
Object Media Limited    http://www.objmedia.demon.co.uk
RSI Information:        http://www.objmedia.demon.co.uk/rsi.html

Paul Farwell - 19 Sep 2004 22:34 GMT
Thanks for both of your replies.

I should have been clearer in what I meant by 'contention'. I didn't
mean contention caused by two threads attempting to gain access to the
same monitor. I meant a situation where two threads are accessing the
same object instance (or method) in an unsynchronized way.

Is there a tool out there that warns when two threads access a shared
instance of an object in a non-threadsafe (i.e. unsynchronized) way?

I've checked out the Software Verification and the OptimizeIt thread
tools. Both of them look like they are intended to detect potential
deadlock (or performance problems caused when threads queue up waiting
for a monitor). I'm looking for something that checks for a different
sort of problem - code that isn't synchronized but probably should be.
Robert Klemme - 20 Sep 2004 08:16 GMT
> Thanks for both of your replies.
>
> I should have been clearer in what I meant by 'contention'. I didn't
> mean contention caused by two threads attempting to gain access to the
> same monitor. I meant a situation where two threads are accessing the
> same object instance (or method) in an unsynchronized way.

Ok, that is not contention.

> Is there a tool out there that warns when two threads access a shared
> instance of an object in a non-threadsafe (i.e. unsynchronized) way?
[quoted text clipped - 4 lines]
> for a monitor). I'm looking for something that checks for a different
> sort of problem - code that isn't synchronized but probably should be.

I don't know any tool that is capable of this.  If you think a bit about
the issue you will recognize that it's at minimum very hard if not
impossible.  For example, objects might be drawn from a pool in a thread
safe manner that ensures only one thread at a time has access to an
instance.  Now accesses to these instances do not need to be synchronized
because they are confined to a single thread even though they are accessed
by multiple threads through their lifetime.  How should a tool go about
this and detect that it's an access that does not need a warning?

Even if you access a single instance concurrently by multiple threads it's
not very likely that two threads access an instance at exactly the same
time; if they don't you would have to watch for concurrent accesses in a
certain interval.  But how large an interval should the tool watch?

And after all, there might be accesses to instance data which after
construction of an instance never changes.  So unsynchronized access to
these methods is completely ok.

The problem with all this is, that it depends on the application's
semantic whether an unsynchronized access is ok or not.  Since software
tools don't have access to semantics, it'll be very hard to come up with a
tool that gives reasonable warnings (i.e. with a good heuristic that
doesn't yield too many false positives).

Kind regards

   robert
Paul Farwell - 20 Sep 2004 22:32 GMT
Thanks, Robert. You are probably correct about it being unlikely (if
not impossible) to create a tool that detects race conditions.

I did some more investigation. JLint claims to be a static analysis
tool which can detect (probable) race conditions. However, when I ran
it against my code, it flagged just about every non-synchronized
public method setter/getter as potentially a race condition problem.
That's probably correct (in a very strict sense) but not very useful.

Seems like a runtime tool would be more useful. I know that JProbe had
a tool that flagged potential race conditions as the code ran. Not
sure why they pulled the product from the market.

At any rate, thanks for your help.
Robert Klemme - 21 Sep 2004 08:41 GMT
> Thanks, Robert. You are probably correct about it being unlikely (if
> not impossible) to create a tool that detects race conditions.
[quoted text clipped - 4 lines]
> public method setter/getter as potentially a race condition problem.
> That's probably correct (in a very strict sense) but not very useful.

Exactly.

> Seems like a runtime tool would be more useful. I know that JProbe had
> a tool that flagged potential race conditions as the code ran. Not
> sure why they pulled the product from the market.

Maybe because it's output was equally useful as that of JLint? :-)

> At any rate, thanks for your help.

You're welcome.

Regards

   robert
Michael Amling - 21 Sep 2004 12:34 GMT
>>Thanks, Robert. You are probably correct about it being unlikely (if
>>not impossible) to create a tool that detects race conditions.
[quoted text clipped - 12 lines]
>
> Maybe because it's output was equally useful as that of JLint? :-)

  Can any of these tools recognize when access to object A is
serialized by synchronizing on object B?
  Sometimes you have to do that because the JVM does its own syncs on
your objects.

--Mike Amling
Robert Klemme - 21 Sep 2004 12:43 GMT
>    Can any of these tools recognize when access to object A is
> serialized by synchronizing on object B?

I doubt so.  It's quite difficult to detect IMHO.

>    Sometimes you have to do that because the JVM does its own syncs on
> your objects.

What exactly do you want to say with that last sentence?  AFAIK there is
no synchronization other than explicit apart from object creation, but
that's a different story.

Kind regards

   robert
Michael Amling - 22 Sep 2004 14:49 GMT
>>   Can any of these tools recognize when access to object A is
>>serialized by synchronizing on object B?
[quoted text clipped - 7 lines]
> no synchronization other than explicit apart from object creation, but
> that's a different story.

  I guess that wasn't phrased very well. I mean you can be taken by
surprise by synchronized super methods in your objects that are
extensions of standard Java objects.
  One case where I've seen this is in a class I had that extends
Thread. The monitor of instance A of that class was held by one thread
while another thread tried to start() instance A. Since Thread.start()
is synchronized, the start() waited indefinitely. So I changed the
program to serialize instances of that class by synchronizing on other,
related, objects.

--Mike Amling
Sebastian Millies - 28 Sep 2004 12:39 GMT
> >>   Can any of these tools recognize when access to object A is
> >>serialized by synchronizing on object B?
[quoted text clipped - 19 lines]
>
> --Mike Amling

This sounds as if it may be related to what is called the "inheritance
anomaly"
in concurrent OO languages. Don't know the literature though. You may be
interested in the comp.lang.java.programmer thread containing this post:
http://groups.google.com/groups?hl=de&lr=&ie=UTF-8&frame=right&th=8a9bd672103c31
70&seekm=slrnclg98n.5lf.Colin_Paul_Gloster%40montezuma.acc.umu.se#link6


-- Sebastian


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.