wait/notify cpu cost?

[Jeff]

OptimizeIt accused one of my run methods of consuming 20% of cpu. However,
it's just a wait() followed by a switch statement. The method called by the
accused, addMeasurement(), only consumes 3%. So there's 17% of cpu that
is supposedly consumed by the accused run method.

Does wait cost significant cpu or is OptimizeIt accounting for waiting time
as cpu usage? BTW, I posted to the OptimizeIt newsgroup, but didn't get an
answer.

Thanks

Here's the method:

public void run() {
while( true ) {
synchronized( myQueue ) {
try {
myQueue.wait();
}
catch (InterruptedException e) { cat.warn("Exception: " + e+
" while waiting on my BarData"); }

while ( myQueue.size() > 0 ) {
reportCard = (ReportCard) myQueue.removeLast();

switch ( reportCard.eventIdentifier ) {
case id1 :
tdAlarm.addMeasurement( reportCard );
break;

case id2 :
faAlarm.addMeasurement( reportCard );
break;

case id3 :
fffAlarm.addMeasurement( reportCard );
break;

case id4 :
fcAlarm.addMeasurement( reportCard );
break;
}
} // while q > 0
} // sync
} // while true
} // close run

 

[Larry Barowski]

OptimizeIt accused one of my run methods of consuming 20% of cpu. However,
it's just a wait() followed by a switch statement. The method called by the
accused, addMeasurement(), only consumes 3%. So there's 17% of cpu that
is supposedly consumed by the accused run method.

Does wait cost significant cpu or is OptimizeIt accounting for waiting time
as cpu usage? BTW, I posted to the OptimizeIt newsgroup, but didn't get an
answer.

I know that JPDA/JDA has a bug on some versions of Java
where it reports waiting threads as running under certain
conditions. That could be related. Try it under J2SDK 1.5
Beta if possible, since it doesn't have that problem.

-Larry Barowski

 

[Roedy Green]

ublic void run() {
while( true ) {
synchronized( myQueue ) {
try {
myQueue.wait();
}

I suggest you either run a profiler,
http://mindprod.com/jgloss/profiler.html

and see which lines of code are getting hammered, or
put in your own counters to count how many times various bits of code
are being executed.

For example, you may find something is breaking the .wait over and
over and over in a tight loop.

 

[Tony Morris]

A call to Object.wait() causes the current thread to enter a "ready" (but
not running) state consuming no CPU.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Larry Barowski]

A call to Object.wait() causes the current thread to enter a "ready" (but
not running) state consuming no CPU.

Yes, and JDI sometimes incorrectly reports this state as running
(com.sun.jdi.THREAD_STATUS_RUNNING) on many VMs,
while others always correctly report it as THREAD_STATUS_WAIT.
I don't work with JVMPI so I don't know if it has the same
problem.

-Larry Barowski

 

[Chris Uppal]

A call to Object.wait() causes the current thread to enter a "ready" (but
not running) state consuming no CPU.

Seems as if it'd be a reasonable implementation strategy to busy-spin for a
limited time if the JVM were running on multiple CPUs.

(Just BTW)

-- chris