lkml.org 
[lkml]   [1998]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: > Re: Linux threads -- as seen in NT Magazine
    Date
    From
    >You are looking at the kernels own locking subsystem not the locks done
    >by the glibc thread library

    See mea culpa need more sleepa follow up message.

    >> If the thread actually sleep(2)'s on some event, fine. But most
    >> Are you running on an SMP machine ? Do you have a threaded, order
    >> dependent pipeline that uses user-level threads and no kernel-level
    >> synchronization ?
    >
    >I the pipeline length is strictly bounded, and the objects in it are
    >type constant do you need any locking anyway. It ought to be almost lockless

    But if they are not constant, then you do, and my current area of
    interest (http://www.op.net/~pbd/quasimodo/) doesn't feature such
    objects. there's an RT-FIFO "DSP" like thread running (and perhaps
    bound) to one processor, and another bunch of threads playing with its
    parameters and injecting work requests into its queue. this *isn't*
    going to be lockfree.

    As I said, I need to think through more carefully whether or not
    sigsuspend() and the current schedule() semantics stand any hope of
    working correctly for the general case (of a multithreaded, variable
    workload, pipelined application).

    --p

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:46    [W:0.019 / U:0.328 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site