Re: New libc malloc patch

From: Jason Evans <jasone_at_canonware.com>
Date: Sat, 3 Dec 2005 19:46:01 -0800
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  
> process
> 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  
nothing else?

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?
Received on Sun Dec 04 2005 - 02:47:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:48 UTC