std.parallelism changes done

[Sönke Ludwig]

Am 24.03.2011 14:25, schrieb dsimcha:
> 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.

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.

>
> 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.

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?

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()).

Btw. another more advanced thing that is interesting is to use IO 
completion ports to dynamically increase the number of threads in cases 
of contention or IO waits. But this is of course a whole different story 
and I certainly would not expect this to get in at this stage or maybe 
ever. Just wanted to throw that in.