This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: thin locks (was Re: libgcj/117:)
- To: jsturm at sigma6 dot com (Jeff Sturm)
- Subject: Re: thin locks (was Re: libgcj/117:)
- From: Godmar Back <gback at cs dot utah dot edu>
- Date: Fri, 10 Dec 1999 15:10:06 -0700 (MST)
- Cc: gback at cs dot utah dot edu, hboehm at exch dot hpl dot hp dot com, joerg dot brunsmann at FernUni-Hagen dot de, tromey at cygnus dot com, java-discuss at sourceware dot cygnus dot com
>
> 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