Question

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).

Was it helpful?

Solution

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!

OTHER TIPS

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).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top