From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Date: Thu, 10 Jun 2021 17:18:54 +0300 Message-ID: <8335tpdcq9.fsf@gnu.org> References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15440"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 36609@debbugs.gnu.org To: dick.r.chiang@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 10 16:20:10 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1lrLXU-0003iV-Kj for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Jun 2021 16:20:08 +0200 Original-Received: from localhost ([::1]:52518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrLXT-0006Ne-Ib for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Jun 2021 10:20:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58828) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrLXO-0006NR-Ls for bug-gnu-emacs@gnu.org; Thu, 10 Jun 2021 10:20:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54200) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lrLXO-0000Ns-Ek for bug-gnu-emacs@gnu.org; Thu, 10 Jun 2021 10:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lrLXO-0008GB-7I for bug-gnu-emacs@gnu.org; Thu, 10 Jun 2021 10:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jun 2021 14:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162333475831691 (code B ref 36609); Thu, 10 Jun 2021 14:20:02 +0000 Original-Received: (at 36609) by debbugs.gnu.org; 10 Jun 2021 14:19:18 +0000 Original-Received: from localhost ([127.0.0.1]:37513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrLWg-0008F3-Kj for submit@debbugs.gnu.org; Thu, 10 Jun 2021 10:19:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrLWd-0008En-NA for 36609@debbugs.gnu.org; Thu, 10 Jun 2021 10:19:17 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52224) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrLWY-0008Hr-Gv; Thu, 10 Jun 2021 10:19:10 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4194 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrLWY-0004bV-5x; Thu, 10 Jun 2021 10:19:10 -0400 In-Reply-To: <87bl8e2aya.fsf@dick> (dick.r.chiang@gmail.com) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:208321 Archived-At: > From: dick.r.chiang@gmail.com > Cc: 36609@debbugs.gnu.org > Date: Thu, 10 Jun 2021 07:52:45 -0400 > > > a single word... change should ... be atomic. > > I've never heard that. The idea is that a variable that is modified in a single machine instruction will always have the value assigned by the last thread which set that. You cannot have, for example, half of the bits of the variable set by one thread and the other half by another thread. > Adding the volatile qualifier to `threads_holding_glib_lock` did not > resolve my MRE on my particular architecture (whatever that may be). So can you describe what you think happens in your scenario that the offending change that added threads_holding_glib_lock causes? Because I still don't see the connection, to tell the truth.