Concurrency and Coordination Runtime | Going Deep

georgioc

Please note the section in John Vert's article where he mentions all the benefits of using IoCompletion ports to simplify handling I/O requests and getting just a handfull of threads to do all the work. The CCR, using one consistent interaction mechanism, the CCR Port, provides a very similar model. You use ports to indicate completion of tasks, and you attach Reissue receivers (using activate) to deal with them. You dont care how many CPUs your system has or how many threads you need. We will do the right thing. The key, in both schemes (NT and CCR) is asynchrony.

g

staceyw
Before C# there was darkness...

"This indeed offers a middle ground. Using iterators and anonymous delegates "

hmm. Nice. Thank you sir. If you ever get time, maybe you could point/post a simple message stream loop server to handle multiple users (i.e. sockets) with open connections and sending/receiving messages in a receive loop for each client. I am missing it, but would seem to still be bound by 1700+- user connections as each active connection would take at least one main thread. Or am I wrong? Thanks much!!!
--
wjs

staceyw
Before C# there was darkness...

CCR have a Blog yet? TIA

georgioc

Staceyw, you will actually be able to service alot more than the number of OS threads in 32 bit systems, if you use asynchronous socket APIs, even from C#. The underlying OS will use overlapped I/O and will not block a thread per connection. Then, the total number of simultaneous requests you can service will not be bound by OS threads. The key ofcourse is to use asynchronous APIs all the way through, so you dont consume a CCR or C# threadpool worker. YOur actuall throughput might not increase btw, but your system will be able to service hundreds of thousands of packets, independent of each other so appear more responsive.

See one of the examples of iterators in this thread or the wiki.We actually have implemented a CCR based transport that does this (but cant post the code, yet Wink , and it uses the C# asynchronous socket calls underneath. We just had to wrap them with CCR ports and simple processes so we did not have to deal with Begin/End.

The CCR, using iterators allows you to get "blocking" behavior so your code does not look like the spaghetti of continuations we find ourselves writing again and again. You can actually encode a while loop , processing packets but with no blocking! One of the examples in the wiki shows a for loop using iterators to encode asyncronous but logically sequentially req/rsp operations. It keeps it all in one routine.

So really what we are doing for you, is allow you to use the asynchronous OS APIs, through a much more readable front end, to get the logical behavior of threads, but without the overhead and limitations.

When threads become super lightweight one day( if ever), then the CCR can use alot more of them and get rid of iterators, but its syntax will not really change. The CCR can have blocking arbiters (join, choice etc)

hope this helps.

georgioc

I updated the wiki with some examples of how you can do value based filtering with the CCR, allowing you to concurrently parse message streams and coordinate among various logic based on just values.

staceyw
Before C# there was darkness...

Any idea when we can play with some bits? TIA

georgioc

we plan to have Beta quality bits available for download around the may/june timeframe.

z33driver

I find CCR extremely interesting and can't wait to get my hands on it.

Is there anything similar out there that we might also want to take a look at, that is downloadable now? Smiley

The scenario I have right now is, I am building a product that uses a lot of multithreading. It is a smart client application that is using the Smart Client Offline Application Block along with a number of other threads handling various tasks like incremental synchronization of data from the offline block, user interface updating, etc. I also have a number of singleton classes that act as gateways into different core functionality. I'm using the lock statement in C# in my singleton classes to control access to public property setters from multiple threads. I'm looking for ways to improve performance in some areas.

One issue I'm working on right now is, there are various bits of user interface information that get updated from multiple threads. I'm using Control.BeginInvoke etc. to manage the user interface updates when some of this data changes (for instance, wireless signal strength, online/offline status, data synchronization status information, etc.). I'm working on solving some cases when it seems there is contention to update the UI on the UI thread and it causes "pauses" that are noticeable when mousing over toolbar icons that hot track for instance (I have a XAML toolbar where the icons "zoom" 50% when moused over).

Are these types of scenarios things that the CCR can help me with?

georgioc

yes UI responsiveness it can definatelly help you with, especially coordination among multiple things , like IO, while keeping the UI going.

The Win32 and Winforms UI model is a bit hard to get right however because of its built in SingleThreadApartment design and various re-entrancy issues. Right now i would recommend you look at the latest PDC talks on concurrency, especially the talk from Jan Gray and Joe Duffy on CLR concurrency best practices. Also look into the background worker CLR 2.0 feature that helps with UI concurrency.