3

I am using a simple Concurrency Runtime task_group in Visual Studio 2010 to run a single working thread to separate the work from the GUI thread.

However one of my colleagues told me that I'm using CR wrong: it was designed for parallelizing lightweight tasks with small context and not for separating bulky and I/O-dependent threads from the GUI. He said that he'd taken this from the documentation, but failed to provide any specific links.

So, what are the limitations of Microsoft Concurrency Runtime and to solve what problems I should NOT use it?

Of course CR is not portable, but let's leave it out: I'm talking about situations, when you code compiles, but you get problems nevertheless.

Steed
  • 1,292
  • 1
  • 14
  • 33

2 Answers2

1

The concurrency runtime is a cooperative scheduling infrastructure. If you're not going to take advantage of cooperative scheduling, then you're better off creating threads when you need to, and letting the OS take care of scheduling.

If you are into cooperative scheduling, then there's really no point to wait for an IO operation to complete, because you're blocking a thread which could have otherwise been used for running other tasks, which do not depend on this IO operation to complete. If other tasks depend on the IO task to complete, you can simply make them continuations, and the ConcRT scheduler will make sure to run them when their time comes.

So it's really not about limitations here. It's simply about knowing what you're trying to achieve, and picking the right tool for the job.

Yam Marcovic
  • 7,953
  • 1
  • 28
  • 38
  • Didn't expect an answer after so long, thank you! If I get you right, you can create single threads with CR, but you'll have additional overhead compared to plain system threads. – Steed May 28 '13 at 05:43
  • 1
    That's the thing, it doesn't let you say "create a thread which runs this...". It only lets you say "Given X cores, make sure to always find time to run my tasks... which I will tell you to schedule every now and then". – Yam Marcovic May 28 '13 at 06:10
1

As Yam mentioned, concurrency runtime does not provide the parallel execution guarantee, it just makes a potential possibility, and that is the difference between notions of tasks and threads. If you get your tasks right (not too granular to spend much time on switching between tasks, and not too coarse to always have some work for all the cores - in your case - just one), then the overhead will not be significant, and your program will be ready for running on a multi-core or a multi-processor platform, "future proof" as MSFT people like to say.

Arsen Y.M.
  • 673
  • 1
  • 7
  • 18