Not really. you can do with with some RealTime OS''s, but not with windows (afaik) and not even with linux without some "make linux a RTOS" patch.

its not CPU, really, its clock rate. Most OS''s keep the clock rate down real around 100hz (linux 2.6 uses 1000, i believe) because the higher you go, the more overhead is involved.

problem is, this low you can''t get resolutions of 2 microseconds easily.

no, it is not possible to achieve that with any normal desktop OS ... period.

The reason is simple, the OSes are pre-emptive multi-tasking, with a scheduler whose job it is to maintain fair resource allocation for competing tasks, without undue reasource waste ... the absolute BEST multithreaded OS for the desktop was BeOS, which had a scheduler with 1ms (millisecond, not microsecond) accuracy, this means that in BeOS, if your thread has sufficiently high priority, the sleep function is usually acurate to +- 0.5 ms. Traditionally, windows 32, I know windows 95 and 98 specifically, had a scheduler that was only accurate to the 18.2 FPS timer, aka 55 ms. This was so attrocious as to be completely useless for modern games ... so people did not use it.

An OS could, and some real time OSes due, give timer and wakeup accuracy in the 2-4 um (microsecond) range, but this is the best I have seen to date, and only realy works when there are not many important system threads competing to draw the screen, manage resources, etc ... these OSes usually do not even run a graphical desktop, because they are used for network switching fabric, audio/video feed routing, etc ... normal OSes do not drop to this level, because it is completely inconsistent with trying to acheive efficient use of a processor, on a system which takes more than 1um per normal operation ...

think for a second, 1 um means 1 MHz, if the processor is running at say 1GHz (which is 3 times lower than the top end, and about 3 times higher than the current bottom end), that only gives you 1000 clock cycles to use for all other threads before returning to the current one ... remmber that task switching uses a fair number of clock cycles, as do the operations actually performed by the other threads ... also, the memory itself is more likely running around 266 MHz, 64 bit wide, not couting access latency ... which gives you only the ability to read and write about 500 integers per time slice, maximum ... the real world is MUCH MUCH less (my guess is more like 50-100).

Basically, an OS which tried to achieve such precision would only be suitable with 2 conditions, 1 - the application and facilities used by it (including all needed OS functions) almost completely fits inside cache memory (at least during any given segment of operation), 2 - there are no more than 1-3 threads of any primary importance running in the system, and not more than 5-9 of any significance whatsoever ... else the thrashing would destoy performance.

This is largely speculation on my part, as I am an application programmer, not a system or driver programmer, but I did work for 2+ years on an embedded game platform, and then 2 years at an audio processing company (which used BeOS, many threads, and had significant latency requirements). Please feel free to correct anything I have wrong, I would like to learn more about the current state of things is this area.

because the timers are updated by the clock ship, which is set to a several millisecond accuracy.

Unless there are "high resolution timers" that do some nifty timing operations with CPU cycles.... which would vary a lot, since such things are inexact science last time i checked.

and still, your process can still be task switch in the middle of a busy wait. suddenly its 100 milliseconds later...

check out the rdtsc instruction, it lets you measure clock cycles. its tricky to get the clock frequency though, and unreliable because of modern CPUs changing frequencies in laptops and such.

Can you be more specific about why you need to wait for 2 microseconds? Perhaps there is a much better solution to your particular problem.