This is the mail archive of the java-discuss@sources.redhat.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: Segment Register thread descriptor (was Re: Jv_AllocBytesChecked)


Shouldn't glibc include a header file that defines things like atomic add,
compare_and_swap (several variants, unfortunately, the API design is
nontrivial), a way to do a store with release semantics, and a fast way to
get some sort of thread identifier? 

It seems to me that libgcj is only one of many potential clients for this.
Replicating it in all of them seems wrong.  Something like this is already
replicated in two pieces of code I helped write: the garbage collector, and
the SGI STL. (See stl_threads.h in libstdc++-v3. It actually looks like
there is a second implementation in libstc++-v3 in atomicity.h.  What a
mess.)  I was under the impression that the Itanium ABI also standardizes
some of these things?  Anybody know what it says?

It's very hard to write high performance multithreaded code without these
things.  It seems to me it really belongs in the C library, even if the
standards don't mandate it.

I'm not quite sure what to do in environments with proprietary libc
implementations.  But getting this stuff right in glibc might convince
others to follow.

Hans

> -----Original Message-----
> From: Bryce McKinlay [mailto:bryce@albatross.co.nz]
> Sent: Thursday, January 04, 2001 4:57 PM
> To: tromey@redhat.com
> Cc: 'java-discuss@sources.redhat.com'
> Subject: Re: Segment Register thread descriptor (was Re:
> Jv_AllocBytesChecked)
> 
> 
> Tom Tromey wrote:
> 
> > That is the issue.  I imagine we'd have to get RMS to sign 
> off on the
> > exception (if the code is in glibc).  This seems unlikely.
> 
> Well, if that is that case then case silly licensing trivialities are
> once again preventing us from writing the best possible code.
> 
> > How long will it be until these are the most common 
> systems?  If it is
> > going to happen soon anyway, then I'm not too conerned.
> 
> I don't think you understand the issue here. Importing the sysdeps
> directory from linuxthreads would allow us to implement 
> faster locking by
> not having to call both pthread_self() and 
> pthread_mutex_lock() for every
> monitor lock. There are two primitives that are important here - the
> compare-and-exchange thread synchronization primitive, and 
> current thread
> lookup (which on many architectures is as simple as loading from a
> register).
> 
> If we import the linuxthreads sysdeps, we can inline these into our
> monitor lock/release code, making it much faster. We'll also
> automatically get the definitions for these primitives on 
> every platform
> that linuxthreads supports. If we don't, we'd have to waste time
> reimplementing the primitives ourselves for each architecture (or else
> use standard pthreads functions as fallback). Since there is 
> presumably
> only one way to implement a correct compare-and-exchange on each
> architecture, the implementations will no doubt be copied 
> directly from
> linuxthreads. At what point does this become a licensing violation?
> 
> regards
> 
>   [ bryce ]
> 
> 

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