Date: Thu, 5 May 2016 21:58:10 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Martin Simmons <martin@lispworks.com> Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: Robust mutexes implementation Message-ID: <20160505185810.GF2422@kib.kiev.ua> In-Reply-To: <201605051720.u45HKZ76021094@higson.cam.lispworks.com> References: <20160505131029.GE2422@kib.kiev.ua> <201605051720.u45HKZ76021094@higson.cam.lispworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 05, 2016 at 06:20:35PM +0100, Martin Simmons wrote: > There is a potential bug in enqueue_mutex when it tests m1 == NULL and m1 != > NULL. These tests only work because m_lock is the first slot in struct > pthread_mutex and hence 0 in curthread->robust_list is converted to NULL > (rather than a negative value). Yes. In fact I wrote the __containerof stuff only later, initial version of the patch did relied on the fact that m_lock is at the beginning of pthread_mutex. I rewrote the code in enqueue, and there is one more similar check in dequeue_mutex(). Updated patch is at https://kib.kiev.ua/kib/pshared/robust.2.patch . It also fixed the lack of userland split for non-robust pp/robust pp queues. > > Also, is it safe to assume memory ordering between the assignments of > m->m_lock.m_rb_lnk and curthread->robust_list? Maybe it is OK because the > kernel will never read curthread->robust_list until after the CPU executing > enqueue_mutex has passed a memory barrier? Inter-CPU ordering (I suppose you mean this, because you mention barriers) only matter when we consider multi-threaded interaction. In case of dequeue_mutex, paired to corresponding enqueue_mutex(), the calls occur in the same thread, and the thread is always self-consistent. WRT possible reordering, we in fact only care that enqueue writes do not become visible before lock is obtained, and dequeue must finish for external observers before lock is released. This is ensured by the umutex lock semantic, which has neccessary acquire barrier on lock and release barrier on unlock.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160505185810.GF2422>