3 ms·

The trick is how you implement reschedule this thread. What you want in this specific case is to take it off-core long enough for another thread to wake up and

The trick is how you implement reschedule this thread. What you want in this specific case is to take it off-core long enough for another thread to wake up and take the lock. That is far too squishy a goal to be something that you can implement. If you sleep for some number of nanoseconds then you are wasting performance and/or not sleeping long enough. In this particular case the lock was a kernel lock in kernel code so the OS would have to fix this, by making the locks fair (or occasionally fair).

raattgift 8y ago
I've been spoiled by a better OS. :D How about: while work: if (contenders > 1) { reduce_priority; pri_reduced = true } take_lock if (pri_reduced) { unreduce_priority; pri_reduced = false } do_work_quantum drop_lock endwhile (I mean empirically, although an educated guess would do). Of course, if reducing priority is too fast, this likely doesn't help; alternatively it could be too slow and what you get back in system latency is taken away in lowered throughput. That's probably not OK if you don't need the system latency to be low. I wonder if (dramatically, even) reducing the priority of some of the original workload exposing the problem, not just when racing for a lock but when doing the actual work quanta, would help. My thought here is that your email-sending is higher-prirority and will at least push some of the workload out of the way in reasonable time, giving you back some responsiveness. I'm surprised if Windows doesn't offer up a high-throughput/latency-tolerant QOS for threads.
- brucedawson 8y ago
  Priorities don't help. They are only relevant if there are more runnable threads than CPUs. In my case I had lots of spare CPUs so both threads could run, regardless of priority. A QOS does not directly help. The only thing I am aware of that can help is fair locks, or occasionally fair locks, so that the lock is given directly to the waiting thread, instead of being made available to all. I have yet to hear of any other solutions.

raattgift 8y ago

I've been spoiled by a better OS. :D How about: while work: if (contenders > 1) { reduce_priority; pri_reduced = true } take_lock if (pri_reduced) { unreduce_priority; pri_reduced = false } do_work_quantum drop_lock endwhile (I mean empirically, although an educated guess would do). Of course, if reducing priority is too fast, this likely doesn't help; alternatively it could be too slow and what you get back in system latency is taken away in lowered throughput. That's probably not OK if you don't need the system latency to be low. I wonder if (dramatically, even) reducing the priority of some of the original workload exposing the problem, not just when racing for a lock but when doing the actual work quanta, would help. My thought here is that your email-sending is higher-prirority and will at least push some of the workload out of the way in reasonable time, giving you back some responsiveness. I'm surprised if Windows doesn't offer up a high-throughput/latency-tolerant QOS for threads.

brucedawson 8y ago
Priorities don't help. They are only relevant if there are more runnable threads than CPUs. In my case I had lots of spare CPUs so both threads could run, regardless of priority. A QOS does not directly help. The only thing I am aware of that can help is fair locks, or occasionally fair locks, so that the lock is given directly to the waiting thread, instead of being made available to all. I have yet to hear of any other solutions.