Re: New libc malloc patch

On Sun, 4 Dec 2005, David Xu wrote:

> Jason Evans wrote:
> > I just need simple (low overhead) mutexes that don't cause malloc to  be
> > called during their initialization.
> umtx is light weight and fast and need not malloc.
>
> >  I would have used  pthread_mutex_*
> > directly, but cannot due to infinite recursion  problems during
> > initialization.
> >
> Yes, I know current pthread_mutex implementations use malloc,
> I don't think it will be changed to avoid using malloc very soon.

It's on my list of things to do.

> > As you pointed out, it's important to get priority inheritance right  in
> > order to avoid priority inversion deadlock, so my hand-rolled  spinlocks
> > weren't adequate.  I need mutexes that are managed by the  threads
> > library.  The libc spinlocks appear to fit the bill perfectly  in that
> > capacity.  It seems to me that using umtx would actually be  the wrong
> > thing to do, because I'd be circumventing libpthread's  userland
> > scheduler, and it would be the wrong thing for libc_r, as  you pointed
> > out.  This approach would work for libthr, but perhaps  nothing else?
> >
> umtx will work with libpthread, I can not find any reason why using umtx
> will cause deadlock, the userland scheduler can not propagate its
> priority decision cross kernel, and umtx is a blockable syscall.

The problem is userland code can exit, circumvent the unlock by
exception handling, take a signal and longjmp, etc., which may
leave locks (not known by libpthread) held.  At least with
spinlocks or mutex, the thread libraries can know that the
application is in a critical region and can behave accordingly.
Libpthread will defer switching threads when they are in
critical regions (unless they are blocked).

I think that libc or other libraries that want to be thread-safe
shouldn't try to roll their own locks.  The reason to do so is
that lock overhead may be deemed too great.  If that is the
case, then we should fix the problem at its source ;-)
Of course, the other reason is that mutexes currently have to
be allocated.

-- 
DE