lkml.org 
[lkml]   [1998]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Thread implementations...
From
Date
MOLNAR Ingo <mingo@valerie.inf.elte.hu> writes:

>
> also, wondering wether LinuxThreads could just use the same trick the
> kernel uses to access the 'current' thread, by doing %%esp & ~-8192 to
> access to 'start' of the kernel stack, there one could store the thread
> structure? [hm, not sure wether this works for LinuxThreads, in the kernel
> we can guarantee that the kernel stack is 8K aligned]

LinuxThreads already uses this. It is especially helpful for accessing
thread specific storage. Unfortunately the current implementation to
do that (not inline, two level array access, lots of error checking)
is bizarre enough that most of these gains are blowed away again.

I think it would be possible to turn pthread_getspecific() into a very
fast inline function, like e.g. Windows uses. pthread_getspecific() is
a rather critical function for some applications (mostly when making
existing libraries thread-safe without changing APIs)

I'm also not sure if the two level setup is worth it, it might save some
memory but slows it down.

Because there are some special cases (the sp & mask trick can't be used
when the user passes its own stack) it might be the best to split the
function into fast/slow path, with slow path as a subroutine call and
the possibility to check for the slow path with one check.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site