[lkml]   [1998]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Thread implementations...
    MOLNAR Ingo <> 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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:43    [W:0.020 / U:34.032 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site