bug#36609: 27.0.50; Possible race-condition in threading implementation

[Eli Zaretskii]

> 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.