Ayende @ Rahien

David Miller commented on Message passing concurrency and shared state

Tue, 06 Oct 2009 08:59:00 GMT

The Axum Incubation project looks like an interesting take on message passing, shared state and consumer / producers. [msdn.microsoft.com/en-us/devlabs/dd795202.aspx](http://msdn.microsoft.com/en-us/devlabs/dd795202.aspx)

Ayende Rahien commented on Message passing concurrency and shared state

Mon, 05 Oct 2009 15:20:19 GMT

Mike, The sessions & queries is what I have. The messages are incoming from the profiled application. I take them and turn then into a coherent model and then there is a different thread to manage that. I like the notion of fibers, though, I'll look into it

Mike Rettig commented on Message passing concurrency and shared state

Mon, 05 Oct 2009 14:55:30 GMT

The sessions and queries are rather low level. The granularity probably needs to be coarsened. In any case, I'll take a stab at the messaging interfaces. In Retlang, a fiber per session or a single fiber for all sessions should be used to encapsulate the state of the session(s). Rather than allowing multiple threads to access the sessions, Retlang channels allow threads to submit asynchronous requests to change state or query the sessions. In turn, the session fiber sends asynchronous updates in response to those requests or other state changing events. The channels give you that coherent model for the actors in the system to communicate and exchange state changes. The retlang channels would look something like this: class SessionChannels { // published from the session fiber to all subscribers // (ui, domain, or any other fiber) interested in the state change IChannel

Ayende Rahien commented on Message passing concurrency and shared state

Mon, 05 Oct 2009 09:28:41 GMT

Frank & Mike, Leave the UI aside, given the three messages that I specified, how do you build a coherent model of what is actually happening on the other side?

Frank Quednau commented on Message passing concurrency and shared state

Mon, 05 Oct 2009 07:58:25 GMT

Maybe I don't see the full picture but I can't find any message passing in that post commented by Mike Rettig...I can't see that the backend really just sends messages to the UI. If that would be the case code close to the UI can then analyze the messages and update relevant View Models accordingly. I would like to have a look at retlang. Mike, do you have Erlang background? That .NET 4.0 stuff which is often termed "LINQ to Events" could also be an interesting programming model for such a problem...once it's in existence, obviously.

Ayende Rahien commented on Message passing concurrency and shared state

Mon, 05 Oct 2009 07:43:32 GMT

Mike, All very well and good, but you are avoiding talking about the actual problem shown in the post

Mike Rettig commented on Message passing concurrency and shared state

Mon, 05 Oct 2009 02:12:28 GMT

Writing concurrent systems without shared state is similar to writing distributed services - think in terms of dto's and service interfaces. The interfaces should be coarse grained and fully encapsulate how the internal state is stored and represented. Tell don't ask. A well designed message based system will include very little if any request/reply (asking for data). Everything should be fire and forget. Avoiding shared state takes discipline in java and c#, but it is worth the effort. It actually isn't difficult once the mindset changes from shared state to messaging. Writing immutable dto's by convention isn't difficult and once committed to messaging, the application can be nicely decomposed into autonomous services. Locking on shared state is a dead end. It cripples design and is unmaintainable. The next generation of languages all have concurrency solutions that don't involve locking. Unless you move on to a new language, IMO the best solution is to adopt a little discipline and use messaging correctly by breaking the habits of old. Mike Rettig Retlang & Jetlang Developer [http://code.google.com/p/retlang/](http://code.google.com/p/retlang/) [http://code.google.com/p/jetlang/](http://code.google.com/p/jetlang/)

Mauricio Scheffer commented on Message passing concurrency and shared state

Mon, 05 Oct 2009 00:13:09 GMT

STM does work in C# but awkwardly so (see comments on [weblogs.asp.net/.../...sactional-memory-and-f.aspx](http://weblogs.asp.net/podwysocki/archive/2008/02/07/software-transactional-memory-and-f.aspx) ). Of course it uses locks in its implementation but the point is that they're abstracted away. Anyway I don't think it's production-ready yet, but it is an interesting model worth investigating nevertheless.

Ayende Rahien commented on Message passing concurrency and shared state

Sun, 04 Oct 2009 23:01:41 GMT

STM doesn't work in C#, and in the end, it would have to rely on locks to make it work. Immutable collections doesn't work, I have to be able to change any part of the data at will

Mauricio Scheffer commented on Message passing concurrency and shared state

Sun, 04 Oct 2009 20:43:05 GMT

STM (Software Transactional Memory) looks like a promising model to manage shared state without locks. There's even an implementation in F# : [cs.hubfs.net/.../4565.aspx](http://cs.hubfs.net/blogs/hell_is_other_languages/archive/2008/01/16/4565.aspx) . @chrido: There are implementations of immutable collections for C#: BclExtras ( [http://code.msdn.microsoft.com/BclExtras](http://code.msdn.microsoft.com/BclExtras) ), functional-dotnet ( [http://code.google.com/p/functional-dotnet/](http://code.google.com/p/functional-dotnet/) ) and probably others.

Ayende Rahien commented on Message passing concurrency and shared state

Sun, 04 Oct 2009 20:38:54 GMT

chirdo, Build the model that can support this, then. I tried, and I couldn't figure out how to do this. That is why I posted this. Try having such a model and updating it in multiple threads.

chrido commented on Message passing concurrency and shared state

Sun, 04 Oct 2009 17:57:30 GMT

i don't get your point, you can have a peristent list which contains persistent lists itself. I assumed that the UI just needs the latest data to display. The UI thread doesn't do any modifications. Modifcations occure when a new session was added or a new query was fired. These modification cause the UI to refresh. => Therefor do this Session.ToArray() inside the Session Thread the thing i want to remove by using a persistent datastructure is the lock in the UI Thread: ...aquireLock() { Session.ToArray()} releaseLock()...

Ayende Rahien commented on Message passing concurrency and shared state

Sun, 04 Oct 2009 17:45:12 GMT

Note that this isn't a single list that you need to track it is a list of lists, and the values in the list change as new data comes in

chrido commented on Message passing concurrency and shared state

Sun, 04 Oct 2009 17:26:45 GMT

something which could have help would be using persistent lists (like in clojure) in .net. so for ex. OnSessionChange the UI gets a snapshot of the current list without the message passing overhead having that would have avoided the lock in the UI-thread. but there will always be some situations where you just need a lock. are there any implementations for immutable, persistent lists in .net around? would be a nice part time project ;-)