From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: 04 Dec 2003 20:26:28 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87oevbes4h.fsf@emacswiki.org> <20031117040607.C6C5D79B72@server2.messagingengine.com> <87ekvpx18d.fsf@emptyhost.emptydomain.de> <4nad6cikxy.fsf@holmes.bwh.harvard.edu> <4nllpt3hr3.fsf@lockgroove.bwh.harvard.edu> <5bad69zd43.fsf@lister.roxen.com> <4noeuon378.fsf@lockgroove.bwh.harvard.edu> <5bptf4ebw8.fsf@lister.roxen.com> <5bk75ce8p1.fsf@lister.roxen.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070566499 1237 80.91.224.253 (4 Dec 2003 19:34:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 19:34:59 +0000 (UTC) Cc: Ted Zlatanov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 04 20:34:56 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARzFY-0001W9-00 for ; Thu, 04 Dec 2003 20:34:56 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARzFY-0003tv-00 for ; Thu, 04 Dec 2003 20:34:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AS08I-0008TW-Oh for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 15:31:30 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AS05t-0007X8-Nu for emacs-devel@gnu.org; Thu, 04 Dec 2003 15:29:01 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AS05N-0007Gl-5x for emacs-devel@gnu.org; Thu, 04 Dec 2003 15:29:00 -0500 Original-Received: from [62.226.11.155] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AS04r-0006kF-SO for emacs-devel@gnu.org; Thu, 04 Dec 2003 15:27:58 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB4JQTNa007762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2003 20:26:30 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB4JQSqj007758; Thu, 4 Dec 2003 20:26:28 +0100 Original-To: Martin Stjernholm In-Reply-To: <5bk75ce8p1.fsf@lister.roxen.com> Original-Lines: 49 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18393 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18393 Martin Stjernholm writes: > David Kastrup wrote: > > > It's not preemption, but preemption aware coding, and it does not > > improve parallel execution but is a prerequisite for it. > > Maybe we have a terminology problem here. I don't regard thread > yields due to blocking operations or cooperative yielding as > preemption. The whole proposal was geared towards parallel execution of computation-intensive tasks (like gnus summarizing and scoring) with the editing foreground task. If we are not talking about multithreading, of course talking about preemption is idle. But if you remember, one topic that was brought up in this discussion was hyperthreading. Cooperative yielding can't make use of hyperthreading. Tasks that require cooperative yielding must not share any resources with any other task in between synchronization points (yield points, whatever). So they can't make use of multiple CPUs available. For multiple CPUs, you need thread safe programming. > Instead I reserve that term for uncooperative yielding when a time > slice is up. It's perfectly fine to have several executing tasks in > parallel without ever stopping any of them uncooperatively. But it will not be able to make use of multiple CPUs. And even with cooperative multitasking you need separate stacks for several resources, for every task, or you can only yield when at the top level of bindings/stacks/whatever. > >> Fine grained locking can, but it's hard to avoid making it too > >> fine grained so that the locking itself becomes more time > >> consuming than the speedup from the improved parallellism it > >> achieves. > > > > For that reason it is important to have as few locks necessary as > > possible. And having to lock on the binding table would be > > prohibitively expensive. > > Another reason to have only a single interpreter lock and no > preemption. It's hardly so expensive that it would take significant > time compared to blocking operations, is it? I don't see any usefulness at all. Certainly every nontrivial task will need to use the interpreter? So where is the gain? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum