How to simulate a busy task

java-programmer, How to simulate a busy task Hi everybody,

I was trying to perform some tests in a multithreading application and
I would like to simulate overloading. That is, I want to simulate
threads performing a task that takes a certain time T. I have thought
of the following possibilities:

-Implement a method that sleeps during T milliseconds. Problem: this
does not overload the computer, during those T milliseconds other
agents can execute.

-Implement a method that performs a busy wait (while(true){...}) and
exits when T milliseconds have passed. Problem: there could be context
switches in between, and so it could happen that another thread
executes in the meantime (and that execution time should not count to
decide when to terminate the busy wait).

-Similar to the previous approach, but we try to count the milliseconds
elapsed "by hand". That is, in every iteration we obtain the
System.currentTimeMillis() and count as much as 1 millisecond (if it is
really at least 1 millisecond greater than the value measured in the
previous iteration). In this way, if the thread is interrupted while
executing the method, nothing happens because we count at most 1
millisecond per iteration. This does not work either too well, because
more than 1 millisecond could have been elapsed between measures.

So I'm not really sure if I can do this with some precision. If you
have any suggestions, please let me know. Thanks in advance,

S.

java-programmer >> How to simulate a busy task
<email***@***.com> wrote in message
news:email***@***.com...
> Hi everybody,
>
> I was trying to perform some tests in a multithreading application and
> I would like to simulate overloading. That is, I want to simulate
> threads performing a task that takes a certain time T. I have thought
> of the following possibilities:
>
> -Implement a method that sleeps during T milliseconds. Problem: this
> does not overload the computer, during those T milliseconds other
> agents can execute.
>
> -Implement a method that performs a busy wait (while(true){...}) and
> exits when T milliseconds have passed. Problem: there could be context
> switches in between, and so it could happen that another thread
> executes in the meantime (and that execution time should not count to
> decide when to terminate the busy wait).
>
> -Similar to the previous approach, but we try to count the milliseconds
> elapsed "by hand". That is, in every iteration we obtain the
> System.currentTimeMillis() and count as much as 1 millisecond (if it is
> really at least 1 millisecond greater than the value measured in the
> previous iteration). In this way, if the thread is interrupted while
> executing the method, nothing happens because we count at most 1
> millisecond per iteration. This does not work either too well, because
> more than 1 millisecond could have been elapsed between measures.
>
> So I'm not really sure if I can do this with some precision. If you
> have any suggestions, please let me know. Thanks in advance,
>
> S.
>

If you want the CPU to spend time executing wasted cpu cycles do something
like

wait(int x){

for (int a=0;a<x;a++)
for (int b=0;b<x;b++)
for (int c=0;c<x;c++)
}

It gets big quick.

java-programmer >> How to simulate a busy task email***@***.com wrote:

> -Implement a method that performs a busy wait (while(true){...}) and
> exits when T milliseconds have passed. Problem: there could be context
> switches in between, and so it could happen that another thread
> executes in the meantime (and that execution time should not count to
> decide when to terminate the busy wait).

You could run a setup phase where you calibrate the machine to see how long
some standardised loop takes; you'd measure that before starting up any of the
simulation threads.

Beware the optimiser !

-- chris

java-programmer >> How to simulate a busy task John Smith wrote:

> wait(int x){
>
> for (int a=0;a<x;a++)
> for (int b=0;b<x;b++)
> for (int c=0;c<x;c++)
> }
>
> It gets big quick.

More likely, it gets zero quick ;-)

If the optimiser notices those loops (which it will if they consume much time)
then it'll try to optimise them. The server JVM is certainly capable of
removing the body of the above method entirely...

-- chris