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.

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.

:) 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)?

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

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. ;-)

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!

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?)

@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.

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

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)

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

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.)

+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.

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.

@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.