Justin Rogers : Regular Expressions

Testing: GC Sanity Checks in Whidbey

Justin Rogers — Sat, 02 Oct 2004 16:42:00 GMT

I have a feeling this method will only be useful when you can run a series of tests without any collections taking place during your tests. Whenever a collection occurs you can never be sure of the amount of time spent in collection (anyone on the CLR want to surface that number without going to performance counters?) so you can't really get an understanding of how badly your test was affected. I've managed to run some rather long tests without any collections by pre-allocating everything to be used by the testing structure and avoiding additional allocations during the test process. Here is how I check for collections:

// Before my test
int[] collections = new int[3];
collections[0] = GC.CollectionCount( 0 );
collections[1] = GC.CollectionCount( 1 );
collections[2] = GC.CollectionCount( 2 );

// After my test
Console.WriteLine( "Collections: {0}, {1}, {2}",
    GC.CollectionCount( 0 ) - collections[0],
    GC.CollectionCount( 1 ) - collections[1],
    GC.CollectionCount( 2 ) - collections[2] );

What I've realized from this little method is that pre-allocating the testing structure really does make a huge difference. I can see 5 or 6 collections if my objects are allocated on the fly during the test and 0 collections if the are pre-allocated into an array or similar structure. Now, in many tests you aren't going to avoid allocating new objects during the test. In many cases the sole purpose of the test is to allocate new objects, such as return strings, or other data. If that is the case, you might want to look for a balance in the collection count between both of your testing methods, test multiple times, test for short periods and average over a large number of separate test loops, or use high performance counters to avoid the DateTime round-off issues.

Regex: MatchCollection uses delay matching for performance

Justin Rogers — Tue, 07 Sep 2004 09:27:00 GMT

There are several ways to get all of the matches of an expression over the source input, but the most popular probably has to be the Matches method which returns a MatchCollection. What most people don't know, and I didn't until recently, is that the actual call to Matches doesn't do any work. It returns a shell that only does work when you actually request the results.

Count
This property is responsible for why most people probably can't tell the difference. Once you get a MatchCollection the first thing you do is check the Count property. All this does is force the MatchCollection to run the expression and fill the internal structures. When you do this, all of the delay loading potential is removed so the underlying collection knows how many matches are present.

This definitely posed some problems for the Asynchronous Regular Expressions using the ThreadPool and a cancellation model. We rewrote the code there to just return a MatchCollection but for some reason it was completing extremely fast all the time and we couldn't figure out why in the hell that was happening. Well, we went ahead and made a call to Count within the runner thread and now everything works as it should.

