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?
--
https://mail.python.org/mailman/listinfo/python-list
