AddTaskSetToPipe stalls main thread

[leethomason]

This was covered in #38, but I don't see how to accomplish it. When submitting ~20 tasks on an 8 thread machine, AddTestSetToPipe will stall the main thread, consistent with its documentation:

        // Adds the TaskSet to pipe and returns if the pipe is not full.
        // If the pipe is full, pTaskSet is run.
        // should only be called from main thread, or within a task
        ENKITS_API void            AddTaskSetToPipe( ITaskSet* pTaskSet_ );

I need the main thread to never stall, and AddTastkSetToPipe() to always return immediately. I feel like there's probably a simple solution to this (as you imply in #38) but I don't see it yet.

[dougbinks]

Normally adding ~20 tasks via AddTestSetToPipe should not stall the main thread. However f you keep submitting work faster than it is completed eventually the pipe on the main thread can fill up.

A solution to this is to submit a single task from the main thread which then submits the tasks - enkiTS can submit tasks from any of it's tasking threads and also from any external task thread (see example ExternalTaskThread.cpp).

For example you can submit a task with an array (or vector in C++ term) of tasks to submit.

[leethomason]

Interesting - thanks for the quick response. That will work, if a little awkward. Maybe consider this a feature request for a "neverStallMainThread" flag.
It's a very nice task library - thanks for providing it!

[dougbinks]

Thanks!

I've been considering something like a neverStallMainThread flag, however this isn't simple as enkiTS doesn't allocate, so an infinite multithread safe task pipe will require extra memory for all tasks along with some added overhead for all tasking threads.

For now I advocate developers submit lots of tasks via another task - that way only developers who need this pay for the added complexity and overhead. I should add some information to the documentation and perhaps a sample to show how to do this.

[leethomason]

I certainly like that enkiTS has a clear designed that can be reasoned about, and I like that it doesn't allocate. An example would be appreciated, but that may be completely sufficient.

[cstamford]

@dougbinks Correct me if I am wrong, but let's say:

(Task Spawner = task we schedule that then schedules many tasks inside it)

• Submit many tasks by Task Spawner 1, such that the pipes are full
• Later, submit many more tasks by Task Spawner 2 while the pipes are still full

Then Task Spawner 2 will still block the main thread because there's no room to queue it - so it will execute, and inside its body will spawn and then execute many other tasks?

This design decision is problematic for me as my engine relies on spawning very many tasks, some of which are long running (20+~ frames) and others that are very short. The only workaround I can see is to spawn a dedicated thread, register it as external, then only queue tasks via that thread. While potentially a little wasteful it does seem like it would work. Do you have any other suggestions?

[dougbinks]

The specific problem you mention in #60 have sounds very much like what I need to do in my own engine. My solution is to set of a small number of tasks, and when they complete set off more, rather than set off a large number. This also means I can prioritize the tasks launched based on the current state (camera position, whether terrain has been modified etc).

It's also worth noting that in your example above, only the pipe for Task Spawner 1 would likely become full. Each task thread has it's own independent task pipes (1 per priority) to which it pushes tasks on the front. Other task threads pull (steal) from the back and then split them up minimally (if m_SetSize>1) and execute.

Task threads pull first from the front of their own tasking pipes, so once they finish the task they start to drain their own pipe until it's empty before stealing more.

Thus Task Spawner 2 would still be able to add tasks to it's own pipe (if there are sufficient threads available).

Another approach to a single launcher task is to have a launcher task set with an array of tasks of size TASK_COUNT (from your example) and m_SetSize=TASK_COUNT , launching 1 task at a time in the range loop and waiting for it to complete before launching the next.

However if you continue to add tasks at a rate faster than they can be processed in the long term you will run out of memory.

Hopefully this helps clear things up - I shall look into documentation and an example in future.