On Fri, Sep 22, 2023 at 06:51:43PM +0300, Eli Zaretskii wrote:
> > From: Emanuel Berg <incal@dataswamp.org>
> > Date: Fri, 22 Sep 2023 16:22:10 +0200
> > 
> > There is no way around it, in order to prevent a race
> > condition any global variable must be locked before it's value
> > can be altered.
> > 
> > So `setq', `setf' and any other setter of global variables
> > must first be refered to the locking mechanism where they
> > either acquire the lock, perform the write, and release the
> > lock; or, if the variable is already locked by some other
> > thread wanting to do the same thing, they must be queued so
> > they will get it in due time.
> 
> So one thread uses setq, releases the lock, then another thread comes,
> takes the lock and changes the value of that variable, and when the
> first thread uses the variable after that, it will have a value
> different from the one the thread used in its setq?  How can one write
> a program under these conditions and know what it will do?

Nicer even. Imagine the compiler saying "oh, we have the value
of this var already in this register!" (this is, after all, why
compiled code is significantly faster).

You can't do this anymore, because each global var is potentially
volatile.

Three quarter of your optimisation opportunities *poof* gone.

Another: suppose you have three globals which have to be
changed in sync. Do you lock around the whole change, although
each var is locked in itself?

Concurrency isn't easy. Most of the application has to "know",
in a way.

Cheers
-- 
t