On Monday 02 March 2009 09:34:20 Michael Schnell wrote: > > NPTL's advantages over LinuxThreads which come to mind: > > - Faster to communicate between threads because it doesn't use signals. > > Do you suggest, the pthread library does any IPC using signals ? There > are a lot other means (semaphores, message queues, ...)
i'm pretty sure drepper wrote some design docs on NPTL you could refer to ... > > - Futex-based primitives mean mutexes and other synchronisation > > between threads are much faster. > > Maybe Futex is implemented using TLS (I understand that it can be done > that way), so I do see that Futex depends in TLS, but I still don't see > why TLS depends on NTPL, Why should implementing TLS with "Linux > Threads" should not be possible ? no, futexes are implemented within the kernel. TLS does not depend on NPTL, NPTL depends on TLS. there was some support in later glibc versions for TLS in linuxthreads as well ... > > - You can have inter-process (system-wide) mutexes and other > > synchronisation objects in shared memory. > > Why does this depend on NPTL ? I understand can request shared memory > and use Mutex without using threads. And if I create a thread why should > same not access the shared memory mapped to it's process or use a Mutex > it's process created - with or without NTPL and with or without MMU ? it doesnt. Jamie is describing reasons why NPTL is better than LT by basically using a list of things that are wrong with LT. > > - Actually POSIX correct behaviour. E.g. getpid() returns > > the same value for each thread. Signals are delivered in the way > > described by POSIX. Etc. So more code just works with NPTL. > > AFAIK, there is a scheduling issue, regarding assigning time slices to > threads with respect to the other running processes, too. fairly minor considering all the ways linuxthreads is broken with POSIX. and NPTL issues can actually be addressed without having to redo design-level details. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
