From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: advice needed for multi-threading patch Date: Sun, 27 Sep 2009 14:59:02 -0600 Message-ID: References: Reply-To: Tom Tromey NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1254085166 4924 80.91.229.12 (27 Sep 2009 20:59:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2009 20:59:26 +0000 (UTC) Cc: Emacs development discussions To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 27 22:59:19 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Ms0pw-0006At-IB for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2009 22:59:16 +0200 Original-Received: from localhost ([127.0.0.1]:43022 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ms0pw-0002zC-3D for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2009 16:59:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ms0ps-0002yr-7U for emacs-devel@gnu.org; Sun, 27 Sep 2009 16:59:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ms0pn-0002yH-Og for emacs-devel@gnu.org; Sun, 27 Sep 2009 16:59:11 -0400 Original-Received: from [199.232.76.173] (port=51123 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ms0pn-0002yE-LF for emacs-devel@gnu.org; Sun, 27 Sep 2009 16:59:07 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:3132) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ms0pn-0000as-0k for emacs-devel@gnu.org; Sun, 27 Sep 2009 16:59:07 -0400 Original-Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8RKx4mE010541; Sun, 27 Sep 2009 16:59:05 -0400 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8RKx4ES027478; Sun, 27 Sep 2009 16:59:04 -0400 Original-Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n8RKx2PJ000746; Sun, 27 Sep 2009 16:59:03 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 7D79E37818C; Sun, 27 Sep 2009 14:59:02 -0600 (MDT) X-Attribution: Tom In-Reply-To: (Stefan Monnier's message of "Thu, 24 Sep 2009 13:25:03 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.16 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:115699 Archived-At: >>>>> "Stefan" == Stefan Monnier writes: [ releasing the buffer lock when yielding ] Tom> I think this means it does not suffice to keep a simple per-thread count Tom> of buffer-local bindings. Stefan> Indeed. The lock should probably be on the buffer-local binding itself Stefan> (i.e. the combination of the buffer and the variable). I looked into this a bit; I think it can lead to deadlock too easily: Thread A acquires V1 and requests V2 Thread B acquires V2 and requests V1 Instead, I think we could remove the buffer lock. Because we currently use cooperative threading, most buffer operations are atomic with respect to thread switches. So, it seems that if we fix the bindings problem, we can probably just remove the buffer lock. What do you think of that? Are there problems I've missed? I wrote some elisp to modify the Emacs sources to use buffer accessor macros everywhere (it handles like 90% of the references, a few tweaks by hand are also needed). The only thing remaining is to fix up the swap_in_symval_forwarding logic, which we have to do anyway. Tom