When using fixedrate
scheduling, there are two possible situations as to when the next invocation of myMethod
occurs:
- if after
RATE_IN_MS
milliseconds from the last myMethod
invocation, myMethod
is no longer running, then that's when myMethod
will be invoked again.
- if after
RATE_IN_MS
milliseconds from the last myMethod
invocation that invocation is still running and it hasn't returned, then this will cause the next scheduled call to be blocked until the current invocation is over.
For example if RATE_IN_MS
is 10 ms, let's consider two scenarios:
myMethod
takes 5 ms to execute. In this case, a new myMethod
invocation will occur every 10 ms because 5 ms is less than 10 ms.
- if for some reason the last
myMethod
invocation took 12 ms to complete, which is longer than 10 ms, then the next one will be queued. So there will be a minimum of 12 ms between invocation which is more than RATE_IN_MS
.
Now to answer your question specifically, let's say that RATE_IN_MS
is 10 ms, then definitely we have the second case from my above example, however, the wait time will not be multiplied in two as you expect, rather it will be consisted of two time periods:
- the time it took
myMethod
to reach Thread.sleep(RATE_IN_MS)
which could be much less than RATE_IN_MS
, let's say it's only 3 ms and let's call this time X.
- the time the Thread sleeps which is
RATE_IN_MS
which we are saying it's 10 ms for example.
Then the total time between invocations of myMethod()
will be: X+RATE_IN_MS
which according to my example is 13 ms and not RATE_IN_MS
* 2.