C# When a managed thread ends its time-slice will it incur context switch?

In Russinovich book it says that thread (NOTE: this is about OS thread) will need dispatching (scheduling) if it a) became ready b) ended its timeslice, yie开发者_开发技巧lds or blocks.

I have a managed thread in my C# real-time app for which is very important to achieve as fewer context switches as possible.

This thread has Highest priority and the process has RealTime priority which makes my thread OS priority 26 out of 31.

What is going to happen to my thread when it ends its timeslice and there are no waiting threads with priority >= 26 ?

Will be there a context switch to reschedule my thread to run again or context switch will be avoided and the thread will be running uninterrupted?

If there will be context switch - can anyone tell how many CPU cycles it takes on average?

I'd appreciate simple and definitive answers!

Thank you !

How could you make a real-time application on non realtime OS? Here's the information about realtime OS

If your thread has max priority you can end up with unresponsive system (http://blogs.msdn.com/b/oldnewthing/archive/2010/06/10/10022675.aspx)

What is going to happen to my thread when it ends its timeslice and there are no waiting threads with priority >= 26 ?

If there are no other threads with the same or higher priority and your thread does not block (sleep, wait etc) - then system will reschedule it with a new time slice.

From MSDN article: "The system treats all threads with the same priority as equal. The system assigns time slices in a round-robin fashion to all threads with the highest priority. If none of these threads are ready to run, the system assigns time slices in a round-robin fashion to all threads with the next highest priority. If a higher-priority thread becomes available to run, the system ceases to execute the lower-priority thread (without allowing it to finish using its time slice), and assigns a full time slice to the higher-priority thread"

Will be there a context switch to reschedule my thread to run again or context switch will be avoided and the thread will be running uninterrupted?

Context switch will occur when thread is transitioned to kernel mode (blocks, sleeps) You can prevent thread from context switching using Thread.SpinWait.

If there will be context switch - can anyone tell how many CPU cycles it takes on average?

Assuming the context switch is initiated by an interrupt, the overhead of switching from user-level to kernel-level on a (2.8 GHz) P4 is 1348 cycles, on a (200 MHz) P2 227 cycles. Why the big cycle difference? It seems like the P4 flushes its micro-op cache as part of handling an interrupt (go to arstechnica.com for some details on the micro-op cache). Counting actual time, the P4 takes 481 ns and the P2 1335 ns.

The return from kernel-level to user-level will cost you 923 cycles (330 ns) on a P4, 180 cycles (900 ns) on a P2.

The overhead of storing / restoring registers (not counting any TLB overhead / excluding cost of FPU register store / restore) is 188 cycles on the P4 (67 ns), 79 cycles on the P2 (395 ns). (taken from here)