jaredpar's WebLog : Immutable

Immutable vs. Mutable Collection Performance

Jared Parsons — Mon, 06 Apr 2009 15:00:00 GMT

One argument I commonly hear against immutable collections is they are slow. I’ve held the opposite belief for some time but shamefully had yet to look at actual numbers on the CLR. Tonight I decided to change that by benchmarking one of my immutable collections against a mutable collection in the BCL. The goal is not to decide the overall best collection but instead to get a sense of how they perform relative to each other in certain scenarios.

For the immutable version, I chose to use ImmutableCollection. This class is a slight variation of Eric Lippert’s Double Ended Queue implementation. The core algorithm is the same but the style was changed to be more inline with other immutable collections I own. For the mutable class I chose to use the ever popular List<T> collection.

I chose to examine the following scenarios that I commonly use with collection style classes.

Adding to the end of the collection
Adding to the front of the collection
Removing from the end of the collection
Removing from the beginning of the collection

Each scenario was run against collections of 100, 1000 and 10000 elements. For each count, the run was executed 1000 times and the total and average time was calculated. The full code for the benchmark is available at the end of this post.

Looking at the data

Now before I get into the results, please assume the usual caveats that come with any benchmark. That is, approach it with a skeptical eye. These scenarios are obviously not something I do exactly in everyday programming (especially removing thousands of elements from the front of List<T>). However they are representative of general operations that I do use. Also I find it interesting to see how the collections perform relative to each other in extreme scenarios.

Most of the results were unsurprising. Remove from end is a very simple operation on a List<T>. It comes down to a bounds check, decrementing an index and updating a couple of internal state variables. Removing the end of an immutable collection requires considerable updating of the internal structure. It ends up being roughly 1 order of magnitude slower. Adding to the end has similar implementation and numbers.

Operations on the front of the list were significantly slower on List<T> than ImmutableCollection for suitably large collections. This is unsurprising given that removal and insertion at the front of a List<T> requires all of the other elements in the underlying array to be shifted up or down. This is a non-trivial operation and is evident in the benchmark.

The most interesting item however, is to look at how each collection scales. In almost all scenarios, ImmutableCollection scaled very closely to the size of the input. That is, an order of magnitude more input resulted in an order of magnitude of more time. List<T> does not have that behavior for all scenarios. Scenarios dealing with the front of the collection saw time rises faster relative to input size. In fact there is a very dramatic jump in both front scenarios between 1000 and 1000 elements. Each case resulted in roughly 2 orders of magnitude more time.

Conclusion

Winner of each category …

Add to End: List<T>
Add to Front: ImmutableCollection<T>
Remove from End: List<T>
Remove from Front: ImmutableCollection<T>

No single benchmark is definitive and this one won’t change that. This benchmark says nothing about the general use of the two classes. However it can provide some insight into these specific scenarios. It also serves as some level of proof that immutable collections can have acceptable performance for these scenarios.

Data

Add to End 100 Elements
       List: Total: 00:00:00.0060473 Average: 00:00:00.0000060
  Immutable: Total: 00:00:00.0267079 Average: 00:00:00.0000267
Add to End 1000 Elements
       List: Total: 00:00:00.0337505 Average: 00:00:00.0000337
  Immutable: Total: 00:00:00.2240444 Average: 00:00:00.0002240
Add to End 10000 Elements
       List: Total: 00:00:00.4266014 Average: 00:00:00.0004266
  Immutable: Total: 00:00:02.6715789 Average: 00:00:00.0026715
Add to Front 100 Elements
       List: Total: 00:00:00.0162186 Average: 00:00:00.0000162
  Immutable: Total: 00:00:00.0213764 Average: 00:00:00.0000213
Add to Front 1000 Elements
       List: Total: 00:00:00.4028523 Average: 00:00:00.0004028
  Immutable: Total: 00:00:00.2055935 Average: 00:00:00.0002055
Add to Front 10000 Elements
       List: Total: 00:00:38.5943722 Average: 00:00:00.0385943
  Immutable: Total: 00:00:02.6212590 Average: 00:00:00.0026212
Remove From End 100 Elements
       List: Total: 00:00:00.0031299 Average: 00:00:00.0000031
  Immutable: Total: 00:00:00.0213737 Average: 00:00:00.0000213
Remove From End 1000 Elements
       List: Total: 00:00:00.0187998 Average: 00:00:00.0000187
  Immutable: Total: 00:00:00.1623739 Average: 00:00:00.0001623
Remove From End 10000 Elements
       List: Total: 00:00:00.1773381 Average: 00:00:00.0001773
  Immutable: Total: 00:00:01.9615781 Average: 00:00:00.0019615
