This is the mail archive of the
mailing list for the Java project.
Re: Segment Register thread descriptor (was Re: Jv_AllocBytesChec ked)
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: Re: Segment Register thread descriptor (was Re: Jv_AllocBytesChec ked)
- From: Ulrich Drepper <drepper at redhat dot com>
- Date: 05 Jan 2001 18:13:51 -0800
- Cc: tromey at redhat dot com, "'Bryce McKinlay'" <bryce at albatross dot co dot nz>, "'java-discuss at sources dot redhat dot com'" <java-discuss at sources dot redhat dot com>, "MOSBERGER, DAVID (HP-PaloAlto,unix3)" <davidm at hpl dot hp dot com>, Benjamin Kosnik <bkoz at redhat dot com>
- References: <140D21516EC2D3119EE700902787664401E3A807@hplex1.hpl.hp.com>
- Reply-To: drepper at cygnus dot com (Ulrich Drepper)
"Boehm, Hans" <email@example.com> writes:
> I'm not proposing to add a replacement for pthread_getspecific, since I'm
> not sure there is a sufficiently general one. I'm proposing to add enough
> so that I can hash on a thread id myself, since that often seems to be
> appreciably faster than the current scheme.
If you only want to have a numeric value that is fine. Adding more
functions is also fine if you can live with the restrictions of
exposing internals. But you must also be aware of the limitations of
most thread IDs: they get reused or not. Both ways you might have
problems and which it is possibly cannot be determined, at least not
> At a minimum, you could expose the thread register when it exists. That
> would largely preserve thread library independence, since the register
> pretty much has to be defined as part of the ABI, and any thread library
> that doesn't use it would be sacrificing performance.
What would the thread register be used for? Is it a pointer, is it
some other numeric value. Or as in the x86 case, what is if it is not
really accessible? Similarly on Alpha where the thread pointer is
retrieved through a (very fast) PAL code call.
> Right. But isn't that a fact of life for almost anything related to
I would imagine that these interfaces are used not only by programs
which are written using the thread library. The thread library itself
needs this kind of functionality and you might also want to write
programs consisting of separate processes with shared memory this way.
Unlike when threads there is actually the possibility to achieve
> > this is a problem since it means that programmers can make errors
> > without seeing them. If somebody has access only to platforms where
> > the spinlock is not needed errors might slip in unnoticed. These kind
> > of things must be automated.
> Again, it seems to me this is unavoidable. You need to test on different
> kinds of platforms. We already have greatly varying memory models
> (apparently even within the X86 line), which require that. And you can omit
> volatile all over the place if you have the right compiler. And byte writes
> are atomic until you find an old Compaq Alpha. For this one you could at
> least provide an option to test with generic code, even if the hardware
> doesn't require it.
If there are ways which allow avoiding these pitfalls they should be
taken. You are a bit too much in this corporate software development
thinking. 99% of all the people writing free software have no access
to more than one architecture. If the code they write is not right
away usable by other (at least to some degree) it will not be picked
up. This is why I said the usage of the new features should be
fool-proof. Then the person writing the code will get it right.
> > Not a problem. Associate a lock with the whole array. But of course
> > you can say this is not good and you want to lock individual blocks in
> > the array. This plays again in the area of not having to define too
> > many interfaces. Everybody wants something different.
> Which is why I would prefer to let the user declare the locks.
Not in all cases. This is an optimization which certainly is not
> Interesting. Have they published/admitted to anything? This would
> certainly affect correctness of the garbage collector in libgcj.
The default mode is certainly compatible. I don't know what you have
to do to get the relaxed memory access model. Intel has lots of P4
docs on their web site. I haven't really looked. Maybe it's all only
available now in preparation for the next generation, who knows.
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------