Other Concurrency Approaches

Other Concurrency Approaches

Microsoft Robotics

Glossary Item Box

Microsoft Robotics Developer StudioSend feedback on this topic

Other Concurrency Approaches

The Concurrency and Coordination Runtime (CCR) can express, with simple helper methods when appropriate, a variety of other concurrency approaches. Examples are:

  1. Asynchronous programming model (APM) in .NET: The "Concurrent Affairs," article has several examples of CCR adapter helpers for managing system libraries with Asynchronous Programming Model (APM) Application Programming Interfaces. The CcrInterop section has examples of to greatly simplify APM code by using the CCR and its iterator support to directly yield to asynchronous I/O, with no delegates or callbacks.
  2. Futures: Futures are expressed by returning a port eagerly from a class, and activating the handlers in parallel. Using a dispatcher queue to execute the code in parallel with the caller and then an OS event to block a public method that waits for the result (assuming a synchronous future pattern). For scheduling future work items the CCR scheduler design naturally implements efficient schemes that utilize CPU processing power when appropriate, using user specified appropriate policy for throttling and load balancing. The dispatcher queues are first in first out but the implementation of the DispatcherQueue class exposes virtual methods to allow derived classes to implement last in first out, random insertion, etc
  3. Promises: Promises are once again expressed in a very similar way to Futures:  A CCR port is the result of a promise, and an error, breaking the promise, is just an item that can be retrieved from the port.
  4. Joins: Join programming has been available in operating systems for quite some time (WaitForMultiple, I/O Completion ports in NT, etc.) and the CCR further extends it with dynamic joins and multiple item receivers
  5. Traditional threading primitives such as reader/writer locks, locks, monitors: The CCR can express threading synchronization primitives through its port and arbiters, instead of explicit locking around shared memory constructs. The problem then becomes one of scheduling and protocol design, instead of protecting shared memory

 

 

© 2012 Microsoft Corporation. All Rights Reserved.

Show:
© 2016 Microsoft