this[int i]
The default indexed property for getting access to Match classes is delay loaded, assuming you don't call Count first. You can pass any index you want to this bad boy, and it'll load all of the matches in between (if they aren't already loaded), and then service the match index you just passed in. Here is where I consider the bad code to start in. If the match doesn't exist, they internally return a null, so if you ask for match 20 and there are only 8, null will get returned internally but they'll throw a ArgumentOutOfRangeException externally.

// Normally this would be possible
Match m = null;
for(int i = 0; (m = matches[i]) != null; i++) {
}

// You could optimize for a specific count
Match m = null;
for(int i = 0; i < 5 && (m = matches[i]) != null; i++) {
}

Unfortunately, the above two constructs aren't possible because of the exception, however, they would be the ideal way to process matches without loading all of the work into a single call.

Enumerator
They do have an enumerator that I guess you really have to use if you want true delay loading syntax without that lame exception. This works out well because it balances the matching work between working with the match and we are no longer front-loaded. This allows us to make a number of syntaxes available, including processing pattern matches for a specific match, or processing only a specific number of matches.

// Process until we find the match we want
foreach(Match m in matches) {
    if ( m.Groups[4].Value == "choice X" ) { /* Do Work */ break; }
}

// Process the first n matches
int count = 0;
foreach(Match m in matches) {
    // Do work
    if ( ++count == 5 ) { return; }
}

We don't stop there. You can also enable RightToLeft matching in an attempt to get the last n matches instead of the first n. You start to see where you get some interesting options for processing a string for multiple matches while still have great control over your performance. Considering various patterns can hang the regular expression engine knowing how and where to use multi-threaded abortable operations can really save you from hanging your application.

Regex: Functionality about named/numbered groups everyone should know.

Justin Rogers — Mon, 06 Sep 2004 23:31:00 GMT

We have a cool new tool amongst us over on http://www.regexlib.com/RETester.aspx. It is already more functional than the previous tool there that was receiving quite a bit of traffic and attention for quickly testing expressions. The new tool really focuses on debug and diagnostic information that can be used to help tune an expression. More will be added for certain, but just the past day a more detailed group capture view was added that presented a few problems.

Explicitly Numbered Groups
This one isn't strange at all, in fact it is only because of extensions by the .NET expression engine that they might be confusing. Numbered groups allow you to change the index of a given capture. If you are working with the GroupCollection you might write the following code in order to enumerate all of the groups. This will print out Group[0] which is always present, but then it will try to point out Group[1]. This will succeed, but not print anything if the expression looks like, "(?<10>111)" and given the input "111";

for(int i = 0; i < m.Groups.Count; i++) { Console.WriteLine(m.Groups[i]); }

What you need to do is get a list of group numbers using the Regex.GetGroupNumbers method. This returns an array of indexes you can use instead of simply dropping blind into the group collection. Another common mistake may also be a foreach or enumeration of the group collection. If you do this, you will get all captures, but you won't be able to retrieve their name or number.

// BAD
foreach(Group g in m.Groups) { }
// GOOD
int[] groups = regex.GetGroupNumbers();
for(int i = 0; i < groups.Length; i++) {
Group g = m.Groups[groups[i]];
}

Named and Numbered Reordering
All named captures are also given a number, but they aren't given a number in-line with their ordering within the expression. They are actually assigned numbers after all of the numbered groups have been allocated. That means the expression "(?<name>99)(9)" would return the 9 as the 1st ordered group and 99 as the second ordered group. If you name a group, be careful when you mix and match with unnamed groups because the indexes are not going to be what you might initially think.

Numbering Bug
Explicitly numbered groups may get overwritten by groups whose indexes are automatically assigned. For instance, if you start an expression by numbering a group, say "(?<10>99)", then go on to create an expression with more than 9 anonymous groups, you'll find that the 10th group gets overwritten or shared. The resulting Value of group 0 is the full capture, but the value present in group 10 will be the value of whatever group is processed last. This is best examined than talked about.

private static Regex regex2 = new Regex("(?<10>99)(9)(9)(9)(9)(9)(9)(9)(9)(9)(9a)(9)(9)(9)(9)(9)(9)(?<20>99)");
private static string data1 = "999999999999a9999999999999999";

For the results, how many groups print the value "99", how many groups print the value "9a". Further, count the number of 9's in the group 0, and the number of 9's in the rest of the groups. Do they even match? Have fun with this and be careful. Regular expressions are supposed to make your life easier, but there are some gotchas.

References:
[1] Match vs MatchSparse, a regular expression implementation detail that may surprise you.
[2] The extended .NET Regular Expression tester is up on www.RegexLib.com

The extended .NET Regular Expression tester is up on www.RegexLib.com

Justin Rogers — Sat, 04 Sep 2004 20:13:00 GMT

Hey guys, figured I'd ping everyone and tell them this little jewel was out and ready to go. You can test your expressions any time you have an internet connection and use some extended features like source from file/web. I have to say the tool is more and more functional every day as new options are being added. Here is a quick overview of the current options:

Client or Server Side Testing - Test against the .NET engine or the browser vb/jscript implementations.
Some new buttons allow you to quickly add your current pattern to the repository on RegexLib or go grab some existing expressions.
You can now specify all of the capturing options for the expression right up front.
The source for an expression can be retrieved for you by an external data source.
Selecting groups and captures in the results window will result in the item captured in the source being highlighted.
And the same asynchronous runner is being used so those runaway expressions won't have you waiting hours for a return, instead they'll conk out after only a few prolonged seconds.

Some of the options that have been tossed back and forth include:

Formalize the tab structure to include documentation, display options, and more. That middle documentation panel is like a window into another universe and we want to make sure the other universe is full of great information.
I've tossed my hand in to include nested groups as nested items in the tree structure... The flat layout of group numbers doesn't portray this, but the offset+length values do give you an idea of where groups are in the hierarchy.
I'm hoping to translate some C# code to aid with screen scraping into JScript so the functions can generate expressions on the client-side. The basic premise is that by feeding some source value, and then tagging all of the ranges you can more easily design a range by telling the code what type of data will be present so it can create an appropriate pattern for that portion. This doesn't work on extremely dynamic patterns, such as date-times, etc... But it would allow you to work on something simpler, especially the not-so-complex layout of a table row within an HTML page.

Go check it out: http://www.regexlib.com/RETester.aspx, and make sure to give plenty of feedback on issues. I guess there were a ton last night, but I'm seeing that everything I've tested today works well.

Regular Expression posts of recent note on blogs.RegexAdvice.com

Justin Rogers — Tue, 10 Aug 2004 10:06:00 GMT

Justin Rogers: What does conditional matching really mean in a regular expression?
Justin Rogers: The not so basics of NOT!
Darren Neimke: Cleaning a list perf. test
Darren Neimke: The sugary synax we love... Lookaround

To note both of my posts are on reduction. Taking advanced syntax features and turning them into more basic syntax that may be more verbose but requires a lighter support of the regular expressions standard. Darren's post start with a killer reason for using look-around assertions. I assert that any expression can be rewritten without a look-around assertion and I've been on a rampage trying to rewrite all of Darren's and Michael's expressions and removing any assertions in the process.

Darren's "Killer Reason for LookAround" posting has been haunting me

Justin Rogers — Thu, 05 Aug 2004 02:32:00 GMT

Darren's Post: http://blogs.regexadvice.com/dneimke/archive/2004/08/03/1432.aspx

Every time he comes up with a posting like the above I get an instant message of some sort or another with a quizzical question, “Hehe, you want to be unproductive today!” or something similarly intriguing. That is how I was introduced to the killer reason for a lookaround challenge. I have to say, I can't find one. At this point it is apparent that look-around expressions might just be a shortcut for a more verbose expression. I've managed to convert nearly all of my library and many other's libraries of look-around expressions to something either simpler/more complex that was not a look-around expression, but instead a normal expression not containing assertions.

Based on these concepts we kind of changed the rules a bit. The new rules stated that we needed to find a place where assertions would provide better performance. And so I started to extrapolate some conditions that would help increase our chances of finding a great case for assertions.

Create a simple bounding match with a start marker and an end marker where marker stands for some pattern or literal.
Between the start and end markers create a relatively complex matching pattern that in many cases would take a long time to execute.
Now assure that the most probably input scenario will match the start marker, and most or all of the complex expression, but not the end marker.

Hopefully you see where I'm going here. Rather than having a huge inline expression to match the conditional rules in the middle in a scenario where the end tag is more likely to cause the pattern to fail, instead apply the complex conditional rules only after matching the start and end tags. We still can't think of anything really stellar, but at least now we have some patterns that do provide better performance using assertions over a normal expression.

I also have another pattern that I don't think can really be done without assertions. However, they can't be done because an assertion is the only way to introduce the (NOT) operator in regular expressions. Well, not the only way, because you can have negative character classes that have a kind of (NOT) operator but they don't work at the same level. They work on characters and can't work on patterns of characters. Here are the two input strings the embody my pattern:

[foo][bar][/bar][/foo]
[foo][bar][/foo][/bar]

Basically, I want to look for start and end groups that cross one another. This pattern could be used to find errors in some proprietary sound mixing format where each sound sample should start and end, but never overlap in time sequence with another. Maybe this is a valdiator tool that gets run at the end of the entire process but allowing the mixing of sounds early on is something that has to be accounted for. Anyway, I want to be able to match one of the patterns, the second one, and ensure that I'm not matching an extended case of the first.

How can I say match [foo][bar][/foo], but ensure that [/bar] doesn't occur preceeding [/foo]? Well that is an assertion. A look-behind assertion to be precise. Then how do I say match [/bar] following [/foo]. Well that is easy, no assertions are needed there, just a normal match literal. Note: This is a simplification of the pattern. There may be any number of whitespace or other characters between some of the tags which is why the look-behinds are necessary.

"\\[(\\w+?)\\]\\[(\\w+?)\\](?<!\\[/\\2\\])\\[/\\1\\]\\[/\\2\\]"

Now, the astute user might point out with the two input strings, becuase we have the following [/\2] pattern the first string won't match. Remember we might be running this over a string of the form [foo][bar][/bar][/foo][/bar] for all we know. In other words we want the pattern to be more resilient to failure. Even with this type of pattern, there is always something else you can use in place of the assertions. Conditional matches for instance could be used. If I match the second end tag before the first end tag then I could conditionally choose to search for the beginning of the string as the next character versus the second end tag. This basically forces a failure.

"\\[(\\w+?)\\]\\[(\\w+?)\\](\\[/\\2\\])?\\[/\\1\\](?(3)^|\\[/\\2\\])"

If you think you might have some patterns that are impossible without assertions then toss them into my comments. I'd be glad to play around and see about converting them to not use assertions. So far everything I've come up with is bust. Some other popular regex bloggers are coming to the same conclusions as well. Wayne King had an <img> matcher that relied on look-behind but then realized a simple expression would do. Darren has been wracking his brains for days as have I.

Bringing an end to the posts on decompositions of numeric ranges into validating regular expressions.

Justin Rogers — Tue, 25 May 2004 07:50:00 GMT

I've posted quite a few items covering the process of decomposition. Most of the examinations are textual only and cover the process of generating decompositions by hand. I've since issued a challenge for the creation of an algorithm that would automatically handle a given range and return the decomposition in regular expression format that could be used to validate input in the range. I talked through a sample algorithm that had some issued, then covered these issues, and finally posted my own algorithm in C# that creates a matching alternation group that isn't minimally sized, but works for the give range. Have a look.

The Beginning: Value range parsing using Regular Expressions. Breaking down the dotted decimal IP byte processing.
Follow-up on ranges: 0 through N ranges are interesting, but what about M through N ranges.
Some Oddities that are hard to handle: That range algorithm was more difficult than I originally pointed out due to some strange oddities.
The post reference the article and algorithm: An Algorithm has been prepared, I'm linking it into an article so you don't have to look at it if you don't want. It is a spoiler.

Examination of regex range validation using lower and upper bound values

Justin Rogers — Sun, 23 May 2004 02:44:00 GMT

A programming challenge? Maybe a bit of one. If nothing else it is a neat algorithm and examination of generating capture groups that will handle numbers within ranges. The first posting I did on this I examined the generation of 0 through N ranges and ended with the examination of parsing 0-255 or a byte value. In this posting I examine using a lower bound that is not 0, how many decompositions are required to validate such a range, and a general purpose algorithm for doing so.

0 through N ranges are interesting, but what about M through N ranges.

Generic, Cancellable, Asynchronous operations? Yeah, I'll blog about that.

Justin Rogers — Sun, 23 May 2004 00:57:00 GMT

Just code today my friends. The design is simple, create a framework that allows running an asynchronous delegate on the thread pool in a manner where it can be cancelled and any exceptions can be handled. We use the same BeginInvoke/EndInvoke model as the rest of the asynchronous programming models under the framework. Our generic classes allow for the creation of a new generic asynchronous result object for each piece of work we want to do. To fully define a generic async operation we need to specify some from of input, the type of the output, and we can even strongly type the async state object.

ar = GenericCancellableOperation<RegexInput, int, Match>.BeginInvoke(
    new RegexInput(regex, "555"),
    new GenericWorkDelegate<Match, RegexInput>(RegexWorkDelegate),
    new AsyncCallback(MatchComplete),
    counter++
);

The above is a sample usage that does the same thing as my previously defined asynchronous regular expression runner. We can no longer specify entire strings of input parameters, so we have to wrap them all in a single object. Here I've used RegexInput to define the Regex and input to match against. We still use the old AsyncCallback model, even though we could strongly type that as well. In fact, BeginInvoke and EndInvoke still use IAsyncResult instead of more strongly typed equivalents. The GenericWorkDelegate will always match the input and return types for the operation generic, basically allowing us to delegate whatever work needs to occur back to your code. It gets wrapped with all of the protective stuff automatically. You still can't run arbitrary code, because any old fool could wrap a try...catch in their delegate and handle the ThreadAbortException that would normally terminate the operation.

using System;
using System.Threading;

public delegate ReturnType GenericWorkDelegate<ReturnType, InputType>(InputType input);

public class GenericCancellableOperation<InputType, AsyncStateType, ReturnType> {
    public class GenericAsynchronousResult : IAsyncResult {
        // Generic State Parameters
        internal AsyncStateType asyncState = AsyncStateType.default;
        internal InputType input = InputType.default;
        internal ReturnType output = ReturnType.default;
        internal GenericWorkDelegate<ReturnType, InputType> workCallback = GenericWorkDelegate<ReturnType, InputType>.default;

        // Non generic state
        internal bool complete = false;
        internal bool completedSynchronously = false;
        internal bool cancelled = false;
        internal ManualResetEvent waitHandle = null;
        internal AsyncCallback callback = null;
        internal Thread currentThread = null;
        internal Exception innerException = null;
        internal Object lockObject = new Object();

        internal GenericAsynchronousResult(InputType input, GenericWorkDelegate<ReturnType, InputType> workCallback, AsyncCallback callback, AsyncStateType state) {
            this.asyncState = state;
            this.input = input;
            this.callback = callback;
            this.workCallback = workCallback;
            this.waitHandle = new ManualResetEvent(false);
        }

        public object AsyncState { get { return this.asyncState; } }
        public bool CompletedSynchronously { get { return this.completedSynchronously; } }
        public bool IsCompleted { get { return this.complete; } }
        public WaitHandle AsyncWaitHandle { get { return this.waitHandle; } }

        public AsyncStateType TrueAsyncState { get { return this.asyncState; } }
        public InputType Input { get { return this.input; } }
        public ReturnType Output { get { return this.output; } }

        public bool Cancel() {
            lock(lockObject) {
                if ( this.cancelled || this.complete ) {
                    return false;
                }

                this.cancelled = true;
                if ( this.currentThread != null ) {
                    this.currentThread.Abort();
                }
            }

            this.waitHandle.Set();
            return true;
        }

        internal void Complete() {
            lock(lockObject) {
                if ( this.complete || this.cancelled ) {
                    return;
                }

                this.complete = true;
            }


            this.waitHandle.Set();
            if ( callback != null ) {
                callback(this);
            }
        }
    }

    public static GenericAsynchronousResult BeginInvoke(
        InputType input,
        GenericWorkDelegate<ReturnType, InputType> workCallback,
        AsyncCallback callback,
        AsyncStateType state)
    {
        GenericAsynchronousResult result = new GenericAsynchronousResult(input, workCallback, callback, state);
        if ( !result.complete ) {
            ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadPool_WaitCallback), result);
        }

        return result;
    }

    private static void ThreadPool_WaitCallback(object state) {
        GenericAsynchronousResult result = state as GenericAsynchronousResult;

        if ( result != null && !result.cancelled ) {
            result.currentThread = Thread.CurrentThread;

            try {
                result.output = result.workCallback(result.input);
            } catch (ThreadAbortException) {
                Thread.ResetAbort();
            } catch (Exception exc) {
                result.innerException = exc;
            } finally {
                result.currentThread = null;
                result.Complete();
            }
        }
    }

    public static ReturnType EndInvoke(IAsyncResult ar) {
        GenericAsynchronousResult result = ar as GenericAsynchronousResult;

        if ( result != null ) {
            result.AsyncWaitHandle.WaitOne();
            if ( result.innerException != null ) {
                throw result.innerException;
            }
            return result.output;
        } else {
            throw new Exception("EndInvoke was called with the wrong async result");
        }
    }
}

