thin locks (was Re: libgcj/117:)

[Godmar Back]

> 
> 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