This is the mail archive of the 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_AllocBytesChec ked)

"Boehm, Hans" <> 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
until runtime.

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

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
always necessary.

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

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