std.parallelism changes done

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

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.