<< The Stripper Pattern | Home | NH Prof New Feature: Error Detection >>

Challenge: multi threaded test failure

On one of my machines, I can consistently get the following test failure, because of an exception throw here:

image

As you can see, we get an ObjectDisposedException here, which cause the test to fail. There is only one problem with that:

image

We only dispose the queue manager on the dispose method, and that can only be called if the test itself was completed.

On the face of it, it looks like I am doing things correctly, but there is a bug here. The CLR’s threading semantics are not broken, even though on first glance it appears so.

As a side note, people keep asking me how I blog so much. This post is a perfect example. When I started writing this blog post, I was truly stamped. By the time I finished, I already noticed where the bug was and fixed it.

Can you tell?

Print | posted on Thursday, May 14, 2009 1:55 PM

Feedback

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 2:47 PM Benny Thomas

This is fairly easy, it is in the nature of QueueUserWorkItem.

This code is not execute before the test is finished because the test is so short. Maybe the testrunner uses QueueUserWorkItem and there is not a free pool thread available before the test is finished.

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 2:47 PM Jason

Line 68 (Assert "hello-1") should read "hello-0" since that will pull a message before the pooled work item will. The test fails at that point, the queue is disposed, and the pooled item exception fires.

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 2:58 PM Ayende Rahien

Benny,
No, we have synchronization there to prevent that.

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 2:59 PM Ayende Rahien

Jason,
Hurray!
You got that, and quite fast

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 3:03 PM Jason

:) Cool. At the start of the post, you mention that it fails consistently on 'one' of your machines -- is it a single core machine? I'm guessing that on a single core, the main program flow has more of a chance to execute before the threadpool spins up (whereas on a multicore, the queued item might execute before the main method, which appears to be the expected result of the test).

Did you resolve the issue by adding a Sleep or another event (Set on line 56, WaitOne on line 65)?

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 3:04 PM Stefan Wenig

For someone who's used to cleaning up after himself, you're surprisingly laissez-faire about putting critical exit-code into finally-blocks ;-)

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 3:16 PM Ayende Rahien

Stefan,
I am not sure that I follow.

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 3:23 PM Stefan Wenig

To prevent that situation, wait.Set and wait.WaitOne could have gone into a finally block. But I was just refering to your kitchen joke about being a former C++ programmer, not making a point about thread-safe programming. So I'm not going to argue about how good a solution that would be - I firmly believe that concurrency is evil since I first read about the double-checked locking pattern, itanium chipsets and memory barriers. ;-)

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 3:31 PM Benny Thomas

Aaah, my bad! My skills improve all the time.

But the error show that your asserts should be the last thing to do in the test.

So you should have 2 variables to catch the Message.Data until the run was over and then test if the where correct!

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 3:36 PM Ayende Rahien

Stefan,
I tend not to care much for stuff like that in a test.
If I need reliability in a test, I have a bad test.
And +1 on concurrency

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 4:12 PM Stefan Wenig

I was just kidding about the finally-part, you would obviously be more concerned with making the code work reliably than fail beautifully. But it goes to show how good you need to understand concurrent test code to make sure you're actually testing what you think you're testing.
This seems to be an integration test, and those tend to be just spot tests (meaning we should not even attempt to cover every possible execution path by creating every possible permutation of circumstances - for coverage we have unit tests).
Introducing timing as one of those circumstances further reduces the evidence an integration test provides. If you want to remove timing as a random variable, you'd have to manually sync the code and have it execute using various permutations of relative timing/waiting. Argh!
If you feel like punishing yourself, you might even try to create a framework that does the permutations automatically for sync points you sprinkle over your code. But then again, you'd probably have to be catholic to do that ;-)
(Am I making any sense?)

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 4:33 PM Ayende Rahien

You make sense, but I do not enjoy pain, so I wouldn't do it

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 4:57 PM Grimace of Despair

@Stefan

"If you want to remove timing as a random variable ..."

... you might consider CHESS? (research.microsoft.com/en-us/projects/chess/)

Never used it though.

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 5:05 PM Rafal

Should I draw the conclusion that catholics enjoy pain???

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 5:07 PM Stefan Wenig

You got that wrong: Catholism is not about enjoying pain, it's about deserving and enduring it.

Damned are those who strive for just happiness (from a Catholic standpoint as well as from a concurrency perspective)

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 5:09 PM Ayende Rahien

Thank goodness that I get to stand from the sidelines and wonder at all the things that exist in the world

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 5:12 PM Rafal

Damned you. Come on, have some pain. Go back to C++!

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 5:46 PM Stefan Wenig

GoD,

seems this is exactly what I was thinking about, thanks for the link!

not surprised that Peli de Halleux is on that team, that chess stuff does remind me of pex, which he presented at last year's lang.net. (on an unrelated note, he was the first person I watched rolling on shoes that can extend little wheels - how cool's that?)

now get this:
research.microsoft.com/en-us/people/jhalleux/
Before joining Microsoft, Peli earned a PhD in Applied Mathematics from the Catholic University of Louvain (2000-2004).

there must be something to my theory about Catholicism and concurrency ...

(and I discovered this just by accident, clicking on the name of the one team member I knew.)

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 6:31 PM Frank Quednau

+1 on the CHESS question. Since you do quite a bit with concurrently used code I was wondering whether you ever had a look at it.

Gravatar

# re: Challenge: multi threaded test failure 5/14/2009 10:30 PM Jeff Brown

The problem is that the Assert on "hello-1" fails which causes the test to fail before the queued user work item has had a chance to run so by the time it does run the queueManager has been disposed. The assumed order of execution is incorrect.

This is an example of why MbUnit v3 has a "Tasks" class to help with managing threads and processes in concurrent tests. It ensures the tasks get cleaned up properly when a test fails and that failures that occur within those tasks are all reported correctly. While that won't prevent test bugs like the above from occurring, it can make them a bit easier to diagnose.

Gravatar

# re: Challenge: multi threaded test failure 5/15/2009 2:43 AM John Smith

@stephan; @ayende

>But I was just refering to your kitchen joke about being a former C++ programmer

You'll have to cite 3 examples before we believe Ayende was a C++ programmer.

Comments have been closed on this topic.