|
|
|
|
|
by Arelius
825 days ago
|
|
Awesome, always great to see more task/job libraries... I have used this sort of thing a lot though, and something I often find both essential, and overlooked is you really need something like `cr_task_sync_and_do_work` that isn't just entirely blocking on the current thread. Since as you build systems on this sort of API, you very quickly get bound by threads just stuck waiting on their children jobs. Having said that, I realize that complicates the implementation quite a bit. The most elegant approach I have seen is one where you put tasks on fibers, and when you sync, instead of entering a sync loop, or waiting on a mutex, you instead suspend the fiber in the awaiting job, and put it back on the task queue. This was detailed by Naughty Dog in their Job System talk at GDC: https://www.gdcvault.com/play/1022186/Parallelizing-the-Naug... |
|