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, ...)
LinuxThreads uses signals. Signals are clunky but the other things have different problems. > > - 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 TLS has nothing to do with Futex. > I still don't see why TLS depends on NTPL, Why should implementing > TLS with "Linux Threads" should not be possible ? It's possible to implement TLS in LinuxThreads if you want. Nobody has done so; there's no point because it's easier to port NPTL. > > - 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. You can't have pthread_mutex_t without using pthreads :-) Are you thinking of a different kind of mutex? You can't just put a pthread_mutex_t in shared memory. It won't work properly. > 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 ? Yes, of course you can access shared memory mapped into multiple processes on any of those combinations. That's the best way to share memory. You can't expect mutexes shard between processes to work though, unless you specifically request a system-scope mutex, which LinuxThreads doesn't support. > > - 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. That's fine tuning and not always important. There's no "correct" time slicing anyway. Compare with putting mutexes in shared memory on LinuxThreads, which is simply broken. -- Jamie _______________________________________________ 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
