On 3/24/2011 3:00 AM, Sönke Ludwig wrote:
Am 24.03.2011 05:32, schrieb dsimcha:
In addition to improving the documentation, I added
Task.executeInNewThread() to allow Task to be useful without a TaskPool.
(Should this have a less verbose name?)
The threading system I designed for the company I work for uses priority
per task to control which tasks can overtake others. A special priority
is out-of-bands (the name my be debatable), which will guarantee that
the task will run in its own thread so it can safely wait for other
tasks.
This may not be an issue in the std.parallelism design. A TaskPool task
can safely wait on other tasks. What prevents this from causing a
deadlock is that calling yieldForce, spinForce, or waitForce on a task
that has not started executing yet will execute the task immediately in
the thread that tried to force it, regardless of where it is in the queue.
However, those threads that process OOB tasks are also cached in
the thread pool and reused for new OOB tasks. Only if the number of
parallel OOB tasks goes over a specific number, new threads will be
created and destroyed. This can safe quite a bit of time for those tasks.
Unfortunately this is not implementable without a massive overhaul of
TaskPool. There are some baked in assumptions that the number of worker
threads in a pool will not change after the pool's creation.
Furthermore, I'm not sure how worker-local storage would be efficiently
implementable without this restriction.
Both kinds of priority have been very useful and I would suggest to put
at least the executeInNewThread() method into ThreadPool to be later
able to make such an optimization.
Can you elaborate on this? The whole point of executeInNewThread() was
supposed to be that a TaskPool is not needed for simple cases.
