Back in 2012 our Product Development Director Andrew Morgan wrote a utility called “ThreadLocker” for dealing with CPU heavy processes or multithreaded processes that have a nasty tendency to cause sluggish performance or even hangs in shared computing environments.
You can read all about the original concept here. Our good friend and CTP Barry Schiffer also wrote a really good article about the need for a product like ThreadLocker here.
Some history:
In essence, ThreadLocker was a utility for both shared and 1:1 desktop environments. It allowed you to layer in rules for processes that had a history of high or disruptive CPU usage, to protect the other users (in a shared environment) or to protect other running processes and the users interface (explorer.exe) while a large compute job was occurring.
ThreadLocker exploded with popularity and has received well over 100,000 downloads in the last three years. Like ThinKiosk, ThreadLocker is something we regularly here that consultants come across in customer environments and it always surprises us with its uptake and popularity. ThreadLocker has been observed in VDI, SBC and even on standalone workstations with great levels of success.
Moving on:
One of the frustrations we had with ThreadLocker, was that any .NET based language (C#, VB.NET etc.) were never quick enough to be able to add an intelligent aspect to the utility without actually making CPU usage worse by implementing it. ThreadLocker 1.0 relied on static rules and any new processes would have to be observed and added.
Recently David Coombes, ThinScale Technologies CTO and Andrew undertook the side project of redesigning ThreadLocker to run in C++, adding the raw speed we needed to be able to make intelligent decisions based on CPU usage and react in a fraction of a second to a sudden CPU spike. ThreadLocker 2.0 was designed to specifically tackle two issues:
- Processes consuming a large % of CPU and is multithreaded.
- Many buggy or heavy processes, each consuming a core each.
We didn’t want to tackle this with the approach of many others have taken, where they’ll pause and resume threads many times a second creating a “SawTooth” effect on the processes CPU usage. We wanted the processes to run as fast as they need up to a certain threshold and only be restricted when contention is likely.
Having experienced other vendor’s approaches where process priority is dropped, many times this simply does not cut it as a heavy process, even at idle priority, will cause the other users and processes to feel slow and sluggish.
Why is ThreadLocker 2.0 different?
With ThreadLocker 2.0 (Enterprise Edition) you can elect a percentage of your CPU cores that ThreadLocker can use for isolating these processes. When a process violates the ThreadLocking criteria, they are locked into these subset of cores to contend with any other processes that are also ThreadLocked, leaving well behaved processes to be able to take advantage of all cores in system. Once they start to behave again and do so for a certain amount of time, the processes are dropped back into the “wild” unless they decide to misbehave again.
This approach is extremely fast (ThreadLocker consumes less CPU than Microsoft’s own Task Manager) from a processing point of view and also has the benefit of allowing users to multitask with other applications while, for example, Excel hammers the ThreadLocking cores during a calculation.
The end result has been fantastic. ThreadLocker can be installed and up and running in seconds. There is no longer a requirement for static rules and out of the box, all aspects of the logic can be tuned to suit your environment, but more than likely won’t be needed.
Availability
ThreadLocker 2.0 is available from today and can be found at https://www.thinscale.com/products/threadlocker/
Thanks,
The ThinScale Team