I still don't find this as useful as the regex only version. I think adapting the code to the particular asynchronous operation you are working on is most sufficient. In the case of regular expressions, you could even embed the ability to abort the problem within the lexical scanner, thus removing the necessity of thread aborts and exceptions. In fact for something like an interpreter aborting as an embedded instruction is the best way to go about things. For now, we don't have the ability to modify the construction of regular expressions under .NET and we can't embed such abort instructions, so we'll have to live with little hacks.

Asynchronous Regular Expressions using the ThreadPool and a cancellation model.

Justin Rogers — Sat, 22 May 2004 07:40:00 GMT

There are probably numerous ways to shoot holes in this class, but this is a 30 minute attempt at providing an asynchronous framework for running regular expressions. The crux of the model is to allow for cancellation of long-running expressions that might otherwise have a negative impact on your application or web server.

You need to start with an IAsyncResult implementation that supports the general asynchronous infrastructure. We'll also have a bunch of extra information for the regular expression work, namely an expression and input string. What I've come up with so far supports all of the features I need including cancellation, full reporting of passed in procedures on the async object for later processing of the work item, and fairly decent protection against the internal members controlling the asynchronous operation.

public class AsynchronousRegexResult : IAsyncResult {
    internal object asyncState = null;
    internal Regex expression = null;
    internal Match match = null;
    internal string inputString = null;
    internal bool complete = false;
    internal bool completedSynchronously = false;
    internal bool cancelled = false;
    internal ManualResetEvent waitHandle = null;
    internal AsyncCallback callback = null;
    internal Thread currentThread = null;

