views:

93

answers:

2

I have time-critical piece of code in my app. I made the thread which runs it Highest priority - that's the most I could do.

Is there any suggestions on how to make part of the code run in this thread to be interrupted as few times as possible (less context switch occurred) ?

The code is not complicated. I replaced all the method calls with inlined code and I don't use anything of high level (like no LINQ). The most of operations are arithmetic. There is only one comparison of strings (I am thinking of ways how to rid of it). Half of maths are with ints and half with doubles.

The code is x86 .NET 4 C#. Runs on single Xenon X3450 W2008R2. Single app server.

(Unfortunately data is coming from 3d party API which doesn't support x64 (hate it!))

I'd appreciate grown-up discussion with experienced developers.

P.S. The server has no paging file so hard page faults wont happen either (no unwanted IO operations).

+1  A: 

If you make that unmanaged WINAPI code instead, the SetThreadPriority function also supports a THREAD_PRIORITY_TIME_CRITICAL (higher than THREAD_PRIORITY_HIGHEST).

It's also worth boosting the priority of the process in which the thread is running (actual priority depends on a combination of thread and process priority).

You should also avoid making I/O calls on the thread (which could block). Taking it to a perhaps-ridiculous extreme you could also avoid making I/O calls on other threads (which could temporarily boost the priority of those threads).

ChrisW
The critical section of code doesnt do any methods calls (not even accessing properties of objects). Let alone IO!I cant make the whole thread unmanaged because it reads from a managed queue in the beginning of calculations and posts results to a managed object in the end. I will end up with fully unmanaged application. In that case I'd rather use Linux with real-time kernel. But making what I've done in C# in 3 weeks will take me 2-3 months to do in C++ and Linux..
Bobb
@Bobb You could also try reducing the priority of your other threads, to reduce the possibility of their preempting your critical thred.
ChrisW
thanks Chris.. thats done too.. there are about 7 working thread in my app and about 15 other threads made by .NET.... I am moving to a console version today (I have little WPF window now) in hope to reduce number of threads further.
Bobb
+2  A: 

The only thing you need to worry about in terms of context switches, is blocking your thread. So there should be no problem with using LINQ (that is, LINQ-to-objects, obviously LINQ-to-SQL or whatever would involve blocking!). Any sort of arithmetic or calling methods and so on will also not block the thread and so have no impact on context switches.

The other thing that affects context switching is, as you noted, priority. But not just thread priority, also your process's priority. You can use SetPriorityClass to increase your process's priority to ABOVE_NORMAL_PRIORITY_CLASS (I wouldn't bother putting it higher than that) and then set your thread's priority to Above Normal as well.

However, in general, priorities are really only useful when it's a matter of timing (that is, making sure your process responds to external input (network, user input, disk I/O) as fast as possible). It will actually have very little impact on your thread's actual throughput, unless you have other processes that are also CPU-bound running at the same time. But if that's the case, then fiddling with priorities is not going to be a viable long-term solution anyway. This is because you'll find that by setting one of the processes to a higher priority, it'll completely starve the other processes and they'll never run.

So anyway, I would carefully consider things before adjusting thread and process priorities. And, as always, test, test, test!

Dean Harding
thanks. the process already runs with RealTime priority. Are you saying that unless the thread blocks on something or the thread with highest priority needs CPU there wont be context switching?
Bobb
P.S. I know precisely what blocking is. I eliminated method calls to make the section faster. Which will in turn give me better chances not to get interrupted.
Bobb
@Bobb: correct, the thread with the highest priority is always scheduled before any other threads. It will never switch away for a thread with a lower priority (unless it blocks)
Dean Harding