Date: Sun, 04 Dec 2005 17:54:53 +0800 From: David Xu <davidxu@freebsd.org> To: Jason Evans <jasone@canonware.com> Cc: current@freebsd.org Subject: Re: New libc malloc patch Message-ID: <4392BCED.3070500@freebsd.org> In-Reply-To: <D6B1310D-32F5-4BAD-B6D2-FFA14DE7A276@canonware.com> References: <B6653214-2181-4342-854D-323979D23EE8@canonware.com> <Pine.LNX.4.53.0511291121360.27754@regurgitate.ugcs.caltech.edu> <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <4391569A.7080808@freebsd.org> <D1B3ED90-7936-41AA-93D3-AAC7E1615CDA@canonware.com> <43924917.3070506@freebsd.org> <D6B1310D-32F5-4BAD-B6D2-FFA14DE7A276@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4392BCED.3070500>