So I saw this video on Youtube with all these C++ masters on GoingNative 2012 : Interactive panel where everybody could ask the questions.

This is the video I was talking about: GoingNative 2012 - Day 1 - Interactive Panel: The importance of being native

And at time 0:24:00 someone put a very interesting question:

We've been doing concurrent programming for some time using pthreads, using windows threads, and so on and I'm so happy that C++ and C caught up with concurrent programming, but it seems to me like it's already behind by five years or ten years because right now we have we have all these powerful multicores and the programming of these multicores really should not be based on threads, it should be task-based [...] and Microsoft has the PPL library and so on and this is totally not reflecting in the C++ standard. [...] The only thing I'm afraid of is that the standard could be locked into threads and sort of make it very difficult to move to Task-Based Programming...

Now I'm quite new to these concepts and I'm a little confused. What is actually Task-Based Programming. Does this term refer to the same thing that Lock-Free Programming refers to? Are these two equivalent terms or are there any links between them?

  • 1
    I haven't had the opportunity to work with the latest C++ standard, so this could be way off, but is consistent with the concerns in your quote. In my vocabulary a task is equivalent to a process. A process/task has its own memory allocated to it. Different processes can't access another process's memory/data (at least without jumping through hoops). A thread can access memory/data of other threads running in the same process. Thus, in a multicore system processes can be run on separate CPUs with no issues, but threads would need to coordinate with eachother when accessing shared data/memory.
    – Dunk
    May 16 '13 at 17:31
  • 1
    ...thereby creating a need to jump through hoops in a multicore system if the threads are running on different CPUs. This is hard enough to do with a programmer in the loop, it is doubtful that the hardware/compiler will be able to handle the generic case reliably and efficiently.
    – Dunk
    May 16 '13 at 17:35
  • Thanks all for all these nice answers but there still is an unanswered question: Does this term refer to the same thing that Lock-Free Programming refers to? Are these two equivalent terms or are there any links between them? Can anyone explain? Are all these task based libraries built also on top of threads or are there other way they got implemented? Thanks!
    – user91225
    May 17 '13 at 12:37

Microsoft has the "Task Parallel Library," or TPL.

It's a higher-level abstraction over threads, and it's library-based, so I see no reason why something similar could not be built in C++, since the TPL is already thread-based, and it doesn't depend on special features in the language standard for its implementation (although the keywords async and await were added to the C# compiler to make such programming easier).

A Task in the Microsoft ecostructure is more or less equivalent to a Future or a Promise. Basically, it's a non-blocking (asynchronous) function; you call it, it returns control back to you while it executes on a new thread, and then you retrieve the return value at some later time when it becomes available.

The TPL has other facilities like Parallel.For, which allows you to process a loop concurrently, using multiple threads. All of these things could be implemented in C++ as library functions. In fact, such a library has already been written.

As far as I know, the PPL (Parallel Patterns Library for Microsoft C++) doesn't depend on any special language features.

  • One important distinction between a Task and a Thread is that a task doesn't necessarily represent a function being run in another thread. It represents anything that could finish, or generate a value, while not running on the current thread. It can be the result of no thread executing at all if it is not representing CPU bound work. Probably the most common example is async IO. It's not representing when a function ends on another thread; it represents when a particular OS hook fires. Task lets you not care how it is completed and lets you treat it as "any asynchronous operation".
    – Servy
    May 16 '13 at 17:22
  • I can't really show a good example in a comment...grr. I'll see if I can find an old question of mine...
    – Servy
    May 16 '13 at 17:25
  • 1
    @Servy: Right; the completion of an asynchronous operation could be the result of a method callback in response to some external event. May 16 '13 at 17:26
  • Yes, that's one example. It's generally easy to set something up using a TaskCompletionSource. The idea is you create a task then continue executing, and that thread eventually does something that ends up setting the result of the TCS, thus completing the task all without requiring more than one thread to execute.
    – Servy
    May 16 '13 at 17:27

There have been threads-via-blocks libraries for ages in cpp. There's Intel's Thread Building Blocks that is quite good, and then there's similar things like OpenMP that allows you to abstract threading in a 'let the system do it for you' kind of way (this is supported by VC++, you have to set the /openmp flag in your builds)

Microsoft is also working on Casablanca, which might not be a truly generic task library, but is a framework for writing task-based systems (mainly for web app purposes) using something similar to Erlang's actor model

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy