[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