Messages in this thread | | | Date | Wed, 29 Mar 2000 10:43:34 -0800 | From | Christopher Smith <> | Subject | Re: Slow pthread_create() under high load |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Mar 28, 2000 at 03:33:00PM -0700, Richard Gooch wrote: > Christopher Smith writes: > > Hmm... it would be nice if there was a thread library that let me > > have: > > > > 1) Solid support for signals, including real-time signals and such > > interesting RT signal extensions that normally require > > POSIX-threads. (Indeed, at least in the POSIX world queue'd signals > > seem to be the way to go, and I'd hate to handle signals any other way > > in a threaded world.) > RT signals work fine with clone()ed processes.
so _POSIX_THREADS_PER_THREAD_SIGNALS_1 is effectively true?
Is there some way to do SIGEV_THREAD? > Maybe the community should sit down and hammer out the following > points, once and for all: > > - do we actually need efficient (POSIX compliant) pthreads for Linux
I think yes. Perhaps it doesn't have to be the most efficient threading API on Linux, but it should be reasonably efficient. There are lots of developers/companies who build their software specifically to POSIX API's, and I think there is a value add to having their software run reasonably well (and reliably) on Linux. A case in point is the blackdown group, who didn't so much have problems with performance, but they did find that pthreads behavior was different enough from standard POSIX that we had to wait years before there was a stable native-threads capable version of blackdown-java on Linux. > - is there a solution to the pthreads/kernel problem that Linus will > accept
It would be good to hear from some of the Pthreads guys on what they've tried so far and what conclusions they've reached. It sounds to me that Linus' requirements on what he'll except are eminently reasonable (indeed, they seem like the only way to go). I have to imagine there's a way to make this work. > - would an efficient lthread implementation provide an acceptable > alternative for those who care more about speed than portability?
I think so, so long as the pthreads solution is not prohibitively slow. Keep in mind that a lot of people use POSIX threads to get better performance than a process based model, so pthreads is only useful to them if it's fairly efficient. > On the last point, it's worth noting that every vendor has had their > own threads API, and people have used it. In my own code, I've made > use of IRIX's native sproc(2), Solaris Threads and Linux's > clone(2). Sure, it's a bit ugly having all those #ifdefs, but it > works, and my code is portable. > > What, I hear you ask. How is it portable? Simple: my applications use > my wrapper layer. What matters to me is that I've had threaded > applications for over 5 years. If I had to wait for vendors to > implement and debug pthreads, I'd only now be shipping threaded > applications.
While this is a good point, there are disadvantages to this approach, particularly with something as close to the system level as threads. Having a portable way of dealing with Linux's divergences from POSIX threads signals behavior is a non-trivial task, and there's nothing your threading library can do to convince external processes that all your threads have the same PID. So, so long as your application doesn't need these kinds of things (and a lot of them don't), so long as you're willing to invest the effort to learn the specifics of each platforms thread library, and so long as your application can live with a least common denominator implementation of threads, you're ok.
Having a working POSIX threads means that people don't have to implement their own (and potentially inefficient and buggy) thread abstraction layer. This saves application developer time. So, as long as this doesn't cost us kernel developer time (which I guess would require that we live in a perfect world rather than the real one ;-), it's a good thing to have. > We *are* following the standard. Or at least, pthreads in Linux is > supposed to. It's just that the efficiency isn't that good. I see no > reason we can't have both: pthreads for compliance, and lthreads for > speed.
I agree, with the caveats mentioned above.
- --Chris
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
iD8DBQE44k7NfrrCpthD+UYRAsZVAKDeTfRgdZwQ+rjEROWQQThHJ18HoQCeJhJX GLpE3RiNyfLpQyXXpjtmAtU= =3Fgq -----END PGP SIGNATURE-----
- 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/
| |