thin locks (was Re: libgcj/117:)

Fri Dec 10 14:17:00 GMT 1999

>> Sure. But reimplementing linuxthreads functionality doesn't seem very
> feasible. If we need to rewrite specific parts espeically for libgcj we
> had better at least still be compatible with what linuxthreads is doing.
>> Note that the IBM JDK runs on linuxthreads too...
>
But why?
I don't believe that there's a compatibility requirement in the sense that
since every Java object can be a lock, there has to be way to extract a
pthread mutex that can be used to lock/unlock that object.
Mutual exclusion can be implemented solely at the compiler/run-time level
with whatever instructions the architecture provides, independent of the
underlying threading system. I would even claim that that's not a bad approach
at all, cause it gives your more control and is a lot more portable since it 
reduces the size of the glue layer you need from your underlying threading 
system --- moreover, it means that you're invoking your underlying system only
in the (hopefully) uncommon case.
You're right though that it would amount to a reimplementation in the sense
that it's providing the same functionality, optimized for a given application,
in a way that's more portable among different threading systems.
	- Godmar