Multithreading - shared mutable data - GIL

[shortcut]

Hello.

Can the following code be considered threadsafe?
The important part for me is, if it could be considered threadsafe in future versions of Python without GIL.

In the past I learned the hard way that it is not a good idea to make assumptions on implementation details of underlying code esp. when it comes to multithreading.

Thanks a lot for your suggestions.

def worker(): while True: time.sleep(1) if not info['running']: # thread safe? break info = {} info['running'] = True th = threading.Thread(target = worker) th.start() time.sleep(5) info['running'] = False # thread safe? th.join()

[noisefloor]

Hello,

the example is that shallow that it hardly makes sense... The thread is pretty useless here.

Generally speaking, relying on a global state of a variable - like here info should be prevented, as this can have unwanted side effects and makes it very hard to track the state of the program. When multiple threads have to work with the same resource concurrently, you may want to take a look at threading.Lock. An older, but IMHO still good introduction with examples can be found at https://pymotw.com/3/threading/ . Maybe this helps as a starting point.

Regards, noisefloor

[shortcut]

Hello noisefloor.

Thanks for taking the time to answer.

the example is that shallow that it hardly makes sense... The thread is pretty useless here.

This is of course true. I tried to remove any unnecessary code to make the example as short and easy as possible to include only the part which is relevant to the question.

So the essential question is if a 'bool' which is part of a 'dict' can be modified from one thread if it is read by another thread without any synchronization elements like mutex, etc. I know it will work currently as GIL will prevent any problems. But I want to be sure that code will not break if once GIL can or will be removed. For languages like C or C++ this is a much easier to answer.

Thanks.

[noisefloor]

I know it will work currently as GIL will prevent any problems.

I think this assumption is wrong. Yes, CPython with a GIL can only execute only one thread at a time - but this does _not_ imply automatic locking! As you have basically no control about context / thread switching in Python, it could well be that thread A reads a shared variable, then the thread is paused, Python switches to another thread B which reads, alters and writes the shared variable, then B is paused, Python return to A and continues to run this thread - with A having an outdated value for the shared variable. So basically your problem is _not_ a future problem, it is real for CPython today already.

Except this: C-based extension modules can have "true" multithreading even with CPython's GIL plus other Python implementations may not have a GIL anyway. The (in the meantime outdated?) Jython and IronPython implementations are GIL-free and it is my understanding that PyPy has no GIL either.

Regards, noisefloor

[shortcut]

As you have basically no control about context / thread switching in Python, it could well be that thread A reads a shared variable, then the thread is paused, Python switches to another thread B which reads, alters and writes the shared variable, then B is paused, Python return to A and continues to run this thread - with A having an outdated value for the shared variable.

This is clear. Only a single python opcode can be considered atomic, and there you can see that e.g. "x += 1" is not atomic cause it consists of multiple opcodes. But that is the reason I posted my example. The change of the shared value does not rely on a previous read value. So what you describe could not happen in my example.

[noisefloor]

But then you don't have a problem anyway, without or with a GIL.

If this still doesn't answer your question, please post a better, closer to real-world code example than the pretty pointless example inn the original post.

Regards, noisefloor

[shortcut]

But then you don't have a problem anyway, without or with a GIL.

That was the answer to the initial question.
Thanks anyway.

[shortcut]

Just for the records.

I found an article which demonstrades what I tried to achieve (gracefully exit infinite loop of a thread from the main thread) in another way by using events.

https://www.instructables.com/Starting-a...-Events-i/

[noisefloor]

Correct, forgot to mention that: threading.Event (https://docs.python.org/3/library/thread...nt-objects) is the simplest form for threads to communicate if "True/False" communication is sufficient. Just share the event object between threads.

Regards, noisefloor

[noisefloor]

A recent, IMHO pretty nice blog post on Python, Threads, GIL and no GIL, the need for locks and shared data can be found at this link: https://blog.jetbrains.com/pycharm/2025/...eter-lock/

Regards, noisefloor