Parallel Programming in Native Code : Parallel Pattern Library

What’s new in Beta 2 for the Concurrency Runtime, Parallel Pattern Library and Asynchronous Agents Library

rickmolloy — Thu, 29 Oct 2009 17:05:03 GMT

Last week Visual Studio 2010 Beta was released for download. Since Beta1, the team has been pretty busy adding enhanced functionality to make you more productive at expressing parallelism in your applications and improving the quality and performance of our runtime and programming models.

Here’s a guide to what’s new in Beta2: we’ve added 2 new concurrent containers, significantly enhanced our online documentation and improved our debug experience by adding better visualizations and more intuitive views in the parallel debug window. We’ve also modified a small number of APIs which you should be aware of if you are using Beta 1.

Concurrent containers – concurrent_queue and concurrent_vector

We’ve alluded more than once to concurrent_queue and concurrent_vector in our videos and live talks, these are finally in the box and with them two new header files concurrent_queue.h and concurrent_vector.h.

concurrent_queue<T> is very similar to std::queue<T> and it offers push, try_pop interfaces and ‘unsafe’ iterators and size accessors (these aren’t threadsafe during concurrent pushes and pops).

concurrent_vector<T> is most similar to a std::vector<T> and it offers a push_back method that is internally synchronized across threads and allows efficient thread safe growth of the vector. Like std::vector, concurrent_vector has random access iterators, but unlike std::vector, the guarantee of contiguous storage is removed and there are no insert and erase methods.

The interfaces to concurrent_queue and concurrent_vector will be incredibly familiar if you are a user of Intel’s Threading Building Blocks (the interfaces are identical), and a very big thank you goes out to their team for their assistance with this.

Here’s a brief example that uses both std::queue and std::vector in a parallel loop:

#include <ppl.h>
#include <concurrent_vector.h>
#include <concurrent_queue.h>
#include <iostream>
using namespace Concurrency;
using namespace std;
int main()
{
    concurrent_vector<int> odds;
    concurrent_queue<int> evens;
    parallel_for(0,100,1,[&odds,&evens](int i){
        if (i%2 == 0)
            evens.push(i);
        else
            odds.push_back(i);
    }); 
    cout << "We expect 100 items: " << evens.unsafe_size() + odds.size() << endl;
}

Debugging enhancements in Beta2

VS 2010 Beta 2 also now includes significant enhancements for parallel debugging. The locals window now includes visualizers for all first class objects in the PPL, the Agents Library so now when you a look at an instance of a concurrent_queue or an ubounded_buffer in the locals window they both look a lot like a std::queue instead of exposing implementation details. The Parallel Tasks and Parallel Stacks windows have also been enhanced; in addition to those videos, try the C++ code in the MSDN walkthrough and Daniel Moth’s blog. Finally, like the rest of the C Runtime, we’ve made our source code for the Concurrency Runtime available as part of the install, so if you need to debug deeper or really want to see how things work internally, you can now.

Documentation updated with more How To’s and walkthroughs

Our offline and online documentation has been significantly updated for Beta2. We’ve added multiple conceptual topics and expanded our How To topics significantly to include information not just on PPL and the Agents Library but on the underlying Concurrency Runtime and how to manage and use scheduler instances. Any feedback on these topics is greatly appreciated.

API updates to task_group and agent

For Beta 2, we’ve made a very small number of API updates to our task_group, structured_task_group and to our agent classes. The change to the agent is simple describe, we’ve simplified the state management and removed the parameter for the agent::done method, it’s sufficient to call this->done() instead of this->done(agent_done).

The change to task_group and structured_task_group is additive, we’ve added the method run_and_wait which takes a functor and runs it inline on the current thread or task. This offers the major benefit of being able to compose tasks and nest their cancellation. One of the easiest ways to see this in action is through implementing a parallel search algorithm, like a parallel version of the new C++0x library function ‘all_of’:

template<class InIt,class Pr>

