From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Tue, 25 Jul 2023 08:45:16 +0000 Message-ID: <87wmyoqt0j.fsf@localhost> References: <871qhnr4ty.fsf@localhost> <83fs5zecpo.fsf@gnu.org> <87351zbi72.fsf@localhost> <83351yevde.fsf@gnu.org> <87cz12ad2w.fsf@localhost> <83a5w6cwdr.fsf@gnu.org> <87pm518m0g.fsf@localhost> <83o7kl9tyj.fsf@gnu.org> <874jmd89us.fsf@localhost> <878rb53dkj.fsf@localhost> <83edkxsclz.fsf@gnu.org> <87tttt1mzh.fsf@localhost> <83351ds9de.fsf@gnu.org> <87ila91j6n.fsf@localhost> <83y1j5qoyo.fsf@gnu.org> <87wmypi7s0.fsf@localhost> <87fs5czvs2.fsf@yahoo.com> <87mszk7glc.fsf@localhost> <877cqozc14.fsf@yahoo.com> <87bkg0s9p4.fsf@localhost> <87351cz993.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13858"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 25 10:45:46 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 1qODft-0003Lq-QE for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jul 2023 10:45:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qODfI-0003KN-W5; Tue, 25 Jul 2023 04:45:09 -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 1qODfH-0003K2-Kk for emacs-devel@gnu.org; Tue, 25 Jul 2023 04:45:07 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qODfF-00053b-AJ for emacs-devel@gnu.org; Tue, 25 Jul 2023 04:45:07 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 20A54240029 for ; Tue, 25 Jul 2023 10:45:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690274703; bh=OreBPvzsyifGpY89U7Kk5UBWALJCaMFKk+hTvZEnC6E=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=WF37ue6mcIOGvChEyB94EJFl+gXtplF5Y8Y0I4ih80eatFjRPtcm4eoGJubGAzJRE OlEhi/ROcR34S7sD2en0A0eMvMhVwe1bqlFybUnfef6BC/jownZv7K7J0bu5oOLQO5 1soLWPme4Np2DpOc4LT+P6bW3xEbDL5O+9H8NzOYkJQOWNVDP9a2MBTd4SkBFsE7oL 1gO3HKMp8tnP6OVOUqy2QtJeNFA2iD/9lF0tutubiJ714VoZDE6ZH4x6AlIpbUiUdP vV8pmSphmHax5+e9Vs18d/OLXjhKYHEFAZI7mxObc+UPRSOtKTj4gbeBt/I504F8w4 f0zQyRMo1a/3Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R99Zk3T1Bz9ryg; Tue, 25 Jul 2023 10:45:02 +0200 (CEST) In-Reply-To: <87351cz993.fsf@yahoo.com> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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:308080 Archived-At: Po Lu writes: > Ihor Radchenko writes: > >> McKenney (2023) Is Parallel Programming Hard, And, If So, What Can You >> Do About It? p. 483 >> >> "For an example, consider >> embedded systems with 32-bit pointers and 16-bit busses. >> On such a system, a data race involving a store to and a >> load from a given pointer might well result in the load >> returning the low-order 16 bits of the old value of the >> pointer concatenated with the high-order 16 bits of the >> new value of the pointer." > > Emacs supports such systems? And they are SMPs as well? My point is that it will be very difficult to support such systems in future if we decide that we want to rely upon safety of concurrent read and write. >> AFAIK. They will degrade >> performance significantly (one-two orders of magnitude) for each >> individual operation (see Figure 5.1 in the McKenney's book) > > Figure 5.1 in that book illustrates the scalability of x86 interlocked > instructions by comparing an increment mechanism using plain loads and > stores to an atomic increment mechanism. It is not relevant to the > subject at hand. I understood that figure and the associated section differently. Do you have some kind of reference showing the performance of READ_ONCE/WRITE_ONCE? If we need less interlocks, it will certainly make things easier, but I do not want to run into hard-to-debug bugs caused by data races. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at