Re: optimizeit: how to workaround/minimize wrong cput time in Object.wait()

From: NOBODY (antispam_at_0.0.0.0)
Date: 11/09/04 

Date: Tue, 09 Nov 2004 14:25:24 GMT

> Or it means, there are too many invocations of wait().
> You'd probably then want to switch from notifyAll() to notify(). Or
> you have a problem on the notifier side, for example with a farmer
> worker scenario where the farmer is too slow putting tasks into the
> task queue; then workers will starve and will wait most of the time.

I already have separated writers semaphore and readers semaphore.
The writer notify() one blocked reader, reader notify() one blocked
writer. Works great. That was the fix I tried. But didn't change much the
profile.

>> it. What I want to determine is the real wait() %cpu due to real
>> contention to reaquire the monitor.
>
> So you don't want CPU time but wall clock time.

I never want clock time. I already have monitored throughput of my code.

A stackframe could be on wait() but actually the thread is done waiting
(waited, in JVMPI language) and tries to acquire the monitor.

Would that part will be shown as cpu or not? Not documented. I supposed
yes because that would explain the 70% of time in wait() caused by
contention. I agree the cpu is not working for that thread though and I
shouldn't care, but...

But excessive contention (like you mentionned through notifyAll()) is
only detectable by guessing if the invocation count is to high, which
requires intrumentation mode, hence give a very biased result.

So I don't know if I have high contention or if it is just a rounding
error! That's the whole problem.

I was planning to try other profilers. I guess this is inevitable.

If any reader have the answer to my original question (how to minimize
now called 'rounding error' in optimize it), please answer. I'm still
listening.

Thanks.

Relevant Pages