New libc malloc patch
davidxu at freebsd.org
Sun Dec 4 01:54:51 PST 2005
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
Yes, I know current pthread_mutex implementations use malloc,
I don't think it will be changed to avoid using malloc very soon.
> 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.
> 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?
Because we want other libraries use pthread mutex, if it can not be
used widely and we have to use spinlock, it is really a bad taste.
I think only the malloc has recursive problem. I tell you the fact,
libpthread needs malloc to initialize spinlock, so you can not create
spinlock dynamically in your malloc code. only libthr does not have the
problem. libc_r also has priority inversion problem with your current
More information about the freebsd-current