tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: fixing libpthread noload, another approach

Martin Husemann <> wrote:

> My understanding is that basically everyone besides you would prefer to keep
> things exactly as they are now.

This is just because I have hit a regression with it and other people
here have not (yet).
> For every clean solution the first step would be to actually measure the
> libc overhead introduced by "real locking" for single threaded apps. Second
> step would be to discuss which hackish solution to use, if the first step
> shows a too high penalty.

However small, there will be a performance penatly if we implement bits
of mutex and condvars in libc stubs. I made the change to do it and I
can run measurement, but what do you want to mesure? The hit on
pthread_mutex_lock()? on malloc()? On something else?

Emmanuel Dreyfus

Home | Main Index | Thread Index | Old Index