Re: Slow pthread_create() under high load

From: Christopher Smith (x@xman.org)
Date: Tue Mar 28 2000 - 04:41:26 EST


On Tue, Mar 28, 2000 at 01:06:08AM -0700, Richard Gooch wrote:
> Because the kernel doesn't make this easy. The kernel has the concept
> of "tasks", which don't map well to POSIX threads. The kernel doesn't
> distinguish between "processes" and "threads" like POSIX does.
> Everything is just a task. Tasks can share some things (FS, files,
> VM), but they can't (yet) share PIDs (probably never), signal queues
> and other things required for POSIX compliance.

IMHO, at least sharing PIDs would be a useful thing. Signal queues
would be nice, but there are other ways to deal with that.
 
> You could probably write a native Linux threads library (lthread_*()
> anyone?) which was just as easy to use and powerful, and didn't
> require buggering the kernel. So from the point of view of the kernel
> community, there is reluctance to throw complex and ugly
> POSIX-specific support code into the kernel, for the sake of
> compliance with an ill-considered standard. Leave the problems to
> user-space, and hence the performance problems people mention.

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.)

2) Support for high-speed synchronization structures. In particular,
one should be able to do thread synchronization much more efficiently
than processes synchronization.

3) Was integrated into the glibc library, so I didn't have to worry
about reentrancy problems.

This all seems highly unlikely to me, and this is why I really would
like to have a good POSIX-threads implementation for Linux. Perhaps
I'm wrong though. Can someone point me to an implementation of threads
on Linux that comes close to the above criteria? If such a beast
doesn't exist, it seems to me that there would be some advantages to
considering the kernel support for POSIX threads option. These
include:

- Already integrated with glibc.
- Well defined specification that is integrated with other POSIX
  features (such as signals).
- Standards compliance is always a nice thing, particularly for making
  portable software.

There was a time when the mantra for Linux was, "when given a choice
between following the standard and doing something cool, I followed
the standard." Perhaps that time has passed, but I think it's worth
reflecting on the merits of that argument and how helpful it's been
for Linux to date.

It appears to me that by NOT being POSIX compliant in this area, you
limit the ability to leverage many of POSIXes other features in a
threaded program in general. Furthermore, you require a LOT of
reworking in userland libraries and such undoubtedly creating
incompatibilities.

--Chris

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



This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:21 EST