Got asked an interesting question by @matt77hias about why enkiTS doesn't use std::future in the API and I think my answer might be worth sharing:https://github.com/dougbinks/enkiTS/issues/27 …
-
The current model in enkiTS is that tasks can call other tasks and waiting for tasks will run any available tasks. This means the stack can grow with each dependency, so I'm considering adding explicit dependencies.
In my experience with tasks, having Wait assist on the queue is a great way to cause deadlocks. I basically abolished Wait from my task library and put an explicit “AssistOnQueue()” function. Usage of it is considered code smell, but valid rarely.
-
-
What do you mean with "wait assist"? (I am not that familiar with the parallel programming slang) :P
-
When the implementation of Wait() is to keep busy working on other tasks, it is assisting on the work queue while waiting. But waiting and just sleep-looping is equally bad. IMO, avoiding waits at all cost is worth the effort. This is what makes continuations worthwhile.
- Näytä vastaukset
Uusi keskustelu -
-
-
The only way the wait in enkiTS should cause a deadlock is if you have two tasks waiting on each other. This is a programming error which would easily be found since the program would always deadlock.
-
Not quite. If you have 4 threads, it's likely that another thread calls wait() and picks up the dependent task, safely making sure that the originally waiting task doesn't deadlock. This is also why I always test on 1 thread in addition to coreCount threads.
- Näytä vastaukset
Uusi keskustelu -
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.