I have a multi-threaded application, and in a certain section of code I use a Stopwatch
to measure the time of an operation:
MatchCollection matches = regex.Matches(text); //lazy evaluation
Int32 matchCount;
//inside this bracket program should not context switch
{
//start timer
MyStopwatch matchDuration = MyStopwatch.StartNew();
//actually evaluate regex
matchCount = matches.Count;
//adds the time regex took to a list
durations.AddDuration(matchDuration.Stop());
}
Now, the problem is if the program switches control to another thread somewhere else while the stopwatch is started, then the timed duration will be wrong. The other thread could have done any amount of work before the context switches back to this section.
Note that I am not asking about locking, these are all local variables so there is no need for that. I just want the timed section to execute continuously.
edit: another solution could be to subtract the context-switched time to get the actual time done doing work in the timed section. Don't know if that's possible.
If not, is there any other way to prevent context switching? Thanks, Yaron If the task is the only task at the highest priority, then there can never be another task that becomes the highest priority ready task, so the only way for a context switch to happen would be for the task to block, when a context switch basically MUST happen.
The context switch time is the difference between the two processes. Let’s take an example: Assume there are only two processes, P1 and P2. P1 is executing and P2 is waiting for execution.
Also, since context switching changes the stack to the new task, unless you are using some stack checking hardware, a context switch generally won’t cause much issue with the tasks stack usage, at most it adds the tasks context to the stack.
Another issue is that swapping is governed by the scheduling algorithm of the operating system and there may be many kernel-level threads that are also doing context switches. Other processes could be contending for the CPU or the kernel handling interrupts.
You can't do that. Otherwise it would be very easy for any application to get complete control over the CPU timeslices assigned to it.
You can, however, give your process a high priority to reduce the probability of a context-switch.
Here is another thought:
Assuming that you don't measure the execution time of a regular expression just once but multiple times, you should not see the average execution time as an absolute value but as a relative value compared to the average execution times of other regular expressions.
With this thinking you can compare the average execution times of different regular expressions without knowing the times lost to context switches. The time lost to context switches would be about the same in every average, assuming the environment is relatively stable with regards to CPU utilization.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With