[Opensim-dev] .NET / Mono lock(obj) statement

[Tedd Hansen]

Today I learned something new and useful. This doesn't make sense at all.

I'd expect thread to wait on second attempt to lock object. Because I could
be planning to unlock object from another thread (you know all this talk
about proper use of multiple processors) effectively releasing the waiting
thread. Or even encounter the lock in some far away galaxy class where I
choose to do a "bool result = Montior.Enter(LockedObject, TimeoutPeriod);"
and move on once TimeoutPeriod has passed.
What happens when you lock, then you lock, then you UNLOCK, <period where
you think you are locked but really are not>, then you UNLOCK AGAIN (but
it's already unlocked)?
Then we have the thread pools and their role in events and such. You never
know what thread will come knocking.

So maybe you can't block on second lock within same thread, but I'd suggest
avoiding it. Seems more reasonable to design the app without nested locks on
same object.

BR, 
Tedd

-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mike Dickson
Sent: 14. januar 2009 15:12
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] .NET / Mono lock(obj) statement

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

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev