How to use two threads (GUI and backend)

[pozz]

Il 26/10/2016 13:27, Antoon Pardon ha scritto:
> Op 26-10-16 om 12:22 schreef pozz:
>> Il 26/10/2016 09:13, pozz ha scritto:
>>> [...]
>>> When the user press Start button (the pressed handler is in the GUI
>>> class):
>>>
>>>   self.comm_active = True
>>>   threading.Thread(target=self.comm_thread).start()
>>>
>>> The backend thread is:
>>>
>>>   def comm_thread(self):
>>>     while self.comm_active:
>>>       self.device.get_status()
>>>       GLib.idle_add(self.polling_received)
>>>       time.sleep(1)
>>>     self.m.close()
>>> [...]
>>
>> Now I have some concerns even in using self.comm_active.  It is a boolean variable
>> accessed by the GUI thread (inside Start/Stop buttons handler) and backend thread
>> (in the "while self.comm_active" instruction).
>
>> Is it safe to access this variable from two different threads?
>> Should I implement a safer and more complex mechanism?  If yes, what mechanism?
>
> Accessing from multiple thread shouldn't be a problem. As long as you only change
> it in one thread.

I don't want to doubt what you have written, but... are you definitevely 
sure?  I tried to search for some authoritative documentation about this 
topic, but I couldn't find any.

I have many years of experiece in embedded firmware written in C for 
small microcontrollers, so I know the problems that could occur when a 
variable is read in one ISR (interrupt service routine) and written in 
the main loop (or viceversa).
ISR and main loop can be considered two threads. If the variable is 
32-bits and the microcontroller can't write atomically (without any 
interruption) a 32-bit variable, bad things could occur.

If the main loop is updating the variable from 0x01020304 to 0xA1A2A3A4 
and the change happens on a byte basis, the ISR could access a 
completely wrong value, for example 0x0102A3A4.

So the main question here is: does python *specification/standard* 
guarantees atomic operations? If yes, what are they?