Über eine Globale variable mit einem thread

In einer Funktion:

a += 1

wird vom compiler interpretiert werden als assign to a => Create local variable a, das ist nicht, was Sie wollen. Es wird wahrscheinlich fehl mit eine a not initialized Fehler, da die (lokalen) a hat in der Tat nicht initialisiert wurde:

>>> a = 1
>>> def f():
...     a += 1
... 
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in f
UnboundLocalError: local variable 'a' referenced before assignment

Könnten Sie bekommen, was Sie wollen, mit dem (sehr verpönt, und aus guten Gründen) global Schlüsselwort, etwa so:

>>> def f():
...     global a
...     a += 1
... 
>>> a
1
>>> f()
>>> a
2

Im Allgemeinen sollten Sie jedoch vermeiden Verwendung von globalen Variablen, die werden extrem schnell von der hand. Und dies gilt insbesondere für Multithread-Programme, wo Sie keine Synchronisations-Mechanismus für Ihre thread1 zu wissen, Wann a geändert wurde. Kurzum: threads sind kompliziert, und Sie können nicht erwarten, haben ein intuitives Verständnis der Reihenfolge, in der die Ereignisse passiert sind, wenn zwei (oder mehr) threads, die Arbeit auf den gleichen Wert. Die Sprache, compiler, Betriebssystem, Prozessor... können ALLE spielen eine Rolle und entscheiden zum ändern der Reihenfolge der Operationen für Geschwindigkeit, Funktionalität oder anderen Gründen.

Den richtigen Weg für diese Art der Sache ist die Verwendung von Python-sharing-tools (sperren
und Freunde), oder besser, zu kommunizieren, Daten über ein Warteschlange statt Sie zu teilen, z.B. wie folgt:

from threading import Thread
from queue import Queue
import time

def thread1(threadname, q):
    #read variable "a" modify by thread 2
    while True:
        a = q.get()
        if a is None: return # Poison pill
        print a

def thread2(threadname, q):
    a = 0
    for _ in xrange(10):
        a += 1
        q.put(a)
        time.sleep(1)
    q.put(None) # Poison pill

queue = Queue()
thread1 = Thread( target=thread1, args=("Thread-1", queue) )
thread2 = Thread( target=thread2, args=("Thread-2", queue) )

thread1.start()
thread2.start()
thread1.join()
thread2.join()

Vielen Dank Jason Pan für die Annahme, dass die Methode. Die thread1 if-Anweisung ist nicht atomar, so dass, während diese Anweisung ausgeführt wird, ist es möglich, dass Thread2 verzahnt zu stören auf thread1, dass nicht-erreichbaren code zu erreichen. Ich habe organisiert, die Ideen aus der vorherigen Beiträge in ein vollständiges Demo-Programm (unten), lief ich mit Python 2.7.

Mit einigen nachdenklich Analyse ich bin mir sicher, dass wir gewinnen konnten weitere Einblicke, aber für jetzt ich denke, es ist wichtig, um zu zeigen, was passiert, wenn nicht-Atomare Verhalten erfüllt threading.

# ThreadTest01.py - Demonstrates that if non-atomic actions on
# global variables are protected, task can intrude on each other.
from threading import Thread
import time

# global variable
a = 0; NN = 100

def thread1(threadname):
    while True:
      if a % 2 and not a % 2:
          print("unreachable.")
    # end of thread1

def thread2(threadname):
    global a
    for _ in range(NN):
        a += 1
        time.sleep(0.1)
    # end of thread2

thread1 = Thread(target=thread1, args=("Thread1",))
thread2 = Thread(target=thread2, args=("Thread2",))

thread1.start()
thread2.start()

thread2.join()
# end of ThreadTest01.py

Wie vorhergesagt, in Sie das Beispiel ausführen, die "nicht erreichbar" - code manchmal auch tatsächlich zu erreichen, produzieren Ausgabe.

Nur um, wenn ich eingefügt, der eine Sperre erwerben/release-pair-Mädchen in thread1 fand ich, dass die Wahrscheinlichkeit, dass die "nicht erreichbar" Nachricht drucken wurde stark reduziert. Um zu sehen, die Nachricht, die ich reduziert die einschlafzeit um 0,01 Sek. und erhöht NN 1000.

Mit einem lock acquire/release-pair-Mädchen in thread1 ich hatte nicht erwartet, um zu sehen, die Nachricht an alle, aber es ist da. Nachdem ich eingefügt, der eine Sperre erwerben/release-paar auch in Thread2 verzahnt, wird die Nachricht nicht mehr erschienen. Im hinteren signt die Inkrement-Anweisung, die in Thread2 verzahnt wohl auch nicht atomar.