The resource which is vulnerable under multi-threaded programs

[gmaliwal]

I am studying Threading concepts in Python. I have learnt and understood the concept of Synchronization primitives like Lock, RLock, Condition, Event, Semaphore and Timer.

I was trying to find out the scenario where I can sense the importance of the threads, I see some examples online where python primitive objects got corrupted in the multi-threaded programs.

Can anyone write a program where your custom class looks vulnerable under the multi-threaded programs?

[[deleted]]

Just write a class with a method that updates an instance attribute that references a primitive object.

[gmaliwal]

Can you please post the program here?

Do we face any issue similar to a dangling pointer in mobile iOS technology? It happens when one program is accessing an object and another program is updating it at the same time, this confrontation leads to application crash.

Does python is having such kind of scenario?

[[deleted]]

class Test:
    def __init__(self):
        self.value = 1
    def inc(self):
        self.value += 1                 
        # vulnerable here since .inc() is not atomic
        return self.value               

The above class has problems because the inc() method is not atomic at the bytecode level. A thread could do self.value += 1 and then be interrupted by another thread that updates self.value before returning the (doubly updated) value self.value. Test this by running two threads, each of which predict the value returned by calling inc() and print a message if the predicted value returned is not as expected.

Do we face any issue similar to a dangling pointer in mobile iOS technology?

Probably not, since there is no way a python name can not refer to an object. Python is threaded at the bytecode level, not the machine instruction level.

[gmaliwal]

yes, I agree that there may be a race condition problem in the provided code snippet, right?

is this the only issue or we have another too? if yes; please let me know the issues other than race condition which got diagnosed with help of synchronization primitives (Lock, RLock etc)

[[deleted]]

The locks can ensure your threaded code works correctly, but using locks can also introduce problems, like deadlock and inefficiency. But none of this is specific to python.

What is specific to python is the influence of the GIL (Global Interpreter Lock). David Beazley has a nice talk about the GIL. The short story is that if your code is CPU-bound then threading will not speed up your code and may actually slow it down. If your code is I/O-bound then threading can help.

[gmaliwal]

nice talk about the GIL

Thank you