MIPS deadlock bug fix

Slegers, Walter Walter.Slegers at nl2.vdogrp.de
Tue Jan 9 23:52:51 PST 2001

Hello Godmar,

It's good to know that someone is listening who can do
something with the comment.

>> With this fix I seem to have no more unexpected deadlocks.
>> Just to be on the safe side, does anyone know of similar
>> "supposed to be atomic" operations?
> Not that, but we've repeatedly pointed out that the CMPEXCH
> in locks.c in broken.  By now, we've wasted more time discussing
> this subject than it would take to just remove, so below it goes.
> I didn't put in your generic version in order to encourage
> you and others to look through your MIPS manual and submit a
> working md version. We don't want to make kaffe too easy to port ;-)

I known my MIPS manual by hart. Unfortunately, an original R3000
processor core has no instructions to provide an atomic exchange or
an atomic compare and exchange. I there were, I definitely would have
used that as that seemed to be the proper action. Maybe an R4000
(which has a store conditional instruction) might be able to do this,
but on an R3000 you are really out of luck. If I hadn't used the
"jthread_suspendall" call then I would have to switch to kernel mode
to disable interrupts....


I agree that this is better than the broken macro. It would have saved me
the time I spent in finding the problem. Yet COMPARE_AND_EXCHANGE
is only defined for i386 architectures and ATOMIC_EXCHANGE is never
defined (at least in the Kaffe 1.0.6 sources). So a working backup solution
might not be that bad. And some embedded/old processor cores simply
don't have these very convenient instructions.

Kind regards,
    Walter Slegers

This Mail has been checked for Viruses
Attention: Encrypted Mails can NOT be checked !


Diese Mail wurde auf Viren ueberprueft
Hinweis: Verschluesselte Mails koennen NICHT geprueft werden!

More information about the kaffe mailing list