Is the overhead of acquiring a lock depending on the OS timer resolution on a context switch?
Suppose thread 1 is trying to acquire a lock on lockObj using a statement lock(lockObj)
, but this object is already locked by thread 2, thread 1 is currently trying to acquire a lock on it. Topic 1 will be locked, right?
Now, suppose there is a context switch during this blocking because there are other threads and applications waiting to start. Is it time until thread 1 is turned on in the Starting state and can acquire a lock based on the OS timer resolution (Ex: default 15.6ms on Windows 7)?
If the answer to the above question is YES, then I have another doubt:
It is easy to create a simple program to check average costs Thread.Sleep(1)
using Stopwatch and conclude that it converges to the OS timer resolution (eg 15.6ms). But I'm having a hard time writing a program to get the same output for the lock statement . Mainly because:
1) It is difficult to make sure that a thread trying to acquire a lock will always block (or at least know WHEN it blocked before acquiring the lock);
2) I don't know how to force the context switch whenever a thread tries to acquire locks. Is there ALWAYS a context switch when the current running thread blocks?
Any help would be appreciated.
source to share
Suppose thread 1 is trying to acquire a lock on lockObj using the lock (lockObj) statement, but this object is already locked thread 2 is currently trying to acquire a lock on it. Thread 1 will block, right?
Yes.
Now suppose there is a context switch during this blocking because there are other threads and applications waiting to start. Is the elapsed time until thread 1 is put into startup state and can acquire a lock based on the OS timer resolution (Ex: default 15.6ms on Windows 7)?
Not directly, no. Typically, thread 1 will be ready as soon as the wait object it was blocked on is signaled. AT THAT TIME, the Scheduing OS algorithm will run and thread 1 will be launched on the kernel if it is free or if its priority is high enough to be included in the set of threads to run on the available cores. It is possible that the timer interrupts my match and sets another high priority "thread 3" and therefore prevents thread 1 from starting, but it also says that "getting the lock depends on the OS timer resolution".
If there is a kernel free to start thread 1, I found empirically that it starts ~ 7us after a signal from thread 2 on my windows system - a few microseconds, not 15.6ms or something.
If thread 1 had to wait for the next timer interrupt to fire some signal, performance would be terribly bad. It doesn't need to wait - the OS was introduced by a signal from thread 2, and the OS decides which set of threads to execute at that time. It may not start thread 1 right away because all cores already have higher priority threads running, it may preempt thread 2 because thread 1 has a higher dynamic priority, or it can preempt another thread running on a different core by issuing hardware interrupts to another using its interprocessor communication driver. The timer interrupt and the "quantum" thing are essentially irrelevant to your scenario.
Try not to get hung up on the "quantum" concept (that's a silly name because "quanta" are supposed to be indivisible, and threads rarely execute for precise intervals with a timer due to I / O signaling and inter-threading), and think instead of a state-machine whose inputs are hardware interrupts and system calls, and output is a set of threads running on cores. The hardware timer interrupt is just one such input that can change the set of running threads.
source to share