New libc malloc patch
deischen at freebsd.org
Sun Dec 4 06:29:45 PST 2005
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
More information about the freebsd-current