epicsThreadSleepQuantum() not accurate

epicsThreadSleepQuantum() returns the system clock period on most architectures, but on many this is not the actual minimum sleep period, as measured by epicsThreadPerform.

Additional information:
Suggestion from J. Lewis Muir:

As a first step, I could see adding a function such as

  void epicsThreadSetSleepQuantum(double quantum);

If someone knows what the sleep quantum should be for their particular machine (by experiment or otherwise), they can set it explicitly (at IOC boot time or whenever). If this function is never called, epicsThreadSleepQuantum() behaves just as it does now. But if epicsThreadSetSleepQuantum() has been called, epicsThreadSleepQuantum() returns the explicitly set quantum.

A step beyond this first step might not be a good idea. But if one was to try to implement a step 2 by tackling the problem of automatically determining the actual sleep quantum, perhaps a function could be added with this signature:

  void epicsThreadCalibrateSleepQuantum(void);

This function would use an algorithm to determine the actual sleep quantum and set it via step 1's epicsThreadSetSleepQuantum(). If the user would like to potentially get a more accurate sleep quantum than what is reported by epicsThreadSleepQuantum(), he or she could call this function (at IOC boot time or whenever). Again, the default is the behavior we have now; the user would have to explicitly call this function to get this new behavior.

What algorithm to use is where things might become difficult. I could see it being difficult to come up with an algorithm that would correctly determine a good actual sleep quantum for the wide range of hardware and operating systems on which EPICS runs.

Original Mantis Bug: mantis-324
    http://www.aps.anl.gov/epics/mantis/view_bug_page.php?f_id=324