Question

I wanted to replace the use of normal threads with the task_group class from ppl, but I ran in to the following problem:

• I have a class A with a task_group member,

• create 2 different instances of class A,

• start a task in the task_group of the first A instance (using run),

• after a few seconds start a task in the task_group of the second A instance.

I’m expecting the two tasks to run in parallel but the second task wait for the first task to finish then starts.

This is happening only in my application where the tasks are started from a static function. I did the same scenario in a test application and the tasks are running correctly in parallel.

After spending several hours trying to figure this out I switched back to normal threads.

Does anyone knows why is the concurrency run-time having this behavior, or how I can avoid this?

EDIT
The problem was that it was running on a single core CPU and concurrency run-time looks at throughput. I wonder if microsoft parallel patterns library has the concept of an active object, or something on the lines so that you can specify that the task you are about to lunch is to be executed in parallel with the thread you start it from…

Answer 1

The response can be found here: http://social.msdn.microsoft.com/Forums/en/parallelcppnative/thread/85a84373-4c3d-4862-bff3-9a21ffe82493

For one core machines, this is expected “default” behavior. This can be changed.

By default, number of tasks that can run in parallel = number of hardware threads (num of cores). This improves the raw throughut and efficiency of completing tasks.

However, there are a number of situations where a developer would want many tasks running in parallel, regardless of the number of cores. In this case you have two options:

1. Oversubsribe locally.

In your example above, you would use

void lengthyTask()

{

    Context::Oversubscribe(true)

         ...do a lengthy task  (//OR a blocking task)

    Context::Oversubscribe(false)

}

1. Oversubcribe the scheduler when you start the application.

   SchedulerPolicy policy(1, MaxConcurrency, GetProcessorCount() * 2);

   SetDefaultSchedulerPolicy(policy);