asgardius/virtualx-engine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
virtualx-engine/core/object/worker_thread_pool.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

245 lines
8.9 KiB
C++
Raw Normal View History

Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
/**************************************************************************/
/* worker_thread_pool.h */
/**************************************************************************/
/* This file is part of: */
/* GODOT ENGINE */
/* https://godotengine.org */
/**************************************************************************/
/* Copyright (c) 2014-present Godot Engine contributors (see AUTHORS.md). */
/* Copyright (c) 2007-2014 Juan Linietsky, Ariel Manzur. */
/* */
/* Permission is hereby granted, free of charge, to any person obtaining */
/* a copy of this software and associated documentation files (the */
/* "Software"), to deal in the Software without restriction, including */
/* without limitation the rights to use, copy, modify, merge, publish, */
/* distribute, sublicense, and/or sell copies of the Software, and to */
/* permit persons to whom the Software is furnished to do so, subject to */
/* the following conditions: */
/* */
/* The above copyright notice and this permission notice shall be */
/* included in all copies or substantial portions of the Software. */
/* */
/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, */
/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF */
/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. */
/* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY */
/* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, */
/* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE */
/* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
/**************************************************************************/
#ifndef WORKER_THREAD_POOL_H
#define WORKER_THREAD_POOL_H
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
#include "core/os/condition_variable.h"
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
#include "core/os/memory.h"
#include "core/os/os.h"
#include "core/os/semaphore.h"
#include "core/os/thread.h"
#include "core/templates/local_vector.h"
#include "core/templates/paged_allocator.h"
#include "core/templates/rid.h"
#include "core/templates/safe_refcount.h"
WorkerThreadPool: Avoid deadlocks when CommandQueueMT is involved This commit lets CommandQueueMT play nicely with the WorkerThreadPool to avoid non-progressable situations caused by an interdependence between both. While a command queue is being flushed, it allows the WTP to release its lock while tasks are being awaited so they can make progress in case they need in turn to post to the command queue.
2023-12-29 01:27:17 +01:00
class CommandQueueMT;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
class WorkerThreadPool : public Object {
GDCLASS(WorkerThreadPool, Object)
public:
enum {
INVALID_TASK_ID = -1
};
typedef int64_t TaskID;
typedef int64_t GroupID;
private:
struct Task;
Remove ThreadWorkPool, replace by WorkerThreadPool The former needs to be allocated once per usage. The later is shared for all threads, which is more efficient. It can also be better debugged.
2022-07-23 19:12:41 +02:00
struct BaseTemplateUserdata {
virtual void callback() {}
virtual void callback_indexed(uint32_t p_index) {}
virtual ~BaseTemplateUserdata() {}
};
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
struct Group {
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
GroupID self = -1;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
SafeNumeric<uint32_t> index;
Remove ThreadWorkPool, replace by WorkerThreadPool The former needs to be allocated once per usage. The later is shared for all threads, which is more efficient. It can also be better debugged.
2022-07-23 19:12:41 +02:00
SafeNumeric<uint32_t> completed_index;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
uint32_t max = 0;
Semaphore done_semaphore;
SafeFlag completed;
SafeNumeric<uint32_t> finished;
uint32_t tasks_used = 0;
};
struct Task {
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
TaskID self = -1;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
Callable callable;
void (*native_func)(void *) = nullptr;
void (*native_group_func)(void *, uint32_t) = nullptr;
void *native_func_userdata = nullptr;
String description;
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
Semaphore done_semaphore; // For user threads awaiting.
WorkerThreadPool: Fix yield-over for not-yet-started tasks
2024-04-18 19:05:44 +02:00
bool completed : 1;
bool pending_notify_yield_over : 1;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
Group *group = nullptr;
SelfList<Task> task_elem;
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
uint32_t waiting_pool = 0;
uint32_t waiting_user = 0;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
bool low_priority = false;
Remove ThreadWorkPool, replace by WorkerThreadPool The former needs to be allocated once per usage. The later is shared for all threads, which is more efficient. It can also be better debugged.
2022-07-23 19:12:41 +02:00
BaseTemplateUserdata *template_userdata = nullptr;
Avoid multiple possibilites of deadlock in resource loading
2023-05-17 00:00:45 +02:00
int pool_thread_index = -1;
Remove ThreadWorkPool, replace by WorkerThreadPool The former needs to be allocated once per usage. The later is shared for all threads, which is more efficient. It can also be better debugged.
2022-07-23 19:12:41 +02:00
void free_template_userdata();
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
Task() :
WorkerThreadPool: Fix yield-over for not-yet-started tasks
2024-04-18 19:05:44 +02:00
completed(false),
pending_notify_yield_over(false),
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
task_elem(this) {}
};
WorkerThreadPool: Avoid most runtime allocations Just a little optimization. **NOTE:** With `RID_Owner` we could replace each pair of `PagedAllocator` and `HashMap`-of-ids-to-pointers. However, that would force us to expose `RID` as the task/group id, instead of `int`, which would break the API. Too bad. Let's wait until Godot 5.0.
2023-12-28 19:31:28 +01:00
static const uint32_t TASKS_PAGE_SIZE = 1024;
static const uint32_t GROUPS_PAGE_SIZE = 256;
PagedAllocator<Task, false, TASKS_PAGE_SIZE> task_allocator;
PagedAllocator<Group, false, GROUPS_PAGE_SIZE> group_allocator;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
SelfList<Task>::List low_priority_task_queue;
SelfList<Task>::List task_queue;
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
BinaryMutex task_mutex;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
struct ThreadData {
WorkerThreadPool: Support daemon-like tasks (via yield semantics)
2024-04-09 17:26:45 +02:00
static Task *const YIELDING; // Too bad constexpr doesn't work here.
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
uint32_t index = 0;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
Thread thread;
WorkerThreadPool: Support daemon-like tasks (via yield semantics)
2024-04-09 17:26:45 +02:00
bool ready_for_scripting : 1;
bool signaled : 1;
bool yield_is_over : 1;
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
Task *current_task = nullptr;
WorkerThreadPool: Support daemon-like tasks (via yield semantics)
2024-04-09 17:26:45 +02:00
Task *awaited_task = nullptr; // Null if not awaiting the condition variable, or special value (YIELDING).
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
ConditionVariable cond_var;
WorkerThreadPool: Support daemon-like tasks (via yield semantics)
2024-04-09 17:26:45 +02:00
ThreadData() :
ready_for_scripting(false),
signaled(false),
yield_is_over(false) {}
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
};
TightLocalVector<ThreadData> threads;
Fix multiple issues in WorkerThreadPool - Fix project settings being ignored. - Made usages of `native_thread_allocator` thread-safe. - Remove redundant thread-safety from `low_priority_threads_used`, `exit_threads`. - Fix deadlock due to unintended extra lock of `task_mutex`.
2023-05-11 12:24:59 +02:00
bool exit_threads = false;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
HashMap<Thread::ID, int> thread_ids;
WorkerThreadPool: Avoid most runtime allocations Just a little optimization. **NOTE:** With `RID_Owner` we could replace each pair of `PagedAllocator` and `HashMap`-of-ids-to-pointers. However, that would force us to expose `RID` as the task/group id, instead of `int`, which would break the API. Too bad. Let's wait until Godot 5.0.
2023-12-28 19:31:28 +01:00
HashMap<
TaskID,
Task *,
HashMapHasherDefault,
HashMapComparatorDefault<TaskID>,
PagedAllocator<HashMapElement<TaskID, Task *>, false, TASKS_PAGE_SIZE>>
tasks;
HashMap<
GroupID,
Group *,
HashMapHasherDefault,
HashMapComparatorDefault<GroupID>,
PagedAllocator<HashMapElement<GroupID, Group *>, false, GROUPS_PAGE_SIZE>>
groups;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
uint32_t max_low_priority_threads = 0;
Fix multiple issues in WorkerThreadPool - Fix project settings being ignored. - Made usages of `native_thread_allocator` thread-safe. - Remove redundant thread-safety from `low_priority_threads_used`, `exit_threads`. - Fix deadlock due to unintended extra lock of `task_mutex`.
2023-05-11 12:24:59 +02:00
uint32_t low_priority_threads_used = 0;
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
uint32_t notify_index = 0; // For rotating across threads, no help distributing load.
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
uint64_t last_task = 1;
static void _thread_function(void *p_user);
void _process_task(Task *task);
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
void _post_tasks_and_unlock(Task **p_tasks, uint32_t p_count, bool p_high_priority);
void _notify_threads(const ThreadData *p_current_thread_data, uint32_t p_process_count, uint32_t p_promote_count);
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
Avoid multiple possibilites of deadlock in resource loading
2023-05-17 00:00:45 +02:00
bool _try_promote_low_priority_task();
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
static WorkerThreadPool *singleton;
WorkerThreadPool: Avoid deadlocks when CommandQueueMT is involved This commit lets CommandQueueMT play nicely with the WorkerThreadPool to avoid non-progressable situations caused by an interdependence between both. While a command queue is being flushed, it allows the WTP to release its lock while tasks are being awaited so they can make progress in case they need in turn to post to the command queue.
2023-12-29 01:27:17 +01:00
static thread_local CommandQueueMT *flushing_cmd_queue;
Remove ThreadWorkPool, replace by WorkerThreadPool The former needs to be allocated once per usage. The later is shared for all threads, which is more efficient. It can also be better debugged.
2022-07-23 19:12:41 +02:00
TaskID _add_task(const Callable &p_callable, void (*p_func)(void *), void *p_userdata, BaseTemplateUserdata *p_template_userdata, bool p_high_priority, const String &p_description);
GroupID _add_group_task(const Callable &p_callable, void (*p_func)(void *, uint32_t), void *p_userdata, BaseTemplateUserdata *p_template_userdata, int p_elements, int p_tasks, bool p_high_priority, const String &p_description);
template <typename C, typename M, typename U>
struct TaskUserData : public BaseTemplateUserdata {
C *instance;
M method;
U userdata;
virtual void callback() override {
(instance->*method)(userdata);
}
};
template <typename C, typename M, typename U>
struct GroupUserData : public BaseTemplateUserdata {
C *instance;
M method;
U userdata;
virtual void callback_indexed(uint32_t p_index) override {
(instance->*method)(p_index, userdata);
}
};
WorkerThreadPool: Support daemon-like tasks (via yield semantics)
2024-04-09 17:26:45 +02:00
void _wait_collaboratively(ThreadData *p_caller_pool_thread, Task *p_task);
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
protected:
static void _bind_methods();
public:
Remove ThreadWorkPool, replace by WorkerThreadPool The former needs to be allocated once per usage. The later is shared for all threads, which is more efficient. It can also be better debugged.
2022-07-23 19:12:41 +02:00
template <typename C, typename M, typename U>
TaskID add_template_task(C *p_instance, M p_method, U p_userdata, bool p_high_priority = false, const String &p_description = String()) {
typedef TaskUserData<C, M, U> TUD;
TUD *ud = memnew(TUD);
ud->instance = p_instance;
ud->method = p_method;
ud->userdata = p_userdata;
return _add_task(Callable(), nullptr, nullptr, ud, p_high_priority, p_description);
}
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
TaskID add_native_task(void (*p_func)(void *), void *p_userdata, bool p_high_priority = false, const String &p_description = String());
TaskID add_task(const Callable &p_action, bool p_high_priority = false, const String &p_description = String());
bool is_task_completed(TaskID p_task_id) const;
Avoid multiple possibilites of deadlock in resource loading
2023-05-17 00:00:45 +02:00
Error wait_for_task_completion(TaskID p_task_id);
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
WorkerThreadPool: Support daemon-like tasks (via yield semantics)
2024-04-09 17:26:45 +02:00
void yield();
void notify_yield_over(TaskID p_task_id);
Remove ThreadWorkPool, replace by WorkerThreadPool The former needs to be allocated once per usage. The later is shared for all threads, which is more efficient. It can also be better debugged.
2022-07-23 19:12:41 +02:00
template <typename C, typename M, typename U>
GroupID add_template_group_task(C *p_instance, M p_method, U p_userdata, int p_elements, int p_tasks = -1, bool p_high_priority = false, const String &p_description = String()) {
More codespell fixes, do more changes from previous ignore list
2023-02-01 10:49:05 +01:00
typedef GroupUserData<C, M, U> GroupUD;
GroupUD *ud = memnew(GroupUD);
Remove ThreadWorkPool, replace by WorkerThreadPool The former needs to be allocated once per usage. The later is shared for all threads, which is more efficient. It can also be better debugged.
2022-07-23 19:12:41 +02:00
ud->instance = p_instance;
ud->method = p_method;
ud->userdata = p_userdata;
return _add_group_task(Callable(), nullptr, nullptr, ud, p_elements, p_tasks, p_high_priority, p_description);
}
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
GroupID add_native_group_task(void (*p_func)(void *, uint32_t), void *p_userdata, int p_elements, int p_tasks = -1, bool p_high_priority = false, const String &p_description = String());
GroupID add_group_task(const Callable &p_action, int p_elements, int p_tasks = -1, bool p_high_priority = false, const String &p_description = String());
Remove ThreadWorkPool, replace by WorkerThreadPool The former needs to be allocated once per usage. The later is shared for all threads, which is more efficient. It can also be better debugged.
2022-07-23 19:12:41 +02:00
uint32_t get_group_processed_element_count(GroupID p_group) const;
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
bool is_group_task_completed(GroupID p_group) const;
void wait_for_group_task_completion(GroupID p_group);
_FORCE_INLINE_ int get_thread_count() const { return threads.size(); }
static WorkerThreadPool *get_singleton() { return singleton; }
Add WorkerThreadPool::get_thread_index()
2023-05-23 11:05:32 +02:00
static int get_thread_index();
WorkerThreadPool: Avoid deadlocks when CommandQueueMT is involved This commit lets CommandQueueMT play nicely with the WorkerThreadPool to avoid non-progressable situations caused by an interdependence between both. While a command queue is being flushed, it allows the WTP to release its lock while tasks are being awaited so they can make progress in case they need in turn to post to the command queue.
2023-12-29 01:27:17 +01:00
static void thread_enter_command_queue_mt_flush(CommandQueueMT *p_queue);
static void thread_exit_command_queue_mt_flush();
WorkerThreadPool: Overhaul scheduling and synchronization This commits rewrites the sync logic in a way that the `use_system_threads_for_low_priority_tasks` setting, which was added due to the lack of a cross-platform wait-for-multiple-objects functionality, can be removed (it's as if it was effectively hardcoded to `false`). With the new implementation, we have the best of both worlds: threads don't have to poll, plus no bespoke threads are used. In addition, regarding deadlock prevention, since not every possible case of wait-deadlock could be avoided, this commits removes the current best-effort avoidance mechanisms and keeps only a simple, pessimistic way of detection. It turns out that the only current user of deadlock prevention, ResourceLoader, works fine with it and so every possible situation in resource loading is now properly handled, with no possibilities of deadlocking. There's a comment in the code with further details. Lastly, a potential for load tasks never being awaited/disposed is cleared.
2024-01-05 17:39:26 +01:00
void init(int p_thread_count = -1, float p_low_priority_task_ratio = 0.3);
Implement a Worker ThreadPool This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks that can be run on threads (and then waited for). It satisfies the following use cases: * HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads. * Thread spawning is slow in general, so reusing threads is faster anyway. * This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks. After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
2022-07-18 12:09:19 +02:00
void finish();
WorkerThreadPool();
~WorkerThreadPool();
};
#endif // WORKER_THREAD_POOL_H
Reference in a new issue Copy permalink