[Opensim-dev] .NET / Mono lock(obj) statement
Mike Dickson
mike.dickson at hp.com
Wed Jan 14 14:11:33 UTC 2009
Even though it works in Java, IMO that's an example of poor design vis.
the locking protocol used. Again, I agree the spec may say that the
locking primitives should test for the thread doing the locking to avoid
a deadlock. Even that won't avoid a deadlock involving a cycles across
multiple objects.
Mike
On Wed, 2009-01-14 at 04:57 +0000, Diva Canto wrote:
> Hi everyone,
>
> Just got back from vacation to TP grief caused by extra locking
> introduced in 7982. The extra locking is all good, but it seems that
> certain things confuse the heck out of mono, so I thought I'd bring up
> the issue here -- I'm pretty sure this problem occurs in other places of
> the code too, so it's good to know what to expect. I'd certainly like to
> find out more about the .NET spec.
>
> Here's a simplified version of the problem:
>
> lock (a)
> {
> foo();
> }
>
> void foo()
> {
> lock (a)
> {
> ...
> }
> }
>
> (the real situation is a bit more complicated; foo() involves a
> delegate; but ignore that)
>
> In Java, this situation does NOT result in locking, because it's the
> same thread that's acquiring object a. I can't find the spec for .NET
> for this particular issue, but I'd be very surprised if it is different
> from Java. Nevertheless, mono was deadlocking here; Windows was not. I
> find the mono behavior very strange.
>
> Crista
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Mike Dickson <mike.dickson at hp.com>
ESS SW Platform Enablement
More information about the Opensim-dev
mailing list