Re: New pthreads library

[Ulrich Drepper <drepper@cygnus.com>]

Roland McGrath <roland@frob.com> writes:

> Do you say this based on the presumption that one must be able to easily
> tell whether a given pointer is a valid thread ID or not?

This is what the specification says for some of the functions
(pthread_join).  We can of course choose to ignore it but it's a bit
more problematic.  Just assume this code:

	pthread_create (&t, ...);
	pthread_join (t, ...);

There is no guarantee that the newly created thread already terminated
when the join operation starts.  It might even be that there is a new
thread with this thread handle and so the join is for a different
thread.

> I believe this weaker specification allows those calls to crash when given
> an invalid thread ID.

At least the definition is unspecified.

> That seems reasonable enough to me.  The main downside to this is the need
> to resize the indirection table as the number of threads grows.

Well, there are techniques available to reduce the costs of this.

> For the x86 segment register trick, you can do a very similar thing just
> with another special declaration.  Either:
> 
> 	extern struct thread_internal *_self asm("%gs:0");
> 	inline struct thread_internal *thread_self() { return _self; }
> 
> or:
> 
> 	extern struct thread_internal _self asm("%gs:0");
> 	inline struct thread_internal *thread_self() { return &_self; }

The second case does not work (try it, you get a wrong use of %gs) and
overall this is not the same.  In your case the compiler has to waste
a register for the thread data pointer.  If you look at the code in
linuxthreads you'll see that I've written the code so that I directly
access the thread data through the %gs register with an non-zero offset.

This makes a big difference for this stupid architecture.  If you can
find a way to modify your code appropriate it's certainly better.  But
I haven't found a possibility.

> Hmm.  On the contrary, I would think that the OS-specific kernel interface
> part would be mostly machine-independent (since the OS takes care of
> abstracting the state it maintains).  Conversely, some implementation
> models do preemptive thread context switching purely in user mode (e.g. the
> scheduler activations model); so the "user part" is then responsible for
> the highly machine-dependent details of saving a preempted user thread's
> state and restoring previously saved context.

Well, yes, of course this part is also dependend.  But there is
already functionality to do this in the libc API (swapcontext etc).

> But it can easily be a decision made at source level via sysdeps
> typedefs/macros whether to include a "kernel thread" data structure
> directly in the pthread data structure or to use a pointer to a
> separately allocated structure.

Makes sense.  But we should forsee this right from the beginning.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------