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, ...)
- 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 ?
- 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 ?
- 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.
-Michael
_______________________________________________
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
