Michael Entin's notebook : .NET

Random() is only random if you are using it right

michen — Tue, 05 Feb 2008 11:53:00 GMT

I like the quote "With great power comes great responsibility" when used in regards to .NET - .NET gives one great powers, but use it wisely and know how this stuff works.

Recently I saw code (it was written by a guy interviewing to our team) that demonstrated interesting problem with incorrect usage of Random class. The code generated a random position for an object, tested if it satisfied some condition; if it did not work - generated another random position, tested the new position and so on until it generated something that did work. The code to generate each position was pretty simple: create new instance of Random class, use it to generate 4 random integers. The percentage of failed position was not very big (but noticeable), the code to test the position was rather fast, and we needed just 10 good positions to create complete configuration (all this was about a variant of Battleship game).

But it took very long to generate the whole configuration - about a second on average.

Playing with this code, I suddenly found that moving Random object to a member variable, so it is re-used, rather than creating new Random object for each position, made the code 10000 times faster! Well, obviously I expected some savings since it creates less objects, but ten thousand times? My first reaction - is the Random really such a heavy object?

It turned out the problem was more interesting, and caused by the usage of default constructor. As MSDN puts it, if you use default constructor the "seed is initialized to a value based on the current time." It actually uses GetTickCount() as the seed. Can you now spot the problem? The Random() constructor was very quick, but during the period of time when GetTickCount() returns the same value (which is about 20ms for most chipsets), all the Random objects created this way will have the same seed and generate the same positions! Instead of trying new positions, the code tried the same position again and again until the GetTickCount() returned a new value. So don't generate too many Random instances - just one will behave much better in most cases.

Functional sort in C#

michen — Tue, 11 Dec 2007 22:46:00 GMT

On an internal mailing list, we were discussing functional languages, and this Haskell sort code:

qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