Remove From Front 100 Elements
       List: Total: 00:00:00.0142981 Average: 00:00:00.0000142
  Immutable: Total: 00:00:00.0192679 Average: 00:00:00.0000192
Remove From Front 1000 Elements
       List: Total: 00:00:00.4407993 Average: 00:00:00.0004407
  Immutable: Total: 00:00:00.1879243 Average: 00:00:00.0001879
Remove From Front 10000 Elements
       List: Total: 00:00:39.7832085 Average: 00:00:00.0397832
  Immutable: Total: 00:00:02.2451406 Average: 00:00:00.0022451

The Code

public class Program {
    public static void ImmutableCollectionAddToEnd(List<string> list) {
        var col = ImmutableCollection<string>.Empty;
        foreach (var item in list) {
            col = col.AddBack(item);
        }
    }
    public static void ListAddToEnd(List<string> list) {
        var col = new List<string>();
        foreach (var item in list) {
            col.Add(item);
        }
    }
    public static void RunAddToEnd(int count) {
        var list = Enumerable.Range(0, count).Select(x => x.ToString()).ToList();
        Console.WriteLine("Add to End {0} Elements", count);
        RunScenario("List", ListAddToEnd, () => list);
        RunScenario("Immutable", ImmutableCollectionAddToEnd, () => list);
    }
    public static void ImmutableCollectionAddToFront(List<string> list) {
        var col = ImmutableCollection<string>.Empty;
        foreach (var item in list) {
            col = col.AddFront(item);
        }
    }
    public static void ListAddToFront(List<string> list) {
        var col = new List<string>();
        foreach (var item in list) {
            col.Insert(0, item);
        }
    }
    public static void RunAddToFront(int count) {
        var list = Enumerable.Range(0, count).Select(x => x.ToString()).ToList();
        Console.WriteLine("Add to Front {0} Elements", count);
        RunScenario("List", ListAddToFront, () => list);
        RunScenario("Immutable", ImmutableCollectionAddToFront, () => list);
    }
    public static void ImmutableCollectionRemoveFromEnd(ImmutableCollection<string> col) {
        while (!col.IsEmpty) {
            col = col.RemoveBack();
        }
    }
    public static void ListRemoveFromEnd(List<string> list) {
        while (list.Count > 0) {
            list.RemoveAt(list.Count - 1);
        }
    }
    public static void RunRemoveFromEnd(int count) {
        Func<List<string>> listInputFunc = () => Enumerable.Range(0, count).Select(x => x.ToString()).ToList();
        Func<ImmutableCollection<string>> colInputFunc = () => ImmutableCollection.Create(listInputFunc());
        Console.WriteLine("Remove From End {0} Elements", count);
        RunScenario("List", ListRemoveFromEnd, listInputFunc);
        RunScenario("Immutable", ImmutableCollectionRemoveFromEnd, colInputFunc);
    }
    public static void ImmutableCollectionRemoveFromFront(ImmutableCollection<string> col) {
        while (!col.IsEmpty) {
            col = col.RemoveFront();
        }
    }
    public static void ListRemoveFromFront(List<string> col) {
        while (col.Count > 0) {
            col.RemoveAt(0);
        }
    }
    public static void RunRemoveFromFront(int count) {
        Func<List<string>> listInputFunc = () => Enumerable.Range(0, count).Select(x => x.ToString()).ToList();
        Func<ImmutableCollection<string>> colInputFunc = () => ImmutableCollection.Create(listInputFunc());
        Console.WriteLine("Remove From Front {0} Elements", count);
        RunScenario("List", ListRemoveFromFront, listInputFunc);
        RunScenario("Immutable", ImmutableCollectionRemoveFromFront, colInputFunc);
    }
    public static void RunScenario<T>(string description, Action<T> del, Func<T> getInputFunc) {
        // Run once to jit
        del(getInputFunc());
        const int times = 1000;
        var total = new TimeSpan();
        for (var i = 0; i < times; i++) {
            // get the input outside the timer so input creation is not calculated 
            var input = getInputFunc();
            var watch = new Stopwatch();
            watch.Start();
            del(input);
            watch.Stop();
            total += watch.Elapsed;
        }
        var average = TimeSpan.FromTicks(total.Ticks / times);
        Console.WriteLine("{0,11}: Total: {1} Average: {2}", description, total, average);
    }
    static void Main(string[] args) {
        var list = new int[] { 100, 1000, 10000 };
        list.ForEach(RunAddToEnd);
        list.ForEach(RunAddToFront);
        list.ForEach(RunRemoveFromEnd);
        list.ForEach(RunRemoveFromFront);
    }
}

Why are thread safe collections so hard?

Jared Parsons — Wed, 11 Feb 2009 16:00:00 GMT

Writing a collection which is mutable, thread safe and usable is an extremely difficult process. At least that’s what you’ve likely been told all through your schooling. But then you get out on the web and see a multitude of thread safe lists, maps and queues. If it’s so hard, why are there so many examples?

The problem is there are several levels of thread safe collections. I find that when most people say thread safe collection what they really mean “a collection that will not be corrupted when modified and accessed from multiple threads”. Lets call this “data thread safe” for brevity. This type of collection is rather easy to build. Virtually any collection that is not thread safe can be made “data thread safe” by synchronizing access via a simple locking mechanism.

For Example, lets build a data thread safe List<T>.

public sealed class ThreadSafeList<T> : IEnumerable<T> {
    private List<T> m_list = new List<T>();
    private object m_lock = new object();

    public void Add(T value) {
        lock (m_lock) {
            m_list.Add(value);
        }
    }
    public void Remove(T value) {
        lock (m_lock) {
            m_list.Remove(value);
        }
    }
    public bool Contains(T value) {
        lock (m_lock) {
            return m_list.Contains(value);
        }
    }
    public int Count { get { lock (m_lock) { return m_list.Count; } } }
    public T this[int index] {
        get { lock (m_lock) { return m_list[index]; } }
        set { lock (m_lock) { m_list[index] = value; } }
    }
    // IEnumerable<T> left out
}

And there you have it. The lock statement prevents concurrent access from multiple threads. So the actual m_list instance is only ever accessed by a single thread at a time which is all it’s designed to do. This means instances of ThreadSafeList<T> can be used from any thread without fear of corrupting the underlying data.

But if building a data thread safe list is so easy, why doesn’t Microsoft add these standard collections in the framework?

Answer: ThreadSafeList<T> is a virtually unusable class because the design leads you down the path to bad code.

The flaws in this design are not apparent until you examine how lists are commonly used. For example, take the following code which attempts to grab the first element out of the list if there is one.

static int GetFirstOrDefault(ThreadSafeList<int> list) {
    if (list.Count > 0) {
        return list[0];
    }
    return 0;
}

This code is a classic race condition. Consider the case where there is only one element in the list. If another thread removes that element in between the if statement and the return statement, the return statement will throw an exception because it’s trying to access an invalid index in the list. Even though ThreadSafeList<T> is data thread safe, there is nothing guaranteeing the validity of a return value of one call across the next call to the same object.

I refer to procedures like Count as decision procedures. They server only to allow you to make a decision about the underlying object. Decision procedures on a concurrent object are virtually useless. As soon as the decision is returned, you must assume the object has changed and hence you cannot use the result to take any action.

Decision procedures are one of the reasons why Immutable Collections are so attractive. They are both data thread safe and allow you to reason about there APIs. Immutable Collections don’t change ever. Hence it’s perfectly ok to have decision procedures on them because the result won’t get invalidated.

The fundamental issue with ThreadSafeList<T> is it is designed to act like a List<T>. Yet List<T> is not designed for concurrent access. When building a mutable concurrent collection, in addition to considering the validity of the data, you must consider how design the API to deal with the constantly changing nature of the collection.

When designing a concurrent collection you should follow different guidelines than for a normal collection class. For example.

Don’t add an decision procedures. They lead users down the path to bad code.
Methods which query the object can always fail and the API should reflect this.

Based on that, lets look at a refined design for ThreadSafeList<T>

public sealed class ThreadSafeList<T> {
    private List<T> m_list = new List<T>();
    private object m_lock = new object();

    public void Add(T value) {
        lock (m_lock) {
            m_list.Add(value);
        }
    }
    public bool TryRemove(T value) {
        lock (m_lock) {
            return m_list.Remove(value);
        }
    }
    public bool TryGet(int index, out T value) {
        lock ( m_lock ) {
            if( index < m_list.Count ) {
                value = m_list[index];
                return true;
            }
            value = default(T);
            return false;
        }
    }
}

Summary of the changes

Both the Contains and Count procedures were removed because they were decision procedures
Remove was converted to TryRemove to indicate it’s potential to fail
The TryGet property was added and is reflective of the fragile nature of the method. Sure it’s possible for users to simply ignore the return value and plow on with the invalid value. However the API is not lulling the user into a false sense of security
The collection no longer implements IEnumerable<T>. IEnumerable<T> is only valid when a collection is not changing under the hood. There is no way to easily make this guarantee with a collection built this way and hence it was removed.
The indexers were removed as well. I’m a bit wishy washy in this particular point as there is nothing in the API which gives a user a false sense of security. But at the same time mutable concurrent collections are dangerous and should be treated with a heightened sense of respect so the indexers were removed.

This version of ThreadSafeList is more resilient, but not immune to, accidental user failure. The design tends to lead users on the path to better code.

But is it really usable? Would you use it in your application?

Immutable Collections and Compatibility with Existing Frameworks

