This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: Slow pthread_create() under high load
- To: "Stephen C. Tweedie" <sct at redhat dot com>
- Subject: Re: Slow pthread_create() under high load
- From: Robert de Vries <rhdv at rhdv dot cistron dot nl>
- Date: Tue, 28 Mar 2000 20:27:30 +0200 (CEST)
- cc: "Albert D. Cahalan" <acahalan at cs dot uml dot edu>, alan at lxorguk dot ukuu dot org dot uk, alvin at iplink dot net, drepper at cygnus dot com, drepper at redhat dot com, glibc-linux at ricardo dot ecn dot wfu dot edu, jpo at joerg-pommnitz dot de, kaz at ashi dot footprints dot net, khim at sch57 dot msk dot ru, linux-kernel at vger dot rutgers dot edu, monty at mysql dot com, mysql at lists dot mysql dot com, rgooch at ras dot ucalgary dot ca, sasha at mysql dot com
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
On Tue, 28 Mar 2000, Stephen C. Tweedie wrote:
> Hi,
>
> On Tue, Mar 28, 2000 at 05:07:44AM -0500, Albert D. Cahalan wrote:
> >
> > Stephen C. Tweedie:
> > > Maybe, but although a lot of the POSIX threads are reasonable,
> > > things like requiring uid/gid updates to be instantly effective
> > > across all threads in the process are just insane.
>
> > If we had a task-group notion in the kernel, we could send some
> > sort of signal to all tasks in the group.
>
> You can do that anyway, in user space. Much cleaner.
Sure you can, but the trick is to send one (1) signal to a group of tasks.
Not n times the same signal to n tasks. IMHO, the POSIX semantics of
signal delivery require a shared signal queue and a private queue. The
shared signal queue is used for signals which are sent to the "process" as
a whole (translate to a group of cloned tasks in Linux) and the private
queue is use for signals sent to an individual thread (translate to one
task of a group of cloned tasks in Linux).
I have implemented a shared signal queue implementation which is triggered
by yet another CLONE_* flag. It seems to work, although I would like some
people to have a look at it.
I feel that this behaviour should be optional. It is useful under certain
circumstances, but it may hurt performance in other cases. For instance,
it could be useful in the situation where signals are used to notify a
group of threads of incoming data on a huge number of sockets. This should
fix the problem noted in the past with the bad performance of select/poll
when handling huge amounts of file descriptors.
On the other hand the shared signal queue introduces inter-thread
dependencies which might hurt certain real-time applications. A lock on
the shared signal queue is needed to prevent two threads simultaneously
accessing the signal queue. This might introduce unwanted delays.
My shared signal queue patch can be found at:
http://www.rhdv.cistron.nl/sigqueue.html
Robert
--
Robert de Vries
rhdv@rhdv.cistron.nl