[kaffe] locks patch

[Helmer Krämer]

On Wed, 2 Jul 2003 06:28:54 -0700 (PDT)
Dalibor Topic <robilad@yahoo.com> wrote:

> 
> --- Helmer Kr_mer <hkraemer@freenet.de> wrote:
> > 
> > Hi,
> > 
> > I've attached a small patch that fixes some issues
> > related to the handling of locks in kaffe. Review
> > and comments appreciated ;)
> 
> applies but doesn't build against the latest CVS sources :( when I make kaffe,
> I get:
> 
> ../../../kaffe/kaffe/kaffevm/exception.c: In function `unwindStackFrame':
> ../../../kaffe/kaffe/kaffevm/exception.c:371: too few arguments to function
> `_slowUnlockMutexIfHeld'
> gmake[3]: *** [exception.lo] Error 1
> 
> The line is 
> 	/* If method found and synchronised, unlock the lock */
> 	if (obj != 0 && (meth->accflags & ACC_SYNCHRONISED) != 0) {
> ->		_slowUnlockMutexIfHeld(&obj->lock, (void*)frame->fp);
> 	}
> 
> and adding &obj->heavyLock doesn't work either ...

should be _slowUnlockMutexIfHeld(&obj->lock, (void*)frame->fp, 0);

Seem to be doing too many things in parallel, lately :(
 
> > Stuff contained in the patch:
> > 
> > * the specialLocks array is removed; special locks whose heavyLock
> >   should not be gc_malloc'ed are now of type struct _iStaticLock,
> >   which contains a struct _iLock field. 
> > * _slowUnlockMutex correctly handles !STACK_GROWS_UP
> > * _slowUnlockMutexIfHeld no longer allocates a heavyLock if that's
> >   unnecessary
> > * _releaseLock and _acquireLock have been removed since they don't
> >   seem to be used anywhere
> > * _lockMutex uses jthread_on_current_stack to detect recursive
> >   invocations
> 
> sounds very good (and looks nice in the patch;). 
> 
> On a side note, I'd prefer a change of _something identifiers to
> internalSomething, since identifiers starting with _ are reserved for the C
> compiler/library. What do you think?

As long as we still know what is doing what afterwards,
I don't have a problem with it ;) Should I post an updated
patch?

Greetings,
Helmer