From owner-freebsd-threads@freebsd.org Thu May 5 18:58:17 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AC83B2EA59 for ; Thu, 5 May 2016 18:58:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1566E1FAF for ; Thu, 5 May 2016 18:58:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0D553B2EA57; Thu, 5 May 2016 18:58:17 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CB3CB2EA55; Thu, 5 May 2016 18:58:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82B551FAD; Thu, 5 May 2016 18:58:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u45IwAHm069983 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 5 May 2016 21:58:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u45IwAHm069983 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u45IwAcl069982; Thu, 5 May 2016 21:58:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 May 2016 21:58:10 +0300 From: Konstantin Belousov To: Martin Simmons Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: Robust mutexes implementation Message-ID: <20160505185810.GF2422@kib.kiev.ua> References: <20160505131029.GE2422@kib.kiev.ua> <201605051720.u45HKZ76021094@higson.cam.lispworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201605051720.u45HKZ76021094@higson.cam.lispworks.com> User-Agent: Mutt/1.6.0 (2016-04-01) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 18:58:17 -0000 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.