Re: New libc malloc patch

Jason Evans wrote:

> On Dec 3, 2005, at 12:26 AM, David Xu wrote:
>
>> I have a question about mutex used in the patch, you are using
>> a spin loop, isn't it suboptimal ? and a thread library like  libpthread
>> supports static priority scheduling, this mutex does not work, it
>> will causes a dead lock, if a lower priority thread locked the mutex,
>> and preempted by a higher priority thread, and the higher priority
>> thread also calls malloc, it will spin there to wait lower
>> priority thread to complete, but that will never happen.
>
>
> David,
>
> You are correct that this is a problem.  Thank you for pointing it  
> out.  There's a new patch that uses the spinlocks that are provided  
> by the threads libraries.  Please let me know if this looks okay.
>
> Also, this patch removes/modifies the code that was causing build  
> failures on amd64, so it's worth giving another try.  Hopefully, it  
> will compile now...
>
> http://www.canonware.com/~jasone/jemalloc/jemalloc_20051203a.diff
>
> Thanks,
> Jason
>
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.

Regards,
David Xu