I would like to know more about how the thread sleep resolution works, and what it is tied into beyond simply the resolution of sleep().
I know its defined by the operating system and that on Windows its typically 15ms. I havent been able to confirm this by looking around recently, but I vaguely recall this 15ms is looped by the OS and is ‘global’ to all threads, meaning that rather than 15ms being the minimum time a thread can sleep for, it is rather the maximum of sleep(1). Is that right? Is it the same for all operating systems (beyond the duration)?
I cant think of a situation where this could matter, but will a spurious wakeup of a thread always occur at the action point of this sleep cycle, or can it happen at any time?
On a synchronized block, are the waiting threads effectively sleep(1)-ing and checking the lock at each cycle, or does a thread exiting the block instantly wake up a waiting thread? Is this the same for all operating systems?
When thread is notify()-ed after a wait(), will it be handled in the same way as above while it waits for the lock, or different?
Is there any other time that the 15ms loop is relevant from a performance perspective?
You need to do a little research on multithreaded kernels.
‘will a spurious wakeup of a thread always occur at the action point of this sleep cycle, or can it happen at any time?’
There are no spurious wakeups with sleep() or any kernel synchro object waits on Windows – none at all. Any such tendency has been designed away in the kernel and does not propagate to user threads.
If a thread is sleeping or waiting on some synchronization object like a mutex or semaphore lock, it is not run at all – it is just a dead ‘Thread Descriptor Object’ on a queue in the kernel and thereby all thread-related stuff, data space for stack etc. In the case of a sleep, the TDO is on a ‘delta queue’ of all timing-out threads, ordered by wakeup time, and the OS checks the item at the head of this queue every 15ms. In the case of a timed lock wait, the TDO is on two queues – the timeout queue and a queue owned by the lock. Either the TDO will reach the head of the timer queue and become ready when its interval is up, or another thread will release the lock and make the thread ready. Whichever get there first, wins, and the TDO is removed from the other queue. The newly-ready thread then joins the set of ready threads and, if a core is available or a lower-priority thread can be preempted, the newly ready thread is dispatched onto the core.
So, the ’15ms’ on Windows is ‘shared’ by all the threads. Windows is a desktop OS and 15ms is beyond direct human sense, so 99.9% of all household threads don’t care because they only need large timeouts, are waiting on I/O, are waiting on some inter-thread comms lock or some combination thereof.
‘Is there any other time that the 15ms loop is relevant from a performance perspective?’
Not much. There is a side-effect of the timer reschedule in that, if the set of highest-priority runnable threads is greater than the number of cores available to run them, the set is run in a round-robin fashion because the list of those threads is rotated round. This is only relevant on regularly overloaded machines and most threads only use the timer intervals to time out other blocking system calls.