On 3/24/2011 9:05 PM, Sönke Ludwig wrote:
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.
Indeed this pattern solves the problem to wait for the completion of a
specific task. It also avoids a huge potential of deadlocks that a
general yield() that does not take a task would have. However, it will
not solve the general problem of one task waiting for another, which
could be in terms of a condition variable or just a mutex that is used
in the middle of the task execution.
Can you elaborate and/or provide an example of the "general" problem?
I'm not quite sure what you're getting at.
Can you elaborate on this? The whole point of executeInNewThread() was
supposed to be that a TaskPool is not needed for simple cases.
Well OK if that is the only purpose to provide a shortcut for (new
Thread(&fun)).start then my suggestion may not make too much sense.
However, I have some doubts that the advantage to have this shortcut
here justifies the functional duplication of core.thread. Is there some
specific use case where you would use a Task object but not a ThreadPool?
executeInNewThread() is useful where you only have a few Tasks, rather
than needing to map a large number of Tasks onto a small number of
threads. Using core.thread here doesn't cut it, because core.thread
doesn't automate passing the function's arguments to the new thread.
Also, I figured out that some of the conditions for @safe tasks can be
relaxed a little if they run in a dedicated thread instead of a TaskPool.
But what I wanted to say is, even if it may be difficult to implement
such thread caching now, putting means to execute a Task in its own
thread now into the ThreadPool allows for such an optimization later (it
could even exist while still keeping Task.executeInNewThread()).
I can't really comment because I still don't understand this very well.