    internal AsynchronousRegexResult(Regex innerExpression, string inputString, AsyncCallback callback, object state) {
        this.asyncState = state;
        this.expression = innerExpression;
        this.inputString = inputString;
        this.callback = callback;

        if ( this.expression == null || this.inputString == null ) {
            this.complete = true;
            this.completedSynchronously = true;
        }
        this.waitHandle = new ManualResetEvent(this.completedSynchronously);
    }

    public object AsyncState { get { return this.asyncState; } }
    public bool CompletedSynchronously { get { return this.completedSynchronously; } }
    public bool IsCompleted { get { return this.complete; } }
    public WaitHandle AsyncWaitHandle { get { return this.waitHandle; } }

    public Regex Expression { get { return this.expression; } }
    public string Input { get { return this.inputString; } }
    public Match Result { get { return this.match; } }

    public bool Cancel() {
        if ( this.cancelled || this.complete ) {
            return false;
        }

        this.cancelled = true;
        if ( this.currentThread != null ) {
            this.currentThread.Abort();
        }
        return true;
    }

    internal void Complete() {
        this.complete = true;
        this.waitHandle.Set();

        if ( callback != null ) {
            callback(this);
        }
    }
}

Three additional methods are needed to make this work. First, we need a BeginInvoke to launch our operation into the thread pool and an EndInvoke to retrieve the results. We don't really need the EndInvoke, but it builds in semantics for waiting on results if they aren't already available. Finally, the ThreadPool_WaitCallback will be the protected method that enables the true cancellation semantics and the ability to run our expressions.