Jared Parsons — Wed, 10 Dec 2008 16:00:00 GMT

When developing my immutable collections library, I spent a lot of time on usability. After all, if a library is not useful then what’s the point?

A big portion of usability is being able to work with existing frameworks and technologies. For .Net and collections that means items like Data binding, LINQ etc … Without integrating into popular technologies the usefulness of a particular library is severely impacted and hence usability decreases.

Most of the existing collection based infrastructures use the .Net collection interfaces as their form of abstraction. The most straight forward way to ensure compatibility is to implement these interfaces on the collections in question. In particular ICollection<T>, IList<T> and IEnumerable<T> are the main abstractions. Lets investigate which ones an Immutable collection should be implementing in order to effectively integrate into existing collection based infrastructures.

IEnumerable<T>

This is the easiest decision. IEnumerable<T> represents a read only, one element at time view on a sequence of objects. Immutable collections can easily and reliably implement a IEnumerable<T>. This is a no brainer. Implement.

ICollection<T>

This interfaces represents a general collection class. Unfortunately this interface is meant to represent a mutable collection class and implements such methods as Add, Clear and Remove. These methods cannot be implemented on an Immutable collection given the current design. All three of these methods are void returning methods because the collection is meant to be changed in place. Immutable collections can support these operations but it involves returning a new instance of the collection.

public sealed class ImmutableCollection<T> : ICollection<T> {
    public ImmutableCollection<T> Add(T item) {
        // Actually add 
        // ...
    }

    #region ICollection<T> Members

    void ICollection<T>.Add(T item) {
        var created = this.Add(item);
        // What to do with created???
    }

    ...
}

But wait! The interface does support a property named IsReadOnly. The intention of this property is to allow an interface to programmatically declare they do not support modifications. A read only collection can just implement this interface, throw a NotSupportedException for all of the mutable methods and return true for IsReadOnly and presto we have a suitable interface for an immutable collection.

Or do we?

The design for ICollection<T> with respect to read only or immutable collections is not optimal. It attempts to combine to separate behaviors into a single interface: mutable and readonly view of a collection. Dual purpose interfaces run into problems because it’s impossible to separate out the behaviors at compile time. This is especially problematic when the behaviors are conflicting. There is no way a read only collection can prevent itself from being passed to a function that expects a mutable collection at compile time. Nor can a consumer who intends to mutate a collection prevent a read-only collection from being passed.

static void DisplayForEdit<T>(ICollection<T> col) {
    // ...
    m_clearButton.Click += (x, y) => col.Clear(); 
}

static void Example1() {
    ImmutableCollection<int> col = ImmutableCollection.Create(new int[] { 1, 2, 3, 4 });
    DisplayForEdit(col);    // Will fail as soon as Clear is clicked
}

But isn’t it the responsibility of the user of ICollection<T> to verify that IsReadOnly is false before mutating a instance? Given the current design of ICollection<T> it is indeed both the responsibility of the consumer to verify this and the implementer to ensure they are not called incorrectly. The problem with putting responsibility on the consumer though is they have to 1) know about read only uses of ICollection<T> and 2) actually care about it.

A quick search of the BCL with reflector can give us evidence of how much consumers actually check for the read only scenario. For the search I used mscorlib, System, System.Xml, System.Data, System.Drawing and System.Core and System.Windows.Forms. And the number of classes which actually take into account ICollection<T>.IsReadOnly is … 1. System.Collections.ObjectModel.Collection<T>. That’s it.

So even if an immutable collection implements this interface in a read-only fashion there’s little chance anyone will be checking for it.

IList<T>

IList<T> inherits from ICollection<T> and hence suffers from all of the same problems

Decision Time

In order to facilitate usability with existing frameworks immutable collections are forced to implement interfaces for which they have no possible way of implementing properly. If collections implement these interfaces they will be trading usability for compile time validation. Even worse is the conversion is implicit which prevents even basic searches for places this conversion occurs. This is a heavy price to pay for compatibility.

After debating this for awhile I decided that loss of compile time validation was a too heavy of a price to pay for the default scenario. But trading away usability was also unacceptable. As a compromise I opted for adding a compatibility layer to the collections. Instead of implementing the ICollection<T> and IList<T> collections directly I created a set of proxy objects that implement the interfaces on behalf of the immutable collections.

In order to centralize this effort I created a factory class, CollectionUtility, which contains appropriate overloads for all of my immutable collection classes [1].

