From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Fri, 07 Jul 2023 08:41:21 +0800 Message-ID: <87ilawimdq.fsf@yahoo.com> References: <871qhnr4ty.fsf@localhost> <83v8ezk3cj.fsf@gnu.org> <87v8ezpov0.fsf@localhost> <83r0pnk2az.fsf@gnu.org> <87pm57pns8.fsf@localhost> <87lefvp55t.fsf@yahoo.com> <87sfa28ura.fsf@localhost> <87cz16o8vz.fsf@yahoo.com> <87jzve8r4m.fsf@localhost> <871qhmo5nv.fsf@yahoo.com> <87bkgq8p5t.fsf@localhost> <831qhmjwk0.fsf@gnu.org> <875y6y8nlr.fsf@localhost> <87h6qhnalc.fsf@yahoo.com> <87ilax71wo.fsf@localhost> <831qhli14t.fsf@gnu.org> <87wmzdxewc.fsf@localhost> <83r0plgjeo.fsf@gnu.org> <87o7kpxapo.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37342"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 07 02:42:41 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qHZYX-0009XZ-80 for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Jul 2023 02:42:41 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHZXY-0003Tn-3B; Thu, 06 Jul 2023 20:41:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHZXW-0003TK-1d for emacs-devel@gnu.org; Thu, 06 Jul 2023 20:41:38 -0400 Original-Received: from sonic311-25.consmr.mail.ne1.yahoo.com ([66.163.188.206]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qHZXU-0008R2-Gk for emacs-devel@gnu.org; Thu, 06 Jul 2023 20:41:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688690493; bh=0nPhwz4K0txDOwLi7fzoKgqgkU+Pc6Iyf8KCf+3Mdds=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=hxJ4nQ4vYwkARKzOYHQVgCTHqn6nN4eqMY8yKTBE98n/nFQP9p+0qKvLMUV6r8msqt1BsCNOLjodpouCXv636+6S/L15iLyI1AZyTxIKjRZNkKUOr0J2ITKgPO5FFCGG7T11FAIuHERhv7IqQcxLGOe+j9zaxARi3T3IGWSoBxSYvplg2VOylJgoIrfcs9FPy701O3HLEXHhI+cxt19+9WzicKEEr0cxMZdWS1rBiMYsjZO7MI+djl8BNk+S1iADkl/34mIKR1uN8sUDz/vyyDW1z2Ylfhy0rG2LylCm1mJC2wxRA9QmRi+ET9FzMHNZf5A4OHjLetgpe3iK/zOrtg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688690493; bh=GXB2sBfjokPQKIzMsA8DmMsmvq9QydLhq8bUGxMGyWL=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Qbah3ljO+IW62C1FW5ARoQ6tsVZi3OJNa58Ca0IlTlJEkH8MxtY1eWa8C0N9xxVYGR38dA1VRSX77gqnEjF6pW0IIZgyK7We1WeM2NAfVbqbEAY9jVcEiMn8AJjwvk/05UMuv+BkYhxjrtAwKz73krzUzqcnmsv9BzWBiWASRBIE/L+YDXTZrKfeFHPblG9tbGddip8DY+wR87DDxHalQ3OVcB50OWG7qiZEwDak+M19xfJQw0ooAzhx9u4QddLQL6dKdxy22CuH3VVxfRE/mobaxJDc/y5o2MOvPRu/P0CicwXa+/49ym1G4kyVhMZ4Bl47Iw9kiulHR1l+6mmLxg== X-YMail-OSG: 35lgOQ8VM1kItFFarBrSOao.Ja8o2ia.e58Tvi0U6LoGHtC4XK052TP3lgtoMJo TOunqdOnXnYmCV714wMb1NkWaRC5pnGkpVLHbBw01v70h16NF_JPgQRgsKzVecgdQBOScIRNOF0Y Ee5jYiduKTOclv0_H2zghUbwYaLbtPzzaeQznGyY6cKqH.j1ZFnO_f9WeRZqo1yB9rn2215fM2E4 dlKlmteUeXJ.HxztcpcGXNqEkqN72wdy30ayPgpNPSWJAz0Cg9pEN2hvacFEAPb4J_9Eo5rhxCy1 8e.APqGyT9aZsAObVGpr7VqUSyS57ubyvaGj00qeojGEOQX.V4vt8a7xDMSfrvOB2HiO28M1qEc9 70RqIeDVHKpzPcotnz0UbFT3cW2gPgusCfJlS9H.SdoD086VcGh1aKM7IKlxRLYCRk8TqAxFLb7H mo0b4D6QooGiaGB67kwywFrjdQn0xaTsrNzFzSUwPSq831zKd2Vry.awIBf8yu3b_iNZ3mCu5IYj zrpqIUw1WTNNd.q.gKn89a9rO7v1rBzNPJhnJyq6OMjorddoKhOmmQ6ovyLc_R4E_pMi3HHaKMZ9 Cn48hYl380IiOMXMyAEZCkdHox5BDq6lYg43TOslIsfo0cpgTSa4XCiAWPQjWSF4l69G00Gp6r79 aP2WhkhGg6qLCxCCViisyxg1qDPTAUgLXpwZvA85bbFKw_pSkkh54sN4MYQ0tqtfoJ0RtXn14YiJ Ocur0RAAB9ekChyqfhTACyjWU6WPC7mDymZCw54DnPcN.zD.YwX4V6Oru7_J4P3oj5t7Toh0xHzJ tWacJSZfAwPhZ7EkMh815I4EgGlcut4g4U1ZgjAoUz X-Sonic-MF: X-Sonic-ID: e7b5c7e5-9031-424e-a919-7469e579486e Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Fri, 7 Jul 2023 00:41:33 +0000 Original-Received: by hermes--production-sg3-67fd64777-txbf9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID aecdf625c207aa7843ce0880fb613953; Fri, 07 Jul 2023 00:41:26 +0000 (UTC) In-Reply-To: <87o7kpxapo.fsf@localhost> (Ihor Radchenko's message of "Thu, 06 Jul 2023 16:32:03 +0000") X-Mailer: WebService/1.1.21638 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.188.206; envelope-from=luangruo@yahoo.com; helo=sonic311-25.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307540 Archived-At: Ihor Radchenko writes: > Same with variables - even if some global variable needs to be locked, > it is unlikely that it will need to be accessed by another thread. I doubt symbol value cells will need to be individually interlocked. Emacs Lisp code will need to insert the appropriate instructions to prevent the CPU from undertaking optimizations on load and store operations on those cells when necessary. Imagine a situation where a secondary thread writes the result of an expensive computation to X, and then sets a flag to indicate its completion: (defvar X nil) (defvar Y nil) thread 1: (setq X (some-expensive-computation)) ;; __machine_w_barrier () (setq Y t) ;; On machines that don't do this automatically, flush the cache ;; eventually. A second thread then waits for Y to be set, indicating completion: (when Y ;; __machine_r_barrier () (do-something-with X)) If the barrier instructions are not inserted, Y could be set to t before X is set to the result of the computation, and the main thread could also load X prior to loading (and inspecting) Y. But there would be no chance of a previously read value of either X or Y appearing after a new value becoming visible or a partially written value of X or Y being read, forgoing the need for any locking being performed on the individual symbols themselves.