It can be quantified, the threadpool manager adds an extra thread beyond the optimum when the existing tp threads don’t complete soon enough. It does this twice a second, up to the maximum set by SetMaxThreads(). Which has a very high default value. The optimum is the number of processor cores the machine has available, 4 is typical. Running more threads than available cores can be detrimental due to the context switching overhead.
It does this based on the assumption that these existing threads don’t make progress because they are not executing enough code. In other words, they block on I/O or a lock too much. Such threads therefore don’t use the cores efficiently enough and allowing an extra thread to execute is entirely appropriate to drive up processor usage and get more work done.
So it is “long running” when the thread takes more than half a second. Keep in mind that this is a very long time, it equals roughly 4 billion processor instructions on a modern desktop class machine. Unless you are running computationally heavy code like calculating the value of pi to a gazillion digits, thus actually executing those 4 billion instructions, a practical thread can only take this long when it does block too often. Which is very common, something like a dbase query is often slow and executed on a worker thread and consumes little cpu.
It is otherwise up to you to verify that the assumption that the threadpool manager will make is accurate. The task should take a long time because it isn’t using the processor efficiently. Task Manager is a simple way to see what the processor cores are doing in your program, albeit that it won’t tell you exactly what code they are executing. You’ll need a unit test to see the thread executing in isolation. The ultimate and only completely accurate way to tell you that using LongRunning was an appropriate choice is to verify that your app indeed gets more work done.