Re: Exposing gthreads, and making exceptions safe under cthreads

Re: Exposing gthreads, and making exceptions safe under cthreads

[Mike Stump]

> From: "Melissa O'Neill" <oneill@cs.sfu.ca>
> Date: Sat, 19 Sep 1998 23:55:28 -0700

> Given this situation, I propose that we expose the gthreads package
> to the user, rather than keep it internal to the compiler sources.

I don't know what you mean by this.  I think I am against this in all
cases.  If you want to expose the user to a new interface, expose them
to the standard posix interface, and implement that on top of mach and
bundle that in the compiler.

> If both the user and the compiler are using the same extension to
> cthreads to support multiple pieces of per-thread data, we can avoid
> the above problems.

Yes, lets do that, and lets use the extenion known as posix threads.

> And, if we expose the gthreads interface on all platforms, the
> change has the added benefit that anyone can write code for GCC
> using the gthreads package and know it'll run on whatever threads
> scheme is local to that architecture.

I can't begin to describe all of my horror at this suggestion.

> P.S. It's also possible to provide a replacement cthreads header that
> redirects cthreads names to gthreads names so that cthreads programs
> can transparently use the gthreads library instead, with zero work on
> the part of the user. But then you have to be sure that every module is
> using this header and not the system one, so this idea has pros and
> cons, whereas nothing above seems to have a downside.

This is another way to solve it that I think would be ok.  Or, do both.

Re: Exposing gthreads, and making exceptions safe under cthreads

