This test also fails from time to time at the last assertion which
checks that thread used at the asynchonization of message processing
for both functions are not intersect. This seems to be caused by a
different thread scheduling strategy of mono which makes this visible.
However, the problem should also exist on CLR but is hard to be
reproduced. At first it was assumed that Thread.GetHashCode call is
the reason as MSDN states that Thread.GetHashCode is not garanteed to
be unique over the time. There it is recommended to use
ManagedThreadId instead.
However, this does not solve the problem. The problem comes from the
fact that both MakeSerial calls utilize the same thread pool
(according to Ralfs article
http://www.dotnetpro.de/articles/onlinearticle4233.aspx about
MakeAsync which should be similar for MakeSerial). So in fact the last
assertion do not match the assumption of using different thread pools.
This assumption could be simply made valid by passing different names
to both MakeSerial calls which will use different thread pools for
both functions ensuring that the last assertion did not fail.
This test fails some times at slower environments as the AutResetEvent
"_are" was reused even if it is already set for every received result
at the lambda expression defined at the TestFixture Setup procedure.
For this test the event will be alrady set for the first result-
Therefore the _are.WaitOne(4000) call will return already for the
first result. On fast machines there is enough time to let the second
result be received before the assertion about the receiving of both
results is checked.
However, on slow machines the second result may not be received fast
enough... To solve this a test local AutoResetEvent is created which
is signaled only when both results has been received. The assertion
part of the test is waiting now for this event.
This test fails sporadically some times at slower machines as the
sleeping seems to be no tlong enough to cause that for the next
incoming message another thread is used. It may also be that at mono
where this failing was observed has a faster thread scheduling letting
the same thread be reused again such that the 3rd thread is never
bothered. By increasing the sleep time to 20 ms this failure did not
appear again.
At second Thead.getHashCode was substituted by GetManagedId as MSDN
states that Thread.GetHashCode is not garanteed to be unique over the
time. There it is recommended to use ManagedThreadid instead.
Merge pull request #7 from kuniss/pull-requests

3 tests corrected