Subj : Re: Solaris real-time thread capabilities
To   : comp.unix.solaris,comp.programming.threads
From : Logan Shaw
Date : Wed Sep 07 2005 12:57 pm

Casper H.S. Dik wrote:
> capnwhit@yahoo.com writes:

>>Hello Eric, Thanks a lot for your reply! Code sample coming up... I
>>basically kept track of the maximum latency between t1 and t2 (as shown
>>in my while loop on my initial post)... the average latency was about
>>1000 ns (over a 5 minute period) but the max latency was 323,000,000!
>>I'll post the sample code shortly...

> Well, *that* is not impossible.  That's because your program was
> hit by a context switch and other processes got to work for apparently
> a lengthy period of time; and if that meant that you later induced a
> page fault, 300ms could easily be explained.

I puzzled over this for a while.

If he creates a processor set and puts his program as the only process
in that set, and if he makes his thread realtime class and sets the
priority to the maximum, and if he sets that processor to no-intr state,
then how can another thread preempt that thread?

As far as I know (according to the Solaris Internals book), the only
priorities above the highest real-time scheduling class priority are
the interrupt priorities, so how would a thread with such a high
priority become runnable on that processor with no-intr set[1]?  The
no-intr state (according to "man psradm") only disables I/O interrupts,
so I guess other interrupts are possible, but it seems fishy to me
that the task is interrupted for 1/3 second.

To make matters more confusing, he's doing one gethrtime() right after
another with no intervening code and noticing a 1/3 second delay between
the two.  His process is VERY unlikely to have a page fault between these
calls, since gethrtime() has its own special trap specifically to make
it faster, so the chances of the relevant page(s) get discarded in that
intervening time are minuscule because the time interval is so short
and the VM clock hands don't move THAT fast, especially on a system
with 2GB of physical RAM (usually).

I'm not saying another thread couldn't be preempting the code and running
at a higher priority, but if it is, I'd be curious to know what thread
it would be that has a higher priority than a realtime scheduling class
thread set to its highest priority.

(That is, assuming everything is as it appears and all the conditions
described above are really met.)

   - Logan

[1]  He mentioned trying all these things, and I assume he did
      try all of them at once.

.