std.parallelism changes done

[dsimcha]

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.