Re: New libc malloc patch

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.

> 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?
> 
> Thanks,
> Jason
> 
> 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
mutex code.

Regards,
David Xu