Re: New libc malloc patch

On Sun, 11 Dec 2005, Jason Evans wrote:

> On Dec 11, 2005, at 5:48 PM, Johan Bucht wrote:
>
> > * Locking primitive
> > The biggest issue and as David Xu pointed out is probably the locking
> > primitives. The SPINLOCK use has a limit in the threading library and
> > makes is hard to have a lot of mutexes. I ended up using a wrapper
> > around the umtx_lock function to get recursive mutexes and it would
> > probably be better to extend the umtx functions to handle recursion.
> > This would probably also be appreciated by other malloc
> > implementations.
> > Might be interesting to implement some of the ideas from the Linux
> > futex
> > implementation to help umtx.
>
> I have been contemplating creating a separate spinlock API that
> doesn't require the threads library to track the spinlocks across
> fork.  This would (if I understand correctly) remove the current
> static spinlock limitations.

What about using pthread_atfork()?

> As for supporting recursive spinlocks, I doubt that the overhead
> would be acceptable in general.  If I could get rid of the need for
> the one recursive lock in malloc.c, I certainly would. =)

Why do we need a recursive mutex?  Can you not restructure the
code so that it is not needed?

-- 
DE