Suspend all dispatching of low-priority work while high priority work is running?

[miketuritzin]

I am struggling with how to do the following with enkiTS, and would appreciate any thoughts!

I want to run a set of low-priority tasks in the background that do not slow down high-priority tasks my app running (and waiting on).
The complexity is that the low-priority tasks hold a lock while they're running that prevents the high-priority tasks from making forward progress. I believe the issue I'm running into is that low-priority tasks will continue to run if the high-priority tasks do not fill the available threads. (And they'll slow down the high priority task by holding the lock.)

Is there a way in enkiTS to suspend all dispatching of low-priority work while high priority work is running? It's okay to let already-running low-priority tasks to finish - I just don't want to run more of them.

Thanks for enkiTS, btw!

[dougbinks]

One way to do this would be to spawn an IPinnedTask per thread which calls WaitforTask( nullptr, enki::TASK_PRIORITY_HIGH ) or with the high priority task you want to run as the task to wait on. This will stop any lower priority tasks running whilst allowing other tasks to run.

You may also need to signal the low priority tasks to quit if they are running a loop holding the lock.

I am contemplating adding more easily customizable scheduling to enkiTS which would make this sort of thing easier.

Do let me know if the above isn't clear enough and I'll write a short code sample.

FYI another more complicated solution is to use dependencies rather than locks. I'm investigating explicit resource dependencies for enkiTS but that is a while off.

[miketuritzin]

One way to do this would be to spawn an IPinnedTask per thread which calls WaitforTask( nullptr, enki::TASK_PRIORITY_HIGH ) or with the high priority task you want to run as the task to wait on. This will stop any lower priority tasks running whilst allowing other tasks to run.

Ah, that's a good idea - going to try that. Also look forward to any future additions to scheduling customizability!

FYI another more complicated solution is to use dependencies rather than locks. I'm investigating explicit resource dependencies for enkiTS but that is a while off.

I'm not sure if I would be able to use this for my case, as I'm calling into a 3rd party lib that is managing/acquiring the locks in question.