using System;
using System.Threading;
using System.Text.RegularExpressions;

public sealed class AsynchronousRegex {

    // Removed result class for brevity, but it is a public nested class.

    public static IAsyncResult BeginInvoke(Regex innerExpression, string inputString, AsyncCallback callback, object state) {
#if DEBUG
        Console.WriteLine("AsynchronousRegex.BeginInvoke::Enter");
#endif
        AsynchronousRegexResult result = new AsynchronousRegexResult(innerExpression, inputString, callback, state);

        if ( !result.complete ) {
#if DEBUG
            Console.WriteLine("AsynchronousRegex.BeginInvoke::ThreadPool Queue");
#endif
            ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadPool_WaitCallback), result);
        }

#if DEBUG
        Console.WriteLine("AsynchronousRegex.BeginInvoke::Leave");
#endif
        return result;
    }

    private static void ThreadPool_WaitCallback(object state) {
#if DEBUG
        Console.WriteLine("AsynchronousRegex.ThreadPool_WaitCallback::Enter");
#endif
        AsynchronousRegexResult result = state as AsynchronousRegexResult;

        if ( result != null && !result.cancelled ) {
#if DEBUG
            Console.WriteLine("AsynchronousRegex.ThreadPool_WaitCallback::Setting Current Thread");
#endif
            result.currentThread = Thread.CurrentThread;
#if DEBUG
            Console.WriteLine("AsynchronousRegex.ThreadPool_WaitCallback::Gathering Match");
#endif
            try {
                result.match = result.expression.Match(result.inputString);
            } catch (ThreadAbortException) {
#if DEBUG
                Console.WriteLine("AsynchronousRegex.ThreadPool_WaitCallback::Thread Aborted, Resetting");
#endif
                Thread.ResetAbort();
            } finally {
                result.currentThread = null;
            }
#if DEBUG
            Console.WriteLine("AsynchronousRegex.ThreadPool_WaitCallback::Completing Asynchronous Result");
#endif
            result.Complete();
        }
#if DEBUG
        Console.WriteLine("AsynchronousRegex.ThreadPool_WaitCallback::Leave");
#endif
    }

    public static Match EndInvoke(IAsyncResult ar) {
        AsynchronousRegexResult result = ar as AsynchronousRegexResult;

        if ( result != null ) {
            result.AsyncWaitHandle.WaitOne();
            return result.match;
        } else {
            throw new Exception("EndInvoke was called with the wrong async result");
        }
    }
}

As mentioned this class is not 100% thread-safe, but will work for the most part. I ran it for a couple of hours and didn't run into any troubles. Not a multi-threaded system though so concurrent access issues wouldn't surface easily (context switching might, but in most cases no).