While trying to explain how this code works (which is very different from what it looks like to C++/C# programmers due to lazy evaluation) I've come up with following C# code (with Linq) that is logically similar to Haskell version. Obviously, Haskell code is much nicer though.

static IEnumerable<T> Qsort<T>(IEnumerable<T> s) where T : IComparable<T>

{

IEnumerator<T> e = s.GetEnumerator();

if (e.MoveNext())

{

T x = e.Current;

foreach (T t in Qsort(s.Skip(1).Where(y => y.CompareTo(x) < 0)))

yield return t;

yield return x;

foreach (T t in Qsort(s.Skip(1).Where(y => y.CompareTo(x) >= 0)))

yield return t;

}

Don't run SSIS package using SQL/CLR

michen — Sat, 25 Aug 2007 03:57:00 GMT

A recent commenter suggested running SSIS using SQL/CLR:

Just an idea on how to do this that may be a bit easier than any of the methods covered. IF you were to write a CLR procedure which accepts a string as its parameter. The string passed in would be the xml definition of a package (either loaded from a source (file, server, etc)or from an application which is able to create the package definition). Then using the CLR procecure that I mentioned above (which has references to the DTS runtime), you could use the Microsoft.SqlServer.Dts.Runtime.Package LoadFromXML() method to flesh out an empty package and then the Execute() method to actually run it.

This may look like a good idea, but don't do this. The reason is that SQL Server has very strict requirements on the type of code running inside (this is how it achieves the great reliability, and why by default it only allows "safe" .NET code and only selected system assemblies). It takes a lot of effort to "harden" code to satisfy these requirements. See e.g. this excellent article by Joe Duffy describing one of the issues: http://www.bluebytesoftware.com/blog/2007/08/23/ThreadInterruptsAreAlmostAsEvilAsThreadAborts.aspx. Only a subset of .NET framework has been "hardened" to qualify.

The SSIS uses "unsafe" .NET code, and we've not done enough testing of SSIS and dependencies inside SQL Server to recommend running it this way, so it is unsupported.

You'd be safer if you write a web service application that does it, and the extra benefit - SQL Books Online has sample code!

Using C# 2.0 iterators to simplify writing asynchronous code (part 2)

michen — Sat, 01 Apr 2006 23:01:00 GMT

Previous article describes the idea of using C# 2.0 iterators to write asynchronous code, now it's time to implement the utility class that "runs" the iterator. The utility turns out to be very light, I'm glad some readers reported they've already implemented their own version.

Lets list requirements for the utility:

The user code should run sequentially. The code can "jump" between threads, but the main benefit of the approach is to let user write sequential code.
The iterator should only resume when all the asynchronous operations finished, and previous moveNext() has yield the result.
The utility should provide centralized exception handling.
If the iterator function has finally clause, C# converts it to Dispose() method of IDisposable interface. We need to call it at the end of iteration.

I've played with different ways to use the utility, and settled on the following pattern:

AsyncEnumerator ae = new AsyncEnumerator();
ae.Start(UserFunction(/*user params*/..., ae));

The AsyncEnumerator class exposes following public API:

public sealed class AsyncEnumerator
{
    public AsyncEnumerator() {}

    // The user-supplied exception handler,
    // if it returns true the enumeration stops.
    public Predicate<Exception> Catch
    {
        get { }
        set { }
    }

   // User should never call this delegate directly, but
    // should pass this callback to any async API it calls.
    public AsyncCallback Callback
    {
        get { }
    }

    public void Start(IEnumerable<Int32> enumerable) {}
}

Now how do we run the user code sequentially, and only resume it after all async operations have finished? The first iteration is invoked directly (i.e. we simply call enumerator.MoveNext, but to make the Start return immediately, we do it on thread pool thread). To decide when to invoke following iterations, let's keep a counter of outstanding async operations (this value it returned by user's yield return statement and is accessible by enumerator.Current). When an async operation finishes and our callback is called, we decrement this counter by 1 (of course, we should use interlocked operations since callbacks may get called in parallel). Once the counter reaches 0, all the outstanding async operations have completed and we should resume the iterator (i.e. call enumerator.MoveNext again).

The only tricky part is that callback(s) may get called before the iterator returns from MoveNext() call - this is why I've added the requirement that iterator can only be resumed after moveNext() has returned. The callback might even be called on the same thread that called the asynchronous method - if there is enough information to complete this call synchronously. The way we handle it is to allow the number of outstanding async operations be negative - we start with 0; each async callback decrements the count by 1; and when iterator.MoveNext() returns we increment it by iterator.Current. If after any of these operations the number of outstanding async operations again becomes 0, we know that all async operations have finished and the iterator code has exited with 'yield return', so it is safe to advance the iterator again:

Thus there is a race between two threads that may resume iterator: the original thread that called previous iterator.MoveNext() and the thread that reported end of the last async operation. But it's OK, since our contract allows iterator code to migrate between threads, we only guarantee that a single thread runs it at a time.

public sealed class AsyncEnumerator
{
    private IEnumerator<Int32> m_enumerator;
    private Int32 m_PendingAsyncOps = 0;

    public void Start(IEnumerable<Int32> enumerable)
    {
        m_enumerator = enumerable.GetEnumerator();

        // let's start the enumeration asynchronously too
        ThreadPool.QueueUserWorkItem(delegate { Advance(); });
    }

    // This is first implementation of Advance, to be revised below.
    private void Advance()
    {
        while(true)
        {
            if (!m_enumerator.MoveNext())
                break;

            // The enumerator returns the number of async ops it initiated
            // Add this to m_PendingAsyncOps
            int pendingAsyncOps = Interlocked.Add(ref m_PendingAsyncOps, m_enumerator.Current);

            if (pendingAsyncOps != 0)
                break; // quit this thread, let other thread resume iteration

            /* No pending Async Ops, continue enumeration */
        }
    }

    // The delegate for this function is passed to all async calls that
    // user makes and thus it is automatically called by async API
    // when an async operation finishes.
    // It is never invoked by our code or directly by user.
    private void Advance(IAsyncResult ar)
    {
        // An async op completed, subtract 1 from m_PendingAsyncOps
        Int32 pendingAsyncOps = Interlocked.Decrement(ref m_PendingAsyncOps);
        if (m_PendingAsyncOps == 0)
        {
            // The last pending async op completed, continue enumeration
            Advance();
        }
    }
}

Finally, last requirements: exception hanlding and calling Dispose() method at the end of iteration. Both changes only affect void Advance() function that works with iterator - we need to catch the exception and call the user-provider handler, and at the end of iteration call Dispose():

    private void Advance()
    {
        bool end = true; // Assume that we'll stop the iteration

        while(true)
        {
            try
            {
                end = !m_enumerator.MoveNext();
            }
            catch (Exception e)
            {
                // An exception occurred, catch it and execute the callback.
                // The callback returns true to end the iteration or false to continue it
                end = (m_catch != null) ? m_catch(e) : true;
            }
            if (end)
                break;

            // The enumerator returns the number of async ops it initiated
            // Add this to m_PendingAsyncOps
            int pendingAsyncOps = Interlocked.Add(ref m_PendingAsyncOps, m_enumerator.Current);

            if (pendingAsyncOps != 0)
                break; // quit this thread, let other thread resume iteration

            /* No pending Async Ops, continue enumeration */
        }

        if (end)
        {
            // If nothing else to do, execute iterator's finally code
            IDisposable d = m_enumerator as IDisposable;
            if (d != null) d.Dispose();
        }
    }

Now the only missing piece is the public API. We have public Callback property that returns AsyncCallback delegate - we just return the second void Advance(IAsyncResult ar) function, but to avoid creating new delegate for each async call, lets cache it. And exception handler is just a delegate that user can provide:

public sealed class AsyncEnumerator
{
    private Predicate<Exception> m_catch;

    // Delegate for passing to async methods
    // (to avoid creating new delegate for each call).
    private AsyncCallback callback;

    public AsyncEnumerator()
    {
        this.callback = Advance;
    }

    /// <summary>
    /// The user-supplied exception handler, should return true to stop enumerator
    /// </summary>
    public Predicate<Exception> Catch
    {
        get { return m_catch; }
        set { m_catch = value; }
    }

    /// <summary>
    /// The callback that user code should pass to all async APIs
    /// </summary>
    public AsyncCallback Callback
    {
        get { return this.callback; }
    }
}

This is all for today. For next blog entry, I plan to do performance measurements, and compare code that uses this utility with code that uses threads and synchronous calls. But I've not done this yet, so you are welcome to post your results!

Using C# 2.0 iterators to simplify writing asynchronous code

michen — Thu, 30 Mar 2006 11:44:00 GMT

A neat idea how C# 2.0 iterators can simplify the task of writing code that uses .NET async pattern.

I’ve recently attended Jeffrey Richter’s class dedicated to effective threading techniques, and that made me think about using the .NET async pattern. The typical usage of this pattern is the following: you start one or more asynchronous operations using obj.BeginOperation method (e.g. stream.BeginRead) passing a callback delegate and immediately return, releasing the thread that started processing. Once the async operation completes, your callback is called (usually on a thread-pool thread). The callback code checks what async operations have completed, and if you have enough data to proceed further it executes next block of code. This is very important for multithreaded servers, since very little resources are being used while the program waits for operation to finish (which can take a while).

But it is very hard to program with this pattern - instead of writing simple sequential code, the code is split into disconnected callbacks that may get executed in parallel. In some cases anonymous delegates make it somewhat better. But if more than one async operation is to be performed in sequence you usually need to maintain some state machine, evaluate where you are and what operation is to be performed next, etc - complex and buggy. Jeffry Richter showed some sample code doing this, but it is obvious it is very hard to write and maintain such code.

I thought it would be nice if there was a way to write sequential code that is put asleep (but does not waste thread), and then restarted when the async operation completes - so called coroutines (see http://en.wikipedia.org/wiki/Coroutines). Then I realized we already have these in C# 2.0 - in form of C# iterators! The idea is to organize the application code as an "iterator" that will "yield" some value after each async operation. Then we need a library utility class that restarts the iterator after the next async operation finishes.

The user code will looks like this:

IEnumerable<int> Foo(/* user params */...,
    /* utility class */ AsyncEnumerator ae)
{
    // start async operation
    IAsyncResult asyncResult = stream.BeginRead(...,
    /* callback provided by utility*/ ae.Advance, null);
    // we could do some more stuff here before yielding
    yield return 1;

    // the code below is called after the code above
    // and after the asynchronous operation ends
    int dataRead = stream.EndRead(asyncResult);
    ...
}

and is started by following code:

AsyncEnumerator ae = new AsyncEnumerator();
ae.Start(Foo(/* user params */ ..., ae));

The AsyncEnumerator utility guarantees the code is executed sequentially, although it may jump between threads :). My iterator code originally yield the IAsyncResult returned by async operation it just started, but it was not really used by utility class. I then showed it to Jeffrey Richter who suggested an ingenious idea - the iterator should produce the number of outstanding async operations started by the iterator code - and the utility class resumes the iterator when all of these operations have completed, this idea fits very well with the synchronization code.

Another issue solved by the utility is exception handling: C# iterators can't have catch block around yield statement, so centralized error handling is hard. The utility catches exceptions raised by iterator, and calls a user-provided delegate that performs exception handling and returns boolean value indicating whether the iteration should stop (another neat improvement by Jeffrey Richter).

If this made you interested, come back to this blog - I'll post details on the inner working of the utility in the next entry.

References:
C# 2.0 iterators http://msdn.microsoft.com/msdnmag/issues/04/05/C20/

Async method pattern in .NET
http://msdn.microsoft.com/msdnmag/issues/01/08/Async/
http://msdn.microsoft.com/msdnmag/issues/04/01/BasicInstincts/default.aspx