RE: [Pnet-developers] re: [DotGNU] Memory usage on an embedded system

[Thong \(Tum\) Nguyen]

> -----Original Message-----
> From: Gopal V [mailto:address@hidden
> Sent: Thursday, 21 October 2004 5:28 p.m.
> To: Thong (Tum) Nguyen
> Cc: address@hidden
> Subject: RE: [Pnet-developers] re: [DotGNU] Memory usage on an embedded
> system
> 
> Hi,
> 
> > > I had to make a few changes to the thin-locks to
> > make
> > > it work. I move the GetObjectLockWordPtr out of
> > the
> > > locked code to prevent a dead lock. (tum: is that
> > > correct ?).
> >
> >
> > No!!!  The dead lock needs to be traced and fixed.
> > That lock is required :\
> 
> But that *is* the deadlock -
> 
> ILLockWord
> CompareAndExchangeObjectLockWord(ILExecThread *thread,
> 
> ...
>       /* Lockdown the monitor hashtable */
> 
> ILMutexLock(thread->process->monitorSystemLock);
> 
>        lockWordPtr = GetObjectLockWordPtr(thread,
> obj);
> 
> 
> GetObjectLockWordPtr waits on the same lock *after*
> it has been locked by the statement above.
> 
> See log attached :)
> Gopal
> 
> 
> 


You didn't tell me it was in CompareAndExchangeObjectLockWord :-\!  That
lock is there for a reason - GetObjectLockWordPtr is public and can be
called directly (not via CompareAndExchange...) and if you remove that lock,
you will corrupt the lockword table.

The fix should be a matter of swapping the order of the following statements
in CompareAndExchangeObjectLockWord:

        /* Lockdown the monitor hashtable */
        ILMutexLock(thread->process->monitorSystemLock);

        lockWordPtr = GetObjectLockWordPtr(thread, obj);


Thin lock lockword pointers are "stable" (don't change for the life of the
object) so it should be safe *not* atomically get the ptr and change the
underlying value.  This was originally how it was but I think I must have
swapped them to save the thread having to fully releasing the mutex twice
(speed issues..) but I forgot that ILMutexes aren't re-entrant.

Regards,

^Tum