New libc malloc patch
deischen at freebsd.org
Sun Dec 11 21:58:40 PST 2005
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?
More information about the freebsd-current