http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Hey Ayende, how about writing concurrent code using the actor model, such as with F#'s agents (http://www.developerfusion.com/article/140677/writing-concurrent-applications-using-f-agents/) instead? What are you thoughts on them? By eradicating the use of shared state altogether and given that actors are thread-safe by default since everything inside an actor is single-threaded there is no need for synchronization. If you need higher throughput then just employ multiple agents in a simple fan-out setup. This model of concurrency is also employed in Erlang and the basis of many highly scalable NoSQL solutions such as CouchBase and Riak. Nowadays, the PostSharp toolkit also has support to help you with actor-based programming in C# too (http://www.sharpcrafters.com/blog/post/Actor-Based-Programming-with-C-50-and-PostSharp-Threading-Toolkit.aspx).http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment6http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment6Sun, 25 Nov 2012 00:06:07 GMTI'd argue that doing any work to make sure there's no shared state in a library *is* multi-threaded (i.e. thread-safe) design.http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment5http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment5Wed, 17 Oct 2012 14:21:08 GMTJames, Absolutely, and it is actually quite elegant. I use similar methods here: http://ayende.com/blog/17409/caching-the-funny-way I discuss those approaches in my next post.http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment4http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment4Tue, 16 Oct 2012 21:26:49 GMTAyende check out ThreadSafeStore: https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json/Utilities/ThreadSafeStore.cs Creating a new dictionary for every change isn't elegant but their is a finite amount of type data to cache so that isn't a problem. Its getto but it is compatible with every version of the .NET Framework and it has yet to break.http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment3http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment3Tue, 16 Oct 2012 20:24:16 GMTDemis, Wait for tomorrow's post, it discuss exactly that.http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment2http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment2Tue, 16 Oct 2012 16:56:26 GMTThere's a difference between not spawning multiple threads in your libraries vs ensuring your library is thread-safe. I agree you generally want to avoid creating threads in your libraries but if you provide static utils that maintains static state you need to make it thread-safe. i.e. ServiceStack's JSON, JSV + CSV Serializers employs aggressive static delegate caching, it maintains the caches statically so the cost of creating delegates is only incurred once. I personally wouldn't want to use a serializer that doesn't do this, paying for start-up costs more than once is not a good perf strategy. I'm sure every many other fast .NET libs that touches reflection does the same thing and there are different strategies to achieve thread-safety: i.e. In ServiceStack.Text we use lock-free code + immutable collections. IMO this post could've been improved if it listed the different strategies to make your code thread-safe... Personally I like to take advantage of static constructors and try to isolate multi-threaded code in as small surface area as possible, e.g. Rather than ensuring a single RedisClient and its socket connection is thread-safe in every API, I pass around a thread-safe Redis Client Factory instead that's used to retrieve non-thread-safe RedisClient connection instances. This confines the multi-threaded code to one spot and allows us to not have to worry about thread-safety in your instance clients.http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment1http://ayende.com/159201/multi-threaded-design-guidelines-for-libraries-part-i#comment1Tue, 16 Oct 2012 16:50:25 GMT