New libc malloc patch
jasone at canonware.com
Sat Dec 3 19:47:24 PST 2005
On Dec 3, 2005, at 5:40 PM, David Xu wrote:
> The libc spinlocks are deprecated, in fact, thread libraries try to
> keep track
> off all spinlocks in libc and reset them in child process, they
> will complain
> if there are too many spinlocks, this is not very correct, but
> would resolve
> dead lock in real world applications (weird applications).
> Because I see you have put _malloc_prefork() and _malloc_postfork()
> hooks in thread libraries, I guess you want to manage all malloc
> locks, so
> you might don't need to use the spinlocks, you can implement these
> locks by using umtx provided by kernel, you can use UMTX_OP_WAIT
> and UMTX_OP_WAKE to implement these locks, the UMTX_OP_LOCK
> and UMTX_OP_UNLOCK can also be used to implement locks, but I reserve
> these two functions since I have plan to implement reliable POSIX
> shared mutex. you can find those code in libthr to study how to
> use umtx.
> Last, I don't know if umtx will work with libc_r, but libc_r has
> already been
> disconneted from world for some days, it will rot away.
I just need simple (low overhead) mutexes that don't cause malloc to
be called during their initialization. I would have used
pthread_mutex_* directly, but cannot due to infinite recursion
problems during initialization.
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
I'd like to keep things as simple and general as possible. Is the
current implementation that uses libc spinlocks acceptable?
P.S. Why are libc spinlocks deprecated?
More information about the freebsd-current