x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Task queueing best practices

I'm making an in-editor tool which will frequently need to perform large processing tasks. I'd like to do them asynchronously on a separate thread (or threads), to keep the editor as responsive as possible. My assumption is that the task system is best for this, particularly since the beginning and end bits of each process do need to execute on the GameThread.

My questions:

  1. Is there any benefit to creating a separate thread or threads specifically to handle the tasks from my tool? If so, should that be done by creating a new ENamedThread enumerant, or in some other way?

  2. How many worker threads are there to handle tasks which are dispatched for ENamedThreads::AnyThread? Is that number controllable?

  3. Will long-running tasks on GameThread block the editor's responsiveness? Will they block the responsiveness of editor tasks, such as moving objects in the world? Will calling FGraphEvent::DontCompleteUntil from such a task block other tasks on the GameThread until the waited-for event fires?

Product Version: Not Selected
Tags:
more ▼

asked Oct 06 '14 at 10:58 AM in C++ Programming

avatar image

Sneftel
460 20 20 40

(comments are locked)
10|2000 characters needed characters left

1 answer: sort voted first

Hi Sneftel,

The Task Graph system works best for small units of work that finish very quickly. For larger, long running tasks - especially tasks spanning several frames - you're probably better off spawning a separate worker thread using the FRunnableThread API.

The number of task graph threads created depends on a number of factors, most importantly the number of available CPU cores. You can find the current logic for this in the FTaskGraphImplementation constructor. Adding your own task graph thread probably doesn't make much sense, since we already try to spawn the optimal number of threads.

If you schedule a long running task on the GameThread, then yes, it will block the game's/Editor's responsiveness. In fact, no work will be done in the game/Editor until your task has completed, and no user interaction will be possible. This is generally not desirable. If you schedule a long running task on a non-Game thread, then it will, too, block whichever thread it was scheduled to. DontCompleteUntil() will also block the task's completion until some event happened. No other tasks will be executed until the current task has completed.

To sum it up, we do not recommend the task graph for long running tasks. Use a separate OS thread using FRunnableThread to perform the work instead. You can regularly check on the game thread, i.e. in Tick(), whether this thread completed. If you have to regularly execute work on such a separate thread, it may also be a good idea to not recreate the thread each time, but instead leave it running and have it Sleep() when there is no work. You can use a work queue (TQueue) in combination with an event (FEvent) to wake up the thread and perform work. There are some examples of this in the code base, i.e. FMessageRouter::Run().

more ▼

answered Oct 06 '14 at 05:52 PM

avatar image Jorgen.Seland Dec 06 '18 at 12:21 PM

DontCompleteUntil() will also block the task's completion until some event happened. No other tasks will be executed until the current task has completed.

Is this still valid? I am asking because I am using DontCompleteUntil in tasks running on the game thread (UE 4.20), and passing a FGraphEvent to DontCompleteUntil does not seem to stall the thread, even if it takes a while before that event gets DispatchSubsequents called on it.

(comments are locked)
10|2000 characters needed characters left
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question