Friday, August 11, 2006

So everyone thinks concurrency will be super important in the years to come. And who would disagree? I recently found this link on the MS Research page. Of course everyone's heard about C Omega, since it was the prototype for the implementation of generics, but did you know about the concurrency lib?

Joins - A Concurrency Library

Comega promised C# programmers a more pleasant world of concurrent programming. Comega had a simple, declarative, and powerful model of concurrency—Join Patterns—applicable both to multithreaded applications and to the orchestration of asynchronous, event-based distributed applications. By exploiting Generics in the Common Language Runtime, we can provide join patterns as a library rather than as a language feature. Offering a library has advantages: The library is language neutral, supporting C#, Visual Basic, and other languages; and the library's join patterns are dynamic, supporting solutions difficult to express with the static join patterns of Comega. The Joins library is efficient and has a simple interface that makes it easy to translate Comega programs to C#. The installer includes a tutorial, documentation, samples, and demos.

8/11/2006 8:58:50 AM (Eastern Standard Time, UTC-05:00)  #    Comments [3]  | 
12/26/2006 8:24:10 AM (Eastern Standard Time, UTC-05:00)
You might be interested in our approach to concurrency and coordination. The primary aim of our technology is to simplify the writing of scaleable, resilient, concurrent/distributed software solutions especially in the case of irregular concurrency. It would appear to us that the majority (if not all) of the other programming tools available seem to target ‘data parallel’ applications. We believe that we are the only provider of a solution that is effective for both regular and irregular concurrency.
We have not implemented a DSL in an ‘application related’ sense as we regard the area of concurrency as the domain we are interested in. It has been our intent to seperate the communications aspects of the solution from the algorithmic/processing aspects of the solution (similar to a co-ordination language). However, we extend the toolset to allow the developer to describe his/her solution using a graphical editor to create something similar to an electronic circuit; this will then be translated to the target language (currently C++). The developer will then be able to write the processing/algorithmic code without any knowledge of the threading/locking/synchronisation issues that writing ‘thread-aware’ code would entail.
We have a runtime which allows the solution to run on a number of OS’es without any changes, and, to run on any hardware topology without any changes (single process on one or more CPU’s (SMP), on shared memory multiprocessors (AMP), and/or heterogeneous networks of these platform types). This ‘hardware independent’ approach facilitates the development of the solution on, say, a desktop PC and allows the choice of hardware to deferred until closer to time of deployment. Hope this interests you from at least from a technological point of view.
9/22/2007 6:42:01 PM (Eastern Standard Time, UTC-05:00)
Nice. Big Thanks!
10/21/2007 8:40:46 PM (Eastern Standard Time, UTC-05:00)
Thanks for stuff.I was looking at the material a long time.
Name
E-mail
Home page

Comment (HTML not allowed)  

Enter the code shown (prevents robots):

Theme design by Jelle Druyts