From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: Locks and threads Date: Wed, 11 Feb 2009 23:53:23 +0000 Message-ID: <87eiy4cyz0.fsf@arudy.ossau.uklinux.net> References: <87mycsd2rj.fsf@arudy.ossau.uklinux.net> <3ae3aa420902111530k671cd331i308915e0efaf75bb@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1234396424 22382 80.91.229.12 (11 Feb 2009 23:53:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Feb 2009 23:53:44 +0000 (UTC) Cc: Guile Development To: linasvepstas@gmail.com Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Feb 12 00:55:00 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LXOuw-0001OM-Iv for guile-devel@m.gmane.org; Thu, 12 Feb 2009 00:54:59 +0100 Original-Received: from localhost ([127.0.0.1]:44013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXOtc-0006W2-U7 for guile-devel@m.gmane.org; Wed, 11 Feb 2009 18:53:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXOtW-0006Vx-SA for guile-devel@gnu.org; Wed, 11 Feb 2009 18:53:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXOtU-0006Tr-Bj for guile-devel@gnu.org; Wed, 11 Feb 2009 18:53:29 -0500 Original-Received: from [199.232.76.173] (port=55544 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXOtU-0006Th-9J for guile-devel@gnu.org; Wed, 11 Feb 2009 18:53:28 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]:54390) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXOtT-0004HA-Mm for guile-devel@gnu.org; Wed, 11 Feb 2009 18:53:28 -0500 Original-Received: from arudy (host86-157-180-39.range86-157.btcentralplus.com [86.157.180.39]) by mail3.uklinux.net (Postfix) with ESMTP id DCC191F6B01; Wed, 11 Feb 2009 23:53:24 +0000 (GMT) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 010A938012; Wed, 11 Feb 2009 23:53:23 +0000 (GMT) In-Reply-To: <3ae3aa420902111530k671cd331i308915e0efaf75bb@mail.gmail.com> (Linas Vepstas's message of "Wed\, 11 Feb 2009 17\:30\:28 -0600") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8156 Archived-At: Linas Vepstas writes: > Err, sort of, yes, unless I misunderstand. Guile 1.8 makes > a certain basic assumption that is splattered throughout > the code; it rather intentionally re-orders the order in which > one of the locks is taken. If I remember correctly, its the > "in guile mode" lock. So if you just go looking for locks > that are released out-of-order, you'll find lots of these. Yes, I think I understand this now (having seen it myself). The pattern is - thread holding its heap_mutex - which is the normal state in guile mode - thread calls scm_i_scm_pthread_mutex_lock to lock some other mutex - scm_i_scm_pthread_mutex_lock: - unlocks the heap_mutex - locks the other mutex - locks the heap mutex again. That in itself doesn't actually cause an ordering problem, but then the thread releases the other mutex without releasing the heap mutex first - which is perceived (by helgrind at least) as a problem. (Is something like this actually _ever_ a problem? If locks are always _acquired_ in the right order, how can the order of _releasing_ ever cause a problem?) The async_mutex handling (that I've posted a patch for) is one example of this. > At the time, I had decided that > 1) it would be a lot of work to get these in order, and the > patch would likely be rejected, and > 2) the reordering is essentially harmless (since its > consistently done). > 3) there might have even been a performance hit (I don't > remember) by trying to get these into order. The other thing to bear in mind is that 99% of this will just evaporate if we move to BDW-GC for 2.0.x; so - assuming we do end up doing that - it makes sense to take a slightly more pragmatic approach than normal for 1.8.x. > This made using valgrind impossible, and that's why I created > the custom patch -- it made a point of ignoring this one > reversed-order, while checking for badness in everything else. Thanks. I understand this much better now! On the other hand, after the async_mutex patch, my helgrind output [1] is only reporting a couple of problems now, so it looks like helgrind-cleanliness might be achievable. [1] I am only running a basic startup test, though: "valgrind --tool=helgrind guile -q <