Re: > Re: Linux threads -- as seen in NT Magazine

Paul Barton-Davis (pbd@Op.Net)
Tue, 15 Dec 1998 14:53:42 -0500


>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/