This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


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

Re: new ToDo list


On 8 Nov 2000, Ulrich Drepper wrote:

> Date: 08 Nov 2000 14:08:27 -0800
> From: Ulrich Drepper <drepper@redhat.com>
> Reply-To: Ulrich Drepper <drepper@cygnus.com>
> To: Britton <fsblk@aurora.uaf.edu>
> Cc: GNU libc testers <libc-alpha@sourceware.cygnus.com>
> Subject: Re: new ToDo list
> 
> Britton <fsblk@aurora.uaf.edu> writes:
> 
> > I am interested in working on the prioity ceiling functions, if someone
> > more experienced like Kaz isn't already planning to do so.
> 
> The thread stuff is a bit more complicated.  I have honest plans to
> scratch the entire existing implementation and start from ground.
> We'll hopefully get some more kernel support and with this a different
> and more efficient implementation is possible.  I haven't described
> this is detail in the ToDo list, sorry.
> 
> In the not too distant future I'll write to this list to call for
> volunteers for the rewrite.  One big company already signalled support
> so it hopefully will become reality.

I'm just waiting for an announcement; maybe I will have the opportunity
to do some of the work.

Nearly anything having to do with thread priorities requires kernel support.
Modifying thread priorities on the fly is potentially expensive. E.g. to
implement a feature whereby a thread that acquires a mutex has its priority
elevated to that of the mutex requires a call into the kernel each time the
mutex is acquired and released. It's not clear that it's worth implementing
this in anything other than a real-time OS that runs over bare hardware.

It would be nice if there was a memory area where one could
twiddle thread parameters without having to actually trap into the kernel.

This could be done without giving each thread a different memory map, if
information for all threads was mapped into the common map; I understand Linus
has been resistant to memory mappings that are specific to a thread, with
justification.

One useful thread parameter would be a ``don't preempt this thread'' flag which
could be used as the sole basis for a critical region on a single processor,
and with a simple spinlock would extend to multiple processors, similer to
the way the kernel does it.


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