[Melissa O'Neill]

Moments ago, I wrote:
> I certainly could alter my minimal wrapper for cthreads to use the POSIX
> threads function names and argument types (it's just changing gthread*
> to pthread* after all), but it wouldn't really be full POSIX threads.
> And, using the posix names might even be a worse mistake, since I'd be
> cluttering up the namespace so that people who *did* want to write a
> true POSIX threads package would get name clashes.

Actually, I suppose that if the above POSIX threads subset was in a
library that was linked with last, if the user had their own POSIX
threads library everything (including libgcc) would use that for
preference.

So, I guess I'm okay with having a POSIX-threads-subset library instead
of a gthreads library after all.

    Melissa.

Re: Exposing gthreads, and making exceptions safe under cthreads

[Melissa O'Neill]

I wrote:
>> Given this situation, I propose that we expose the gthreads package
>> to the user, rather than keep it internal to the compiler sources.

Mike Stump writes:
> I don't know what you mean by this.  I think I am against this in all
> cases.  If you want to expose the user to a new interface, expose them
> to the standard posix interface, and implement that on top of mach and
> bundle that in the compiler.

The standard POSIX interface would be excellent, but POSIX provides a
pretty rich thread model and feature set. My point was that we could
provide a *minimal* wrapper for ``the local threads scheme'' so that
you don't have to be on a system that has POSIX threads support to have
a thread-safe gcc. On systems with POSIX threads, gthreads would be
POSIX threads, plain and simple (there would be no library, per se, just
a header file redirecting the gthreads names to POSIX names). But on
systems with cthreads, gthreads would be cthreads. And so on...

This is basically what is done now in the gthr-* headers -- but the work
is hoarded by the compiler, so the user has to face the problem of the
variety of operating system thread packages themselves.

>> If both the user and the compiler are using the same extension to
>> cthreads to support multiple pieces of per-thread data, we can avoid
>> the above problems.
>
> Yes, lets do that, and lets use the extension known as posix threads.

Are you volunteering to do the work?  Or do you know of an existing
POSIX wrapper for cthreads?

I certainly could alter my minimal wrapper for cthreads to use the POSIX
threads function names and argument types (it's just changing gthread*
to pthread* after all), but it wouldn't really be full POSIX threads.
And, using the posix names might even be a worse mistake, since I'd be
cluttering up the namespace so that people who *did* want to write a
true POSIX threads package would get name clashes.

>> And, if we expose the gthreads interface on all platforms, the
>> change has the added benefit that anyone can write code for GCC
>> using the gthreads package and know it'll run on whatever threads
>> scheme is local to that architecture.
>
> I can't begin to describe all of my horror at this suggestion.

It would be wonderful if everyone had POSIX threads, but that isn't the
case right now. To me, this is just like the `libiberty' library -- it
provides a base-level of functionality. Users can and should use POSIX
threads when they either need more than that base level of functionality
or when they don't want to have code that'll run under whatever threads
scheme the operating system provides (including none at all).

I am not saying there should be a competing threads package for POSIX
threads with a competing interface. What I am saying is that it would
be cool to provide a wrapper for the local operating system threads package
that turns them into a minimal subset of POSIX threads (with gthread_*
rather than pthread_* names).

I don't see what is so horrific here. No one would be forced to use it,
no harm would be done.

     Melissa.

Re: Exposing gthreads, and making exceptions safe under cthreads

[Tom Tromey]

>>>>> "Martin" == Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

>> It seems to me that you could also implement this using a hash
>> table (or moral equivalent) in gthr-mach.h.  That is, nothing says
>> you must use the underlying thread system's mechanism for
>> thread-specific data.

Martin> Out of curiosity: How would this work?

Martin> It seems that you need *some* thread-specific state to get the
Martin> key (or whatever) to the hash table?

Yes.  You need a thread id to serve as the key for the table, and you
need a way to get the id of the currently executing thread.  If
cthreads doesn't have thread ids, then this scheme won't work.  This
seems to be a fairly common feature of thread systems, though.

Also, if you can't have some kind of cleanup run when a thread exits,
then this scheme will leak memory.

Tom

Re: Exposing gthreads, and making exceptions safe under cthreads

[Martin von Loewis]

> It seems to me that you could also implement this using a hash table
> (or moral equivalent) in gthr-mach.h.  That is, nothing says you must
> use the underlying thread system's mechanism for thread-specific data.

Out of curiosity: How would this work?

It seems that you need *some* thread-specific state to get the key (or
whatever) to the hash table?

Martin

Re: Exposing gthreads, and making exceptions safe under cthreads

[Tom Tromey]

>>>>> "Melissa" == Melissa O'Neill <oneill@cs.sfu.ca> writes:

Melissa> Currently, EGCS can't be compiled with the configure option
Melissa> --enable-threads under systems that use cthreads (aka mach
Melissa> threads).
Melissa> [ ... ]
Melissa> Cthreads only provides *one* pointer for thread-specific
Melissa> data.
Melissa> [ ... ]
Melissa> Given this situation, I propose that we expose the gthreads
Melissa> package to the user, rather than keep it internal to the
Melissa> compiler sources.

My two cents: this seems like a lot of effort to work around a design
bug in one obscure (to me!) thread system.

It seems to me that you could also implement this using a hash table
(or moral equivalent) in gthr-mach.h.  That is, nothing says you must
use the underlying thread system's mechanism for thread-specific data.

Tom

Re: Exposing gthreads, and making exceptions safe under cthreads

[Alexandre Oliva]

Melissa O'Neill <oneill@cs.sfu.ca> writes:

> It's also possible to provide a replacement cthreads header that
> redirects cthreads names to gthreads names so that cthreads programs
> can transparently use the gthreads library instead, with zero work on
> the part of the user.

It might be possible to install this header as a replacement of the
standard cthreads header (if there is one; I'm just guessing) in the
gcc include PATH, so that it wraps the standard cthreads header
redirecting the calls as appropriate.

Another alternative is to modify gcc so that it internally handles the
gthreads calls as built-ins or aliases to gthreads functions.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Exposing gthreads, and making exceptions safe under cthreads

[Melissa O'Neill]

Currently, EGCS can't be compiled with the configure option --enable-threads
under systems that use cthreads (aka mach threads). The problem is that
there is no `gthr-mach.h' file for this platform (gthr-*.h files are
used in frame.c to manage exception information).

The underlying problem behind the lack of a gthr-mach.h file is that
it's difficult to write an interface to cthreads that is both efficient
and doesn't impact the user's ability to maintain their own thread-specific
data.

Cthreads only provides *one* pointer for thread-specific data.  So, if
the application is using that pointer for its thread-specific data, any
library routines (such as those in libgcc) that want it for themselves
are out of luck.

Given this situation, I propose that we expose the gthreads package
to the user, rather than keep it internal to the compiler sources. If
both the user and the compiler are using the same extension to cthreads
to support multiple pieces of per-thread data, we can avoid the above
problems.  And, if we expose the gthreads interface on all platforms,
the change has the added benefit that anyone can write code for GCC using
the gthreads package and know it'll run on whatever threads scheme is
local to that architecture.

I have an implementation of the gthreads interface that's built on top
of cthreads that's ready to roll if we do this. If we don't do this, my
library is useless, since the user has to use cthreads and thus will
trample over that single per-thread pointer my library is relying on.

For gthreads on top of cthreads, I'd like to put the gthreads functions
into libgcc.a, since some functions can't be inlined and there's a
couple of static variables (although they could be put in a separate
library that's always linked). For other architectures, you just have
to install the current gthr-[whatever].h file as gthreads.h in the
include hierarchy, so it's hardly any work there, just a policy change.

Thoughts, opinions, etc. welcome...

     Melissa.

P.S. It's also possible to provide a replacement cthreads header that
redirects cthreads names to gthreads names so that cthreads programs
can transparently use the gthreads library instead, with zero work on
the part of the user. But then you have to be sure that every module is
using this header and not the system one, so this idea has pros and
cons, whereas nothing above seems to have a downside.