This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: thin locks (was Re: libgcj/117:)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]