inline bool parallel_all_of(InIt first, InIt last, Pr pred)
{

   typedef iterator_traits<InIt>::value_type Item_type;

   //create a structured task group
   structured_task_group tasks;

   auto for_each_predicate = [&pred,&tasks](const Item_type& cur){

   if (!pred(cur))
      tasks.cancel();
   };

   auto task = make_task([&](){
      parallel_for_each(first,last,for_each_predicate);
   });

   return tasks.run_and_wait(task) != canceled;
}

Here we are placing a call to parallel_for_each inside of a structured_task_group and cancelling the work when the predicate is not true. This has the effect of cancelling all nested tasks in the structured_task_group, potentially saving work if the predicate is long running and expensive to compute. We can use this in our example above like this (but don’t expect to see significant speedups over std::all_of for this example):

if (parallel_all_of(odds.begin(),odds.end(),[](int i){return i % 2;}))
    cout << "success!" << endl;

So try Beta 2 if you haven’t already

That’s about it for now, so download VS 2010 Beta 2 if you haven’t already and if you’re at PDC or TechEd Europe next month stop by our booth or come to one our talks.

-Rick

Synchronization with the Concurrency Runtime - Part 3

vinodsu — Thu, 04 Jun 2009 23:51:00 GMT

In my previous posts, I addressed the motivation behind using concurrency runtime’s synchronization primitives and also introduced Critical Section and reader writer lock. In this blog, I will cover concurrency runtime’s event.

Event

This is a bi-state type class which, unlike Critical Section or Reader Writer Lock, does not protect access to shared data. Events synchronize flow of execution and use concurrency runtime’s facilities to enable cooperative schedule of work. They behave similar to Win32 manual-reset event. The main difference between the concurrency runtime’s event and Win32 event is that the concurrency runtime’s event are designed to cooperatively yield to other cooperative tasks in the runtime when blocked in addition to preempting whereas Win32 events are, by design purely pre-emptive in nature.

Example:

This example enables the scheduler to create two threads and then calls DemoEvent function that takes event class and a Win32 manual-reset event class as template parameters. The Demo function first creates several tasks that simulate some work and then wait for a shared event to become signaled.

Special thanks to Rick Molloy for sharing this example.

// event.cpp : Defines the entry point for the console application.

// compile with: /EHsc

#include <windows.h>

#include <concrt.h>

#include <concrtrm.h>

#include <ppl.h>

using namespace Concurrency;

using namespace std;

class WindowsEvent

{

HANDLE m_event;

public:

WindowsEvent()

:m_event(CreateEvent(NULL,TRUE,FALSE,TEXT("WindowsEvent")))

{

}

~WindowsEvent()

{

CloseHandle(m_event);

}

void set()

{

SetEvent(m_event);

}

void wait(int count = INFINITE)

{

WaitForSingleObject(m_event,count);

}

};

template<class EventClass>

void DemoEvent()

{

EventClass e;

LONG volatile taskCtr = 0;

//create a taskgroup and schedule multiple copies of the task

task_group tg;

for(int i = 0;i < 8; ++i)

tg.run([&e, &taskCtr]{

//Simulate some work

Sleep(100);

printf_s("\tTask %d waiting for the event\n", InterlockedIncrement(&taskCtr));

e.wait();

});

Sleep(1000);

printf_s(" Setting the event\n");

//Set the event

e.set();

//wait for the tasks

tg.wait();

}

void main ()

{

// Create a scheduler that uses two threads.

CurrentScheduler::Create(SchedulerPolicy(2, MinConcurrency, 2, MaxConcurrency, 2));

printf_s("Cooperative Event\n");

DemoEvent<event>();

printf_s("Windows Event\n");

DemoEvent<WindowsEvent>();

}

Sample Output:

Cooperative Event

Task 1 waiting for the event

Task 2 waiting for the event

Task 3 waiting for the event

Task 4 waiting for the event

Task 5 waiting for the event

