Re: Segment Register thread descriptor (was Re: Jv_AllocBytesChec ked)

[Ulrich Drepper <drepper at redhat dot com>]

"Boehm, Hans" <hans_boehm@hp.com> writes:

> As was pointed out by one of the other posters, there are some copyright
> issues.  We would like to be able to reuse at least the assembly sequences
> that are currently in various other libraries.   The license on the result
> should be sufficiently liberal that it does not discourage use.

And encourage even more exploitation of Free Software?  If a
specification is available the people who want to use the
functionality in non-free programs can write their own code.


> > 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.
> So long as this is effectively part of the ABI (e.g. on Alpha?) I don't
> think
> it matters.  The call in the library would expand to the PAL code call or
> whatever.
> If the call depends on the thread library, then there are some hard choices
> (which I would mostly push back to the client, with a reasonable default).

This is not really the point but I can answer this anyway.  On Alpha
there is room for one (thread) context-specific word.  It can be used
in whatever way, we store a pointer.  The PAL is lower than any OS,
it's more or less part of the CPU.  So it's not really part of the ABI
but everybody does it.


What I actually meant is that there are two uses of the thread IDs:
the first in a context, and all later ones.  On Alpha and some other
architectures it is stupid to use the same mechanism to retrieve the
thread ID more than once in a context.  Instead the value should be
stored locally.  On other architectures (IA-64, ...) this isn't
necessary.

I don't have appropriate macros in the thread library to handle this
since I couldn't think of any.  Instead I maintain the thread ID's
manually.  This is not optimal and would have to be abstracted out.


> I think you're giving to much credit to us corporate software developers.

Definitely not! :-)


> In many cases, it's not easy for us to test on competitive hardware either,

Why should you?  You only have to have access to the platforms you
care about.  And this definitely is the case.  Free Software packages
are different since they potentially have to run everywhere.


> though I do currently have the advantage that I can test on different HP
> hardware.  But I think I understand the problem.  I think in this case, the
> problem is fundamentally unsolvable;

At some level, yes.  But making the implementation (in this case this
atomicity library) more complicated can help to hide many differences.
Since the people writing the library do much more about this issue
it's much safer to put the burden on them.  Therefore a design goal
here should be to think about the most general solution even if this
means very complicated implementations (and compiler dependencies).

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------