Rick Molloy

Rick Molloy rickmolloy

Niner since 2008


  • Rick Molloy: Actor-based Programming in C++ - Control Flow versus Data Flow

    @AlessandroV - what are you trying to change?  There are several more samples on msdn here: https://msdn.microsoft.com/en-us/library/dd492627.aspx

  • Rick Molloy: Actor-based Programming in C++ - Control Flow versus Data Flow

    @Glen. Thank you I'm glad this was useful.

    @Bernd.  Just confirming in concrt, the scheduler / resource manager control the number of threads. If you have 1000 calls and send 1000 messages to them there will be approximately 4 threads running at once on a 4-core processing those thousand messages until they are completed. You will in fact see more threads, but they are not usually usuall actively processing items, they're kept in reserve in case an API call is made that is considered 'blocking'. 

    'Agents' can hold onto a thread when they don't exit their run method in a short amount of time (as do all tasks), but there only a  few examples online showing folks how to do this.  In reality you may want to have a mix of 'control flow' and 'dataflow' agents in an application, it just depends on what you need.

  • Rick Molloy: Actor-based Programming in C++ - Control Flow versus Data Flow

    @Benjamin - multiple folks contributed to the concise DEFINE_HAS_MEMBER in the example, my original version was more verbose.

    In general I also try to avoid macros but I think there are a few really good use cases for them.  For me they involve things like converting class / variable names to strings (we see this a lot in debugging / tracing) or in cases where you want the name of something in a class (in a macro) to vary but not the structure.

    In C++11 I think template aliases will help with some places where folks are using macros now as will being able to allow constructors to call other constructors, but I don't think it will help in this instance because the preprocessor is converting the type to a string.

    The original DEFINE_HAS_MEMBER is part of the concrt sample pack in connect.h at http://code.msdn.com/concrtextrasAnd">http://code.msdn.com/concrtextras

    And Xiang Fan has a blog post on how to do this without decltype at:



  • Checking In: Rick Molloy - Gone Native

    @niners: it's funny you ask about showing more code as I'm working with Charles to provide some code-heavy content here soon, specifically writing and walking through code and demos, I'll also ensure that what I show is also available to be used (e.g. available in text or for download). 

    I also wanted to say thanks for the constructive feedback; folks here especially Charles listen and respond to the feedback.  I also know what I always want out of feedback is that it is direct and actionable (e.g. tell me what I'm doing well and tell me what you'd like to see done differently), blanket statements just aren't as useful and ultimately aren't as effective at making change.

    So if there's specific things here I mentioned here or somewhere else that you'd like to see let us know and stay tuned.


  • Checking In: Rick Molloy - Gone Native

    Thanks folks & concurring Stephan here.  My preference to capture nothing in a lambda by default isn't about performance it's about correctness.

    @AceHack - a workaround I've seen a lot of folks do in C# is to simply make a copy of the value inside the lambda to avoid a race condition when copy semantics are desired.

    There's also various tricks to improve performance if the copy happens to be expensive, e.g. in native combinable<T> or .NET 4, System.Collections.Concurrent.ConcurrentBag<T> in can be used to help with this.  Also in .NET you can look at the overloads of System.Threading.Tasks.Task which take a state parameter in the constructor.

  • Parallel Programming for C++ Developers: Tasks and ​Continuatio​ns, Part 2 of 2

    @HeavensRevenge - I'm still around; as Charles mentioned, I'm working as a dev these days in the Startup Business Group on the team that is responsible for AvatarKinect. 

    I still stay pretty connected to the PCP team, and its great to see more folks from the team here.

    The team has been discussing tasks and continuations for awhile and I'm glad to see them surfaced in the extras, the video and the book at https://msdn.microsoft.com/en-us/library/gg675934.aspx.

    And just for the record my drink of choice is a double ristretto.

  • Dave Probert: Inside Windows 7 - User Mode Scheduler (UMS)

    How does TPL & PLINQ relate to ConcRT? 

    The easiest distinction between TPL/PLINQ and the Concurrency Runtime (ConcRT) is the target customer; TPL & PLINQ are built on .NET while ConcRT, the Parallel Pattern Library (PPL) and the Asynchronous Agents library are targeted to C++ customers.  All are available in the Visual Studio 2010 CTP.

    Many of the scenarios and use cases between TPL & PPL are very similar particularly at a high level, i.e. both support task parallelism, parallel loops and have well defined cancellation and exception handling support.   The runtimes are different; while TPL and PLINQ are built on top of the CLR and it's threadpool, PPL and Agents are built on the Concurrency Runtime which is a component of the C Runtime that is new to Visual Studio 2010.

    As you've noted, Joe, Steve, myself and the rest of the TPL, PLINQ and ConcRT "folks" are all on the Parallel Computing team, we talk very frequently and are incredibly cognizant about the places where the technologies and APIs have differences; we try to ensure that the usage and semantics are similar wherever possible to minimize the amount of time spent by you (our developers) keeping track of idiosyncrasies that aren’t inherent to the .NET & C++ programming model differences.


  • Expert to Expert: Meijer and ​Chrysanthak​opoulos - Concurrency, Coordination and the CCR

    esoteric, is there something you'd specifically like to hear about wrt to the Concurrency Runtime? I'm assuming you've seen the other posts here talking about it.
  • Native Parallelism with the Parallel Patterns Library

    Sorry for the late response on this.  The C++0x library draft is here it has several crucial improvements to help with multi-threading (std::atomic, std::thread, and the locks), but doesn't address fine-grained concurrency in the same way that the PPL or the Concurrency Runtime does.  std::thread gives a developer a portable way to start threads (which is wonderful) and the atomics library and locks give folks a portable way to add thread safety and compare and swap operations, but the PPL provides a task abstraction and algorithms on top of it (similar to the STL algorithms) for describing potential concurrency in an application.  Specifically, I can build up generic 'algorithms' like those in the STL, for_each, accumulate, sort, transform and if as a developer I can guarantee that they won't be modified while being iterated upon (or provide safety), I can use the task_group and task_handles to implement versions of those algorithms that can be run in parallel. 

    As far as getting access to ppl.h, check the blog at https://blogs.msdn.com/nativeconcurrency there is some content on the PPL, links to the CTP and links to the forums.

    The helper function I showed make_task is not critical, it's a nicety.  task_handle is a template helper class and we need to specify a type for a functor.  I could use a std::function as the type, but again here this is binding it to a particular type, when the type of a lambda is intentionally anonymous, the helper function just makes it a little easier to express, particularly when the lambda is declared inside the constructor.

    These are all syntactically correct (though compiled in this form)...

    auto lambda1([](){  cout << " hello world from a task! " << endl';});

    task_handle<function<void(void)>> task1(lambda1);
    auto task2(make_task(lambda1));
    task_handle<decltype(lambda1)> task2;

    I can then schedule any of these with a structured_task_group or a task_group.


    structured_task_group tg;

    task_group tg;

    structured_task_group is lighter weight and more efficient, but really for structured, nested or recursive scenarios (like building loops or algorithms), the task_group is more general purpose, the run and wait methods are threadsafe so can be use for unstructured parallelism, and work can be scheduled on it on multiple threads for example, or it can be waited on a separate thread than it was started on.

  • Native Parallelism with the Parallel Patterns Library

    I've posted links to the CTP at https://blogs.msdn.com/nativeconcurrency/.  Most of what I was doing on the fly is supported in the CTP.

     I think the only tricky thing was the factory method for constructing a task...

    #include <ppl.h>

    //a helper factory mathod for declaring a task
    template <class Func>
    task_handle<Func> make_task(Func& fn){
       return task_handle<Func>(fn);

    void main(){
        // a task_group
        task_group tasks;
        //a task
        auto t = make_task([]{ cout << "hello from a task" << endl;});


  • Native Parallelism with the Parallel Patterns Library

    Glad you enjoyed this technogeist, if you check out the Visual Studio 2010 CTP, you'll see that we're doing significant work concurrently, in both native and in .NET 4.0 to support concurrency.  I'd also encourage you to check out the video on the native focused asynchronous agents which is also in the CTP. 

    Daniel Moth walked through some of the tools that we're working on as well for debugging and I'd encourage you to check that out.


  • Parallel Computing Platform: Asynchronous Agents for Native Code

    A couple of quick responses here.

    Craig, OpenMP can be a quick way to get started today. Particularly if all you are looking to parallelize a for loop (make sure you look at the different scheduling options in particular 'dynamic').

    WRT to UI threads (or other) threads, the runtime doesn't do anything special for threads it doesn't know about which means that the OS will round-robin those threads with the other running threads on the system. There are some knobs in the runtime which we'll probably discuss at a later which can be used to be more particular with the scheduler and UI threasd. I'll also try to get a blog post up in the next week or so to talk about the message blocks in more detail and I'll probably mention communicating with UI threads at that point.

    You asked 'will I get into trouble if I call into legacy code' that used traditional threading constructs like mutexes and critical sections.  If by trouble, you mean things like deadlocks, it is possible to get into trouble, but it's also possible to avoid it.  You would need to take some care to ensure that thisinteraction works well and you aren't creating a deadlock or livelock. 

    The message blocks (particularly call and tranform) mentioned in the video aren't re-entrant, which can be great at helping correctness, so  if I have a pipeline or network built up of a series of transforms there's only going to be one instance of each stage of that pipleine running by-default, though they can all be active at the same time.  However if as you mentioned you're interacting with legacy code in each stage that is taking locks, there may be a chance of deadlock.

    Regardin erlang, this is still a C++ library so the language constraints of C++ will still apply.  However as we mentioned, the message blocks provide a certain degree of ordering and for 'call' and 'transform' they aren't re-entrant. We'll also make copies of messages between blocks.  As I'm sure Niklas mentioned, it's possible to get yourself into trouble if you're passing pointers around, but it's also very possible to avoid a lot of trouble by following best practices.
View All