Setting the event

Windows Event

Task 1 waiting for the event

Task 2 waiting for the event

Setting the event

Task 3 waiting for the event

Task 4 waiting for the event

Task 5 waiting for the event

We observe that when using cooperative event, we execute all 5 tasks, each task when waiting on the event that is not set, cooperatively yields so that another task can be scheduled and run in the thread’s quantum. When using windows event, we observe that the 2 tasks scheduled block the thread until the event is set.

Samples posted for the Parallel Pattern Library and Concurrency Runtime

rickmolloy — Wed, 03 Jun 2009 00:40:00 GMT

Following the release of Visual Studio 2010, we've just published a set of sample applications for using the Parallel Pattern Library, the Agents Library and the Concurrency Runtime on code gallery. These supplement the documentation and samples provided on msdn for Beta1.

The samples include using task parallelism with PPL, a few based examples of using the Agents Library (Dining Philosophers, an example using choice) and a find in files example (which will be blogged about here in the next day or so). There are also some examples of using the Concurrency Runtime itself, a simple event based application demonstrating cooperative blocking and UMS threads and a task based example (fibonacci) which shows the Concurrent Suballocator.

As always your feedback here or in the forums is welcome.

-Rick

What's new in the Concurrency Runtime and the Parallel Patterns and Asynchronous Agents Libraries

rickmolloy — Thu, 21 May 2009 23:23:00 GMT

Visual Studio 2010 Beta1 has been released, and it is a full install version. The team has been busy, busy busy since the CTP release last fall to deliver most of the APIs and objects we’ve blogged about here into Beta1. So I wanted to take a moment to summarize what’s new in the Beta for the Parallel Pattern Library, the Asynchronous Agents Library and the Concurrency Runtime.

You can find the official reference documentation and walkthroughs in the MSDN Library here.

What’s new in the Parallel Patterns Library

The Parallel Patterns Library (PPL) provides an imperative programming model that promotes scalability and ease-of-use for developing concurrent applications. In general the library’s surface area remains largely unchanged, with a few high impact additions. You will also find it more stable, more robust, faster, and more scalable – lots of goodness!

Added support for exception handling in task_group.
The new is_current_task_group_canceling API helps query cancellation status.
The combinable<T> object has been added for helping avoid races on reductions and accumulations.
We’ve made significant performance improvements to our parallel loops: parallel_for, parallel_for_each and parallel_invoke
critical_section and reader_writer, the cooperative synchronization primitives that we blogged about recently, are now in.
We’ve also included a manual reset event called Concurrency::event.

What’s new in the Asynchronous Agents Library

The Asynchronous Agents Library (or just Agents Library) provides a programming model that enables you to increase the robustness of concurrency-enabled application development. The Agents Library is a C++ template library that promotes an actor-based programming model and in-process message passing for fine-grained dataflow and pipelining tasks. The Agents Library builds upon the scheduling and resource management components of the Concurrency Runtime.

Here’s a summary of what’s we’ve added and revised in the Agents library:

Added the choice, join and multitype_join message blocks to allow users to wait on a set of messages; choice waits for any message, join waits for all messages of a single type, and multitype_join waits for all messages and allows for multiple different types.
Renamed the transform message block to transformer (we didn’t want Concurrency::transformer to conflict with std::transform)
Added functor support to the pipeline message blocks call and transformer
Building custom message blocks is now easier due to some refactoring.

What’s new and improved in the Concurrency Runtime itself

The underlying Concurrency Runtime has undergone significant feature improvements and performance enhancements, many of which we have been discussing already on this blog. These changes will have improvements to everything built on top of the runtime, including the Parallel Patterns Library and the Agents Library.

Added support for User Mode Scheduled Threads on Windows 7 RC (see our blog posts on the Concurrency Runtime’s support and go deep on Win7 UMS)
Revised and simplified scheduler policies and APIs for constructing schedulers.
Added dynamic resource management for load balancing between multiple scheduler instances.
Further improved load balancing by applying the hill climbing technique to thread injection.
Added the concurrent sub-allocator for high performance allocations and frees on multiple threads

Call to Action

Download and install Microsoft Visual Studio 2010 Beta 1 today. Impress your friends and coworkers by being among the first to learn and use our libraries. Provide early and critical feedback on our forum that will shape the way that these libraries are ultimately released.

See this blog post on the value of your feedback: On Achieving Perfection –or– Why We Love Your Feedback (and Why You Can Love Giving It).

Happy coding!

Synchronization with the Concurrency Runtime - Part 2

vinodsu — Thu, 14 May 2009 21:46:00 GMT

In my previous post, I addressed the motivation behind using concurrency runtime’s synchronization primitives and also introduced Critical Section. In this blog, I will cover concurrency runtime’s reader writer lock.

Reader Writer Lock

This class enables multiple threads to read from a shared resource at the same time but only allows one thread to write to it at a time. They share many characteristics with concurrency runtime’s critical section, reader writer locks are non-reentrant and block cooperatively. The reader writer lock resembles the Win32 Slim reader/writer locks (SRWLock). Reader writer lock performs better than critical section in read-mostly environments.

Similarity to Win32 Slim reader/writer locks:

- Can be used only by threads of a single process.

- The reader writer lock can be owned by multiple reader-threads or only one writer thread at any time.

- Non-reentrant.

- Do not support upgrades or downgrades.

Differences with Win32 Slim reader/writer locks:

- The concurrency runtime’s reader writer lock object guarantees that the order of exclusive (writer) lock-ownership is on a first-come, first-serve basis.

- There is no need to explicitly call Initialization of resources before use of the concurrency runtime’s reader writer lock and release after the use of the reader writer lock.

- Cannot specify spin count for the concurrency runtime’s reader writer lock object.

- The concurrency runtime’s reader writer lock enforces cooperative blocking where they yield to other cooperative tasks in the runtime when blocked.

- The concurrency runtime’s reader writer locks give writer preference over readers; i.e. if there are readers and writer(s) simultaneously waiting for the lock, the lock would be handed over to the first writer in queue.

- Exceptions are thrown by the concurrency runtime’s reader writer lock object; on recursive calls, or if unlock is called when the lock is not held, or if a lock is destroyed when being held.

Example:

Given below is a code sample illustrating reader_writer_lock using 4 readers and 1 writer. The readers output the value of the shared data and the writer updates the value of the shared data and outputs it.

// reader_writer_lock.cpp

// compile with: /EHsc

#include <ppl.h>

#include <stdio.h>

#include <windows.h>

using namespace std;

using namespace Concurrency;

//number of iterations each thread performs

static const int NUM_ITERATIONS = 2;

//the shared data that needs protection from race/tearing

static unsigned int sharedData = 0;

//Demonstrates the use of the reader lock

void Reader(reader_writer_lock* pRWLock)

{

for( int i = 0; i < NUM_ITERATIONS; ++i)

{

//use the reader lock

pRWLock->lock_read();

printf_s("Reading %d\n", sharedData);

//Sleep for some time, this is to simulate potential work done while holding the lock

Sleep(100);

//release the lock

pRWLock->unlock();

}

//Demonstrates the use of the writer lock

void Writer(reader_writer_lock* pRWLock)

{

for( int i = 0; i < NUM_ITERATIONS; ++i)

{

//use the writer lock

pRWLock->lock();

printf_s("\tWriting %d\n", ++sharedData);

//Sleep for some time, this is to simulate potential work done while holding the lock

Sleep(100);

//release the lock

pRWLock->unlock();

}

int main()

{

reader_writer_lock rwlock;

//performs reader writer operations in parallel

parallel_invoke(

[&] { Reader(&rwlock); },

[&] { Writer(&rwlock); }

);

return 0;

}

Sample output:

Reading 0

Writing 1

Reading 1

Writing 2

Reading 2

An interesting point to note here is that even though we use 4 readers, we notice that only 3 readers output their value and the lock is taken by the writer. This happens because the lock prefers writers. We do not guarantee the order of task execution but if such a guarantee is required, you could consider using events, which I will cover in the next blog post.

Synchronization with the Concurrency Runtime - Part 1

vinodsu — Wed, 22 Apr 2009 23:21:00 GMT

In a concurrent world multiple entities work together to achieve a common goal. A common way to interact and coordinate is to use shared data. However, shared data must be accessed carefully. This can be achieved through synchronization, primarily using:

i) Blocking methods such as locks and mutexes

ii) Non-blocking methods such as lock-free programming techniques.

I will talk about the synchronization using blocking methods within a process, using constructs provided as part of the concurrency runtime and exposed through the Parallel Pattern Library (PPL). In this blog, I will address the concurrency runtime’s critical section and will cover reader writer lock and events in subsequent blog posts.

For a general picture of the native concurrency runtime, and high level roles of each of its components please refer to this post.

Motivation

Goals of the concurrency runtime’s synchronization primitives:

1. Simple APIs

Unlike their Win32 equivalent, concurrency runtime’s synchronization primitives don’t have C-style initialization and release/destroy type of resource management calls. The exposed interfaces are simple and conform to the C++0x standards and the synchronization objects throw meaningful exceptions on certain illegal operations.

2. Block in a cooperative manner

The synchronization objects are cooperative in nature, in that they yield to other cooperative tasks in the runtime in addition to preempting. For an illustration of this scenario, refer to this post.

Critical Section

This represents a non-reentrant, cooperative mutual exclusion object that uses concurrency runtime’s facilities to enable cooperative scheduling of work when blocked. This class satisfies all Mutex requirements specified in C++0x standards. The concurrency runtime’s critical section provides a C++ façade as compared to its C-styled Win32 equivalent: Windows CRITICAL_SECTION

Similarity to the Win32 CRITICAL_SECTION:

- Can be used only by threads of a single process.

- The critical section object can only be owned by one thread at a time.

Differences with Win32 CRITICAL_SECTION:

- The concurrency runtime’s critical sections are non-recursive. Exceptions are thrown upon recursive calls.

- The concurrency runtime’s critical section object guarantees that threads waiting on a critical section acquire it on a first-come, first-serve basis.

- There is no need to explicitly call Initialization/allocation of resources before use of the concurrency runtime’s critical section and release resources after the use of the critical section.

- Cannot specify spin count for the concurrency runtime’s critical section object.

- The concurrency runtime’s critical section enforces cooperative blocking where they yield to other cooperative tasks in the runtime when blocked.

- Exceptions are thrown by the concurrency runtime’s critical section object; on unlock calls when the lock is not held, or if a lock is destroyed when being held.

Example:

The sample below alternates between printing to standard output from FunctionA and FunctionB.

// critical_section.cpp

// compile with: /EHsc

#include <ppl.h>

#include <stdio.h>

#include <windows.h>

using namespace std;

using namespace Concurrency;

//number of iterations each thread performs

static const int NUM_ITERATIONS = 5;

//Demonstrates use of critical section

void FunctionA(critical_section* pMutex)

{

for( int i = 0; i < NUM_ITERATIONS; ++i)

{

//use exclusive lock

pMutex->lock();

printf_s("A %d\n", i);

//Sleep for some time, this is to simulate potential work done while holding the lock

Sleep(100);

//release exclusive lock

pMutex->unlock();

}

//Demonstrates use of critical section

void FunctionB(critical_section* pMutex)

{

for( int i = 0; i < NUM_ITERATIONS; ++i)

{

//use exclusive lock

pMutex->lock();

printf_s("\tB %d\n", i);

//Sleep for some time, this is to simulate potential work done while holding the lock

Sleep(100);

//release exclusive lock

pMutex->unlock();

}

int main()

{

critical_section mutex;

//call FunctionA and FunctionB in parallel

parallel_invoke(

[&] { FunctionA(&mutex); },

[&] { FunctionB(&mutex); }

);

return 0;

}

Sample output:

Note: There is a possibility that the order may be swapped, where B gets the lock before A; the locks are handed out on a first-come, first-serve basis, it’s a race to try and get the lock at the beginning. One way of guaranteeing consistency is using events.

On Channel9: a chat with members from the Visual C++ and Concurrency Runtime teams

rickmolloy — Wed, 14 Jan 2009 04:36:00 GMT

Last week, Don McCrady, Damien Watkins from the C++ team and I sat down with Charles from Channel9 and chatted about the Concurrency Runtime, new C++ work in Visual Studio 2010 and how our teams are working together.

As Charles pointed out, we also touched briefly upon new features in the C++0x standard that haven’t been discussed before.

Here's the link:

http://channel9.msdn.com/shows/Going+Deep/Parallel-Computing-in-Native-Code-New-Trends-and-Old-Friends/

Enjoy and as always your feedback is very welcome,

Rick

Getting the Visual Studio 2010 CTP to use more than one hardware thread: using Hyper-V and other options

rickmolloy — Wed, 05 Nov 2008 06:36:00 GMT

Last week, we blogged about the Visual Studio 2010 CTP which includes the Concurrency Runtime, the Parallel Pattern Library and the Asynchronous Agents Library which is available as a Virtual PC image. As the Parallel Extensions to .NET team blogged yesterday, this is unfortunate because VPC images only have a single core and this isn't great for building parallel applications.

There's a couple of options to try out the CTP and the projects built with it on something other than a single-threaded VPC image. Note that none of these are officially tested or supported so things may not work as expected.

One option which is straightforward for most C++ projects is to statically link in the Runtime Libraries in your applications and move them to another computer with more than a single CPU to test them.

To do this open the solution explorer pane and right click on your C++ project and select properties. Under the C/C++ ->Code Generation property page under Runtime Library select "Multi-threaded (/MT)" for release builds and "Multi-threaded Debug (/MTd)" for debug builds. Also note that if you're using MFC in your application on the General Property Page you'll need to change the "Use of MFC" setting to something other than "Use MFC in a Shared DLL."

Another option is to convert the Virtual PC image to a Hyper-V image which will allow you to see up to 4 hardware threads if they are available on your system. Grant Holliday has a guide on his blog for doing this.

An advantage to statically linking your application is you can run it at full speed outside of the VPC and install is straightforward; conversely an advantage to converting your VPC image to a Hyper-V image is that you can try the Parallel Debugger windows in the Visual Studio debugger.

As I said neither of these options is supported, but I do hope that they can help you make it easier to explore the Concurrency Runtime, Parallel Pattern Library and Asynchronous Agents Library.

-Rick

Visual Studio 2010 CTP available: Including the Concurrency Runtime, Parallel Pattern Library and Asynchronous Agents Library!

rickmolloy — Wed, 29 Oct 2008 03:09:00 GMT

In his blog post on Monday, Soma mentioned some of the great things happening at PDC 2008 and also announced the Visual Studio 2010 CTP. We’re very excited to announce that this CTP includes the Concurrency Runtime, the Parallel Pattern and Asynchronous Agents Libraries for C++ developers that we’ve mentioned here and on channel9 previously.

He also announced that the Visual Studio 2010 and .NET 4.0 include the Task Parallel Library, PLINQ and includes parallel profiling and debugging experiences that support both native and managed code.

The CTP is available as a VPC image and is available here:

https://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=9790

Getting started with the PPL and Agents Library: the walkthrough

Once you have the CTP running, getting started is relatively straightforward. Launch the Visual Studio 2010 CTP and click the link to the walkthroughs. There is one provided which shows a very simple example of using the Parallel Pattern Library and the Agents Library.

Here’s a snippet of that walkthrough, where a parallel_for is used to concurrently check a series of numbers for primality and then sends the prime numbers as a message to an agent. The agent in this example is responsible for inserting them into a vector.

What’s important to take away from this example is how the agents functionality (send, receive and the unbounded_buffer) are used in conjunction with the parallel_for to insert data into a std::vector, which isn’t typically threadsafe. We accomplish this by separating the shared state and in this case the computationally expensive work (IsPrime is slow J) from the less expensive insert operation. It’s also interesting to note, that It may be also useful to just leave those messages in the unbounded_buffer since it supports enqueue and dequeue operations, but in this case we’re assuming there is a need for the random access iteration that std::vector provides.

Here’s the virtual ‘run’ method in the derived ConsumerAgent class below which waits for messages being sent to a message block and then inserts them into a std::vector v:

virtual bool run(){

int curValue;

while(true){

curValue = receive(buf_);

//use -1 to signal exit

if (curValue == -1)

break;

v_.push_back(curValue);

};

return true;

};

And here’s the code which iterates over the range of numbers and sends messages for the agent to process. Note that I’m using a C++ lambda for the body of the loop.

std::vector<int> v;

unbounded_buffer<int> intBuf;

ConsumerAgent myAgent(v,intBuf);

myAgent.start();

parallel_for(1,count,1,[&](int i){

if (IsPrime(i))

send(intBuf,i);

});

//use -1 to signal exit

send(intBuf,-1);

myAgent.wait();

printf("Found %d prime numbers in parallel\n",v.size());

The full example is provided in the walkthrough.

What’s in the CTP: Parallel Pattern Library, Asynchronous Agents Library, Concurrency Runtime

The classes and APIs in the Parallel Pattern Library and Asynchronous Agents Library are in the header files ppl.h and agents.h respectively and all of the APIs are currently in the Concurrency namespace. The Concurrency Runtime itself and the load-balancing scheduler are included as binary code and part of msvcr100.dll in the CTP. Here’s a brief list of the header files and major APIs in each one.

ppl.h: includes parallel_for, parallel_for_each, parallel_invoke, task_group and task_handle

agents.h: includes unbounded_buffer<T>, overwrite_buffer<T>, and the send and receive helper methods. call<T> and transform<Input,Output> and the abstract agent class are also included.

concrt.h: includes APIs for interacting with the scheduler. Note that that it isn’t necessary to interact with the scheduler when you use the APIs and classes in ppl.h or agents.h an implicit scheduler will be created on demand.

I’ll try to take some time over the next couple of days to provide a few examples using each of these APIs on this blog and if you’re at the PDC this week, stop by the Parallel Computing Platform Teams’ booth. We’d love to hear from you.

-Rick

Concurrency Runtime on Channel 9

rickmolloy — Thu, 09 Oct 2008 21:46:00 GMT

A few weeks ago several of us from the Parallel Computing Platform sat down with Charles Torre from Channel 9 to discuss the Concurrency Runtime that we've blogged about here. We talk about the motivation of the Concurrency Runtime, how its scheduler and resource manager interact and discuss the C++ programming models built on top of it, the Parallel Pattern Library mentioned here earlier here by Don McCrady and myself and the Asynchronous Agents Library (a concurrent data flow and message passing library) that we haven’t discussed yet but will likely soon.

The video is now available on Channel 9: http://channel9.msdn.com/posts/Charles/The-Concurrency-Runtime-Fine-Grained-Parallelism-for-C/.

We hope you enjoy it, and as always feedback more than welcome and greatly appreciated!

Avoiding Contention using Combinable Objects

dmccrady — Thu, 25 Sep 2008 19:51:00 GMT

When attempting to parallelize an algorithm, programmers are frequently thwarted by the presence of shared state . Any state that can potentially be modified by multiple threads simultaneously during a parallel operation must be synchronized somehow to...(read more)