public static class CollectionUtility {
    public static IEnumerable<T> CreateEmptyEnumerable<T>();
    public static IEnumerable<T> CreateEnumerable<T>(T value);
    public static ICollection<T> CreateICollection<T>(IReadOnlyCollection<T> col);
    public static IDictionary<TKey, TValue> CreateIDictionary<TKey, TValue>(IReadOnlyMap<TKey, TValue> map);
    public static IList<T> CreateIList<T>(IReadOnlyList<T> list);
    public static ICollection CreateObjectICollection<T>(IReadOnlyCollection<T> col);
    public static IDictionary CreateObjectIDictionary<TKey, TValue>(IReadOnlyMap<TKey, TValue> map);
    public static IList CreateObjectIList<T>(IReadOnlyList<T> list);
    public static IEnumerable<int> GetRangeCount(int start, int count);
}

The proxy objects live as private inner classes inside CollectionUtility. They implement the collection interfaces in the most read-only way possible. When confronted with mutating calls, the proxies throw NotSupportedException.

So at the end of the day I have compile time validation for immutable collections. If a developer wants to use them in a less than safe scenario it requires an explicit conversion.

static void Example2() { 
  var col = ImmutableCollection.Create(new int[] { 1, 2, 3, 4 }); 
  // Still fails, but explicit conversion required 
  DisplayForEdit(CollectionUtility.CreateICollection(col)); 
  }

I feel like this as an appropriate tradeoff. In the worst case scenario, a developer can search for all accesses of the CollectionUtility class and find places where a proxy is being created.

Next time, lets take a look at a different way of approaching an interface hierarchy for a set of collections. One that will allow us to avoid this problem altogether going forward.

[1] It actually contains overloads for a set of truly read only collection interfaces that I wrote for my library but we’ll get to that another time.

Edit: Updated the exception to be NotSupportedException

A Lesson in Serialization

Jared Parsons — Tue, 02 Sep 2008 15:00:46 GMT

A few days ago, I recklessly added a [Serialization] attribute to a few of my immutable collection types. I needed to pass data between AppDomain's and adding [Serialization] was the quick and dirty fix. Compiled, ran and I didn't think much about it.

Luckily I was updating some unit tests last night and I remembered this and added a couple of serialization sanity tests. Most of the tests passed first time but for my ImmutableStack class[1] was throwing an exception. Well, it was actually my ImmutableQueue but it was failing in one of the inner ImmutableStack instances. The test code was fairly straight forward

var stack = ImmutableStack.Create(new int[] { 1, 2, 3 });
using (var stream = new MemoryStream()) {
    var f = new BinaryFormatter();
    f.Serialize(stream,stack);
    stream.Position = 0;
    var obj = f.Deserialize(stream);
    var stack2 = (ImmutableStack<int>)obj;
    var stack3 = stack2.Reverse();
}

I did a bit of digging and discovered the exception was coming from the stack2.Reverse() call. Jumped through the code and didn't see much wrong. I had several existing tests around ImmutableStack.Reverse() and I couldn't see why Serialization would make any difference.

public ImmutableStack<T> Reverse() {
    var r = ImmutableStack<T>.Empty;
    var current = this;
    while (current != ImmutableStack<T>.Empty) {
        r = r.Push(current.Peek());
        current = current.Pop();
    }

    return r;
}

Can you see what's wrong with the code?

It took me a few minutes of debugging and frustration. The bug is in the while loop conditional. Until you introduce serialization this code is just fine. ImmutableStack<T>.Empty is a static readonly declaration. The code implementation only allows for one to be created so it a singleton and equality can be done with a quick reference check.

private static readonly EmptyImmutableStack s_empty = new EmptyImmutableStack();

public static ImmutableStack<T> Empty {
    get { return s_empty; }
}

Unfortunately serialization breaks the assumption that EmptyImmutableStack is a singleton. The EmptyImmutableStack class is a singleton by convention only. It's a private nested class that's only instantiated once per AppDomain. There is nothing stopping the CLR or Serialization for that matter from creating a second instance. In the case of deserialization that's exactly what happens. The serializer isn't built to recognize this pattern and instead simply creates a new instance of EmptyImmutableStack upon deserialization.

This essentially prevents you from safely using a functional style Empty pattern inside a serializable collection.

The fix is simple enough, alter the conditional to be (!current.IsEmpty).

[1] The version of ImmutableStack I'm using is heavily based off of Eric Lippert's implementation.

ImmutableStack in F# Part 2

Jared Parsons — Tue, 19 Aug 2008 15:00:20 GMT

I'm a bit busier than I thought I would be after returning from vacation. But I had a little bit of time to play around with the implementation again today. Thanks to all the suggestions in the comments from the previous post.

This version has a couple of improvements including

Removing the ambiguous constructor
More efficient All() implementation

Remaining issues:

Need to make it generic :)
Still exposing a type union. Great for F# but it produces somewhat awkward looking metadata for non-F# languages to consume

#light

namespace Col
    type ImmutableStack =
        | EmptyStack
        | Value of int * ImmutableStack
        static member Empty = EmptyStack
        static member Create( l:#seq<int> ) =
            let s = ref ImmutableStack.Empty
            l |> Seq.iter (fun n -> s := (!s).Push(n) )
            !s
        member x.Count =
            let rec count t (cur:ImmutableStack) =
                match cur.IsEmpty with
                    | true -> t
                    | false -> count (t+1) (cur.Pop())
            count 0 x
        member x.IsEmpty =
            match x with
                | EmptyStack -> true
                | _ -> false
        member x.Push(y) = Value(y,x)
        member x.Peek() =
            match x with
                | EmptyStack -> failwith "ImmutableStack is empty"
                | Value (v,_) -> v
        member x.Pop() =
            match x with
                | EmptyStack -> failwith "ImmutableStack is empty"
                | Value (_,n) -> n
        member x.Reverse() =
            let rec doBuild (cur:ImmutableStack) (building:ImmutableStack) =
                match cur.IsEmpty with
                    | true -> building
                    | false -> doBuild (cur.Pop()) (building.Push(cur.Peek()))
            doBuild x ImmutableStack.Empty
        member x.All() =
            match x with
                | EmptyStack-> Seq.empty<int>
                | Value (v,n) -> seq {
                    yield v
                    yield! n.All() }

Immutability and ReadOnlyCollection

Jared Parsons — Tue, 22 Apr 2008 15:42:00 GMT

I am a huge fan of read only/immutable collections and data. Hopefully the increased exposure through the blogosphere alerted users to the advantages of this type of programming for the appropriate scenarios. I wanted to discuss ReadOnlyCollection<T> in case devs looking around in the BCL discover it and assume it's immutable. There are two details of this class which cause gotchas and design issues for consumers who assume it is immutable.

It implements IList<T>

IList<T> is a interface describing mutable collection types which support indexing. ReadOnlyCollection is designed to be read only and cannot fulfill this contract. Therfore every mutable function will throw an exception. IMHO this is not the best design because it is implementing a contract it won't every fullfill. This has the effect of turning what should be a compile time error into a runtime exception (passing a non-mutable collection to an API expecting a mutable collection).

Unfortunately there is not a good interface to implement. The indexable interfaces are all representative of mutable collection types. It would be nice to add an immutable/read only interface which can be safely implemented.

    interface IReadOnlyList<T> : IEnumerable<T>
    {
        T this[int index] { get; }
        int Count { get; }
        int IndexOf(T value);
        bool Contains(T item);
        void CopyTo(T[] array, int arrayIndex);
    }

Ideally this would be called IImmutableList<T> but I'm having trouble getting over the double I, double M pattern to start the name. Perhaps IPersistentList.

It's not deeply ReadOnly

ReadOnlyCollection<T> is a read only facade on top of mutable collection. Read only data should be just that, read only. This means calling methods directly on the class produce the same result every single time. However because it uses a mutable backing store this is not true and can cause gotchas along the road.

Take the following sample which uses a ReadOnlyCollection to wrap a List.

            var list = new List<int>();
            list.AddRange(Enumerable.Range(1, 10));

            var roList = new ReadOnlyCollection<int>(list);
            Console.WriteLine(roList.Count);    // Outputs: 10
            list.Add(42);
            Console.WriteLine(roList.Count);    // Outputs: 11

There are ways to avoid this problem with ReadOnlyCollectionn. The simplest is to make sure you pass a copy of your list into the constructor.

            var roList2 = new ReadOnlyCollection<int>(new List<int>(list));

PipeSingleReaderNoLock

Jared Parsons — Mon, 03 Mar 2008 08:46:00 GMT

Previously we discussed a multi-thread safe queue like data structure using locks as an internal synchronization mechanism. This time we'll look at a version requiring no locks.

In the previous version, locks were used to synchronize access to an underlying queue which stored the data. Removing the locks necessitates us moving away from Queue<T> to store the data and forces us onto another structure which is safe in the presence of multiple threads.

Immutable collections are safe in the presence of multiple threads and don't require any synchronization mechanisms. However they're immutable and we're trying to build a mutable data structure? No matter. Even though each instance is immutable they can be used to create new instances which represent a somewhat mutated state.

For this exercise we will be using a slight variant of Eric Lippert's Immutable Stack implementation [1]. The pipe will have two stacks; 1) for capturing input and 2) for storing output. Named m_writeStack and m_readStack respectively.

This makes the implementation of reading input straight forward. While m_readStack is not empty the reader thread can systematically pop off the values. This doesn't require any contention with writer threads and since their is only one reader thread and the stack is immutable the code is straight forward. Once the m_readStack is empty the reader thread will swap out the current state of m_writeStack with an empty stack. The original value will be reversed so we can maintain the FIFO ordering and set as the new m_readStack.

private bool CheckForInput() {
    if( m_readerStack.IsEmpty ) {
        var prev = Interlocked.Exchange(ref m_writerStack, ImmutableStack<T>.Empty);
        m_readerStack = prev.Reverse();
    }
    return !m_readerStack.IsEmpty;
}

Writing data is more complicated because it must deal with contention for updating the same data structure. It can be altered by other writers or the reader thread when it runs out of data. Basically it must push a value onto the stack and update the m_writerStack to point to the new value. In between the operations the value of m_writerStack could change and thus invalidate the push. To guard against this the writer must guarantee the current value of the m_writerStack is the same as it was before the push operation. Interlocked.CompareExchange will do the trick. If it's been changed then repeat the operation.

public void AddInput(T value) {
    bool done;
    do {
        if (m_inputClosed) {
            throw new InvalidOperationException("Input end of pipe is closed");
        }
        var originalStack = m_writerStack;
        var newStack = originalStack.Push(value);
        var currentStack = Interlocked.CompareExchange(ref m_writerStack, newStack, originalStack);
        done = object.ReferenceEquals(currentStack, originalStack);
    } while (!done);
    m_event.Set();
}

At a glance it may seem like this suffers from the ABA problem. This is not the case and it's easy to prove. In between the read and push operation only two other operations can modify the m_writeStack variable. The first is another write which will produce a new value of ImmutableStack<T>. In this case the CLR guarantees that the references will not be equal and the CAS operation won't succeed. The second is the reader thread swaps out the value and replaces it with Empty. It's possible to hit an ABA situation here (detailed below) but fundamentally if it was empty before and empty now the operation is still safe. No data is lost because we are still replacing an empty stack with a single value'd stack.

Here's a more elaborate version starting with an empty pipe of type int

Thread 1: Begins to write 5 and is stopped just before the CAS operation

originalStack points to ImmutableStack<int>.Empty

Thread 2: Starts and completes a write of the value 6
Thread 3: Reads a value from the pipe, having no data replaces m_writeStack with ImmutableStack<int>.Empty
Thread 1: Resumes and the CAS succeeds even though the m_writeStack technically changed in the middle of the operation

Even though this exhibits many characterstics of the ABA pattern it is not a problem because the behavior is still correct. No data was lost because it was transferred to the reader thread. The end result is m_writeStack pointing to a single vaue'd stack containing the data 5 which is valid. The pipe does not guarantee the ordering of data between writer threads (merely the ordering between a single writer thread).

Below is the implementation in it's entirety.

public class PipeSingleReaderNoLock<T> : IDisposable {
    private readonly ThreadAffinity m_affinity = new ThreadAffinity();
    private ImmutableStack<T> m_readerStack = ImmutableStack<T>.Empty;
    private ImmutableStack<T> m_writerStack = ImmutableStack<T>.Empty;
    private readonly AutoResetEvent m_event = new AutoResetEvent(false);
    private volatile bool m_inputClosed;

    public PipeSingleReaderNoLock() {
    }

    #region Dispose
    public void Dispose() {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
    ~PipeSingleReaderNoLock() {
        Dispose(false);
    }
    private void Dispose(bool disposing) {
        if (disposing) {
            m_event.Close();
        }
    }
    #endregion
    public void WaitForOutput() {
        m_affinity.Check();
        while (!CheckForInput()) {
            m_event.WaitOne();
        }
    }
    public T GetNextOutput() {
        m_affinity.Check();
        T data;
        while (!TryGetOutput(out data)) {
            m_event.WaitOne();
        }
        return data;
    }
    public bool TryGetOutput(out T value) {
        m_affinity.Check();
        if (CheckForInput()) {
            value = m_readerStack.Peek();
            m_readerStack = m_readerStack.Pop();
            return true;
        }
        else {
            value = default(T);
            return false;
        }
    }
    private bool CheckForInput() {
        if (m_readerStack.IsEmpty) {
            var prev = Interlocked.Exchange(ref m_writerStack, ImmutableStack<T>.Empty);
            m_readerStack = prev.Reverse();
        }
        return !m_readerStack.IsEmpty;
    }
    public void AddInput(T value) {
        bool done;
        do {
            if (m_inputClosed) {
                throw new InvalidOperationException("Input end of pipe is closed");
            }
            var originalStack = m_writerStack;
            var newStack = originalStack.Push(value);
            var currentStack = Interlocked.CompareExchange(ref m_writerStack, newStack, originalStack);
            done = object.ReferenceEquals(currentStack, originalStack);
        } while (!done);
        m_event.Set();
    }
    public void CloseInput() {
        m_inputClosed = true;
    }

[1] If you haven't read this series you really should.

Tuples Part 7: Mutable Tuples

Jared Parsons — Wed, 23 Jan 2008 10:56:19 GMT

Part 6 left us with comparable tuples. At this point, the Tuple class is functionally complete. There will be a little more done with the debugability and overall fit into larger projects. But otherwise it is sound.

Now the focus shifts to generating mutable tuples. Immutability is nice for threading, memoization, etc ... However it's not always practical to use immutable objects. Often an algorithm does not benefit from immutability and lends itself to a more mutable type.

Mutable tuples behave like a Tuple in every other way except that they're ... mutable. This includes implementing interfaces as well as inheritance structure.

public sealed class MutableTuple<TA, TB> : 
    ITuple<TA, TB>, 
    IEquatable<MutableTuple<TA, TB>>, 
    IComparable<MutableTuple<TA, TB>>, 
    IComparable
{

As such the script already used will be sufficient to generate mutable classes in addition to the ones its already doing. The majority of the code difference is just in the naming of the classes. The only functional differences exist in the properties and indexer. Both of these add a setter method. Below is the modified code for generating the property and indexer.

function script:Gen-TupleAccess
{
    param ( [int] $count = $(throw "Need a count"), [bool]$mutable )
    "public int Count { get { return $count; } }"
    "public object this[int index] { get { switch (index){ "
    0..($count-1) | %{ "case $($_): return m_$($lowerList[$_]);" }
    "default: throw new InvalidOperationException(""Bad Index"");"
    "} }"

    if ( $mutable )
    {
        "set { switch (index) {"
        0..($count-1) | %{ "case $($_): m_$($lowerList[$_]) = (T$($upperList[$_]))value; break;" }
        "default: throw new InvalidOperationException(""Bad Index"");"
        "} } "
    }
    "}"
}

function script:Gen-Property
{
param ( [int] $index = $(throw "Need an index"), [bool]$mutable = $false)

    if (-not $mutable )
    {
@"
    private readonly T{0} m_{1};
    public T{0} {0} {{ get {{ return m_{1}; }} }}

"@ -f $upperList[$index],$lowerList[$index]
    }
    else
    {
@"
    private T{0} m_{1};
    public T{0} {0} {{ get {{ return m_{1}; }} set {{ m_{1} = value; }} }}

"@ -f $upperList[$index],$lowerList[$index]
}
}

Now creating a mutable tuple is the same as the immutable tuple with just a name tweak.

            var t1 = MutableTuple.Create("foo", 42);
            t1.A = "again";

Tuples Part 1

Jared Parsons — Thu, 03 Jan 2008 19:25:51 GMT

A tuple in computer science can be described as a set of name/value pairs. In some cases it can be described as simply a set of values that are accessible via an index [1]. Previously I discussed how to create a Tuple inside of PowerShell. This series will focus on the use of Tuples in DotNet and how to use PowerShell to generate DotNet code.

This series will also distinguish between mutable and immutable tuples. As DotNet is shifting it's focus on parallel programming, immutable types are becoming more important. Therefore this serious will focus on Tuples as immutable types and later examine mutable tuples.

In Visual Studio 2005, both C# and VB acquired tuples as a part of the programming language in the form of Anonymous Types. These fit all of the properties of a tuple. The one difference is in VB, anonymous types are mutable by default. This can be changed though by using the Key keyword.

However anonymous types are lacking one quality which severely lessens their usefulness. Their type cannot be described. This prevents them from being used as parameters, fields, generic parameters [2] etc ... Unless you use late binding or terribly awkward casts this is limiting.

To get around this, we will be defining a set of generic tuple class supporting 1-N name value pairs. The great downside is because we will be predefining these types the names in the name value pair will be fixed. We will be using A-N for 1-N pairs.

This is very limiting in itself because it's reducing the expressiveness of a type. Anonymous types are much more expressive since they have names. Now types will have properties A,B, etc ...

For me this still works. In my code, I only end up using tuples when I need to pass data around between tightly coupled classes, or just within the same class. Since the creation and use are so close loosing the full expressiveness of the name is not that limiting.

In addition, our tuple implementation will leverage type inference as much as possible such that the following code can be written.

            var tuple = Tuple.Create("foo");
            Console.WriteLine(tuple.A);

Why write a script to generate these classes? Wouldn't it just be easier to just do this by hand??? Yes and no. If you are doing a fixed set of short used classes then yes, do it by hand. These scripts evolved out of my use of tuples. Once I would settle on a structure and I would think of a new feature I needed. Typically I have tuples defined up to 5 fields. Retyping out a new feature got tiresome and error prone. With a scripting solution I could add a new feature and tests in just a few minutes. The series is very representative of the way my solution changed over time. Simple at first but I added features as the situation dictated. Having a scripting solution saved me a lot of time.

Next up, generating the basic structure.

[1] In this case, the index just becomes the name and hence a name/value pair.