How to suspend a java thread for a small period of time, like 100 nanoseconds?

The granularity of sleeps is generally bound by the thread scheduler's interrupt period. In Linux, this interrupt period is generally 1ms in recent kernels. In Windows, the scheduler's interrupt period is normally around 10 or 15 milliseconds

If I have to halt threads for periods less than this, I normally use a busy wait

EDIT: I suspect you'll get best results on jrockit + solaris. The numbers on a windows box are terrible.

@Test
public void testWait(){
    final long INTERVAL = 100;
    long start = System.nanoTime();
    long end=0;
    do{
        end = System.nanoTime();
    }while(start + INTERVAL >= end);
    System.out.println(end - start);
}

For simulation, I would not attempt to simulate in real-time as this doesn't give you reproducible results. i.e. you can't test your simulation.

Instead, I would use a data-driven, simulated clock, and run everything as fast as possible. This gives you reproducible results and allows you to simulate faster than real-time (e.g. 2x to 100x faster)

---

Suspecting a thread takes around 10 microseconds. There is no point trying to suspend a thread for less time than this.

To busy wait for a short period of time, you can try.

long start = System.nanoTime();
while(start + delay >= System.nanoTime());

Note: as @EugeneBeresovsky comments, after your machine has been running for 292 years this could overflow so you might choose to write this as

while(System.nanoTime() - start < delay);

This will fine for delays of less than 292 years instead. You can use System.currentTimeMillis() for much longer delays.

However, even this is not reliable as System.nanoTime() can take up to 300 ns on Centos 5.x so calling it twice is going to take much longer than 100 ns. Also many OS only have a resolution of 1000 ns (1 micro-second) so this loop will wait up to 1 micro-second regardless of the delay you are looking for.

Instead what you can do is to busy wait in a short loop which is not optimised way.

For a delay of 100 ns, I suspect it would be better to busy wait on whatever you are waiting for instead of creating a separate busy loop.