Qu'est-ce que le «stockage local des threads» en Python et pourquoi en ai-je besoin?

En Python en particulier, comment les variables sont-elles partagées entre les threads?

Bien que j'aie utilisé threading.Threadavant, je n'ai jamais vraiment compris ou vu des exemples de partage des variables. Sont-ils partagés entre le fil principal et les enfants ou seulement entre les enfants? Quand aurais-je besoin d'utiliser le stockage local des threads pour éviter ce partage?

J'ai vu de nombreux avertissements sur la synchronisation de l'accès aux données partagées entre les threads à l'aide de verrous, mais je n'ai pas encore vu un très bon exemple du problème.

Merci d'avance!

En Python, tout est partagé, à l'exception des variables locales de fonction (car chaque appel de fonction obtient son propre ensemble de paramètres locaux et les threads sont toujours des appels de fonction séparés.) Et même dans ce cas, seules les variables elles-mêmes (les noms qui font référence aux objets) sont locaux à la fonction; les objets eux-mêmes sont toujours globaux et tout peut s'y référer. L' Threadobjet d'un thread particulier n'est pas un objet spécial à cet égard. Si vous stockez l' Threadobjet à un endroit accessible à tous les threads (comme une variable globale), tous les threads peuvent accéder à cet Threadobjet. Si vous souhaitez modifier de manière atomique tout ce à quoi un autre thread a accès, vous devez le protéger avec un verrou. Et tous les threads doivent bien sûr partager ce même verrou, sinon ce ne serait pas très efficace.

Si vous voulez un stockage réel local des threads, c'est là threading.localqu'intervient. Les attributs de threading.localne sont pas partagés entre les threads; chaque thread ne voit que les attributs qu'il y a lui-même placés. Si vous êtes curieux de connaître sa mise en œuvre, la source se trouve dans _threading_local.py dans la bibliothèque standard.

Considérez le code suivant:

#/usr/bin/env python

from time import sleep
from random import random
from threading import Thread, local

data = local()

def bar():
    print("I'm called from", data.v)

def foo():
    bar()

class T(Thread):
    def run(self):
        sleep(random())
        data.v = self.getName()   # Thread-1 and Thread-2 accordingly
        sleep(1)
        foo()

>> T (). Start (); T (). Début ()
Je suis appelé depuis Thread-2
Je suis appelé depuis Thread-1 

Ici, threading.local () est utilisé comme un moyen rapide et sale de passer des données de run () à bar () sans changer l'interface de foo ().

Notez que l'utilisation de variables globales ne fera pas l'affaire:

#/usr/bin/env python

from time import sleep
from random import random
from threading import Thread

def bar():
    global v
    print("I'm called from", v)

def foo():
    bar()

class T(Thread):
    def run(self):
        global v
        sleep(random())
        v = self.getName()   # Thread-1 and Thread-2 accordingly
        sleep(1)
        foo()

>> T (). Start (); T (). Début ()
Je suis appelé depuis Thread-2
Je suis appelé depuis Thread-2 

En attendant, si vous pouviez vous permettre de passer ces données comme argument de foo (), ce serait un moyen plus élégant et bien conçu:

from threading import Thread

def bar(v):
    print("I'm called from", v)

def foo(v):
    bar(v)

class T(Thread):
    def run(self):
        foo(self.getName())

Mais ce n'est pas toujours possible lors de l'utilisation de code tiers ou mal conçu.

Vous pouvez créer un stockage local de thread à l'aide de threading.local().

>>> tls = threading.local()
>>> tls.x = 4 
>>> tls.x
4

Les données stockées dans le tls seront uniques à chaque thread, ce qui aidera à garantir qu'aucun partage involontaire ne se produira.

Comme dans tous les autres langages, chaque thread en Python a accès aux mêmes variables. Il n'y a pas de distinction entre le «thread principal» et les threads enfants.

Une différence avec Python est que le Global Interpreter Lock signifie qu'un seul thread peut exécuter du code Python à la fois. Cependant, cela n'aide pas beaucoup pour la synchronisation de l'accès, car tous les problèmes de préemption habituels s'appliquent toujours et vous devez utiliser des primitives de thread comme dans d'autres langues. Cela signifie toutefois que vous devez reconsidérer si vous utilisiez des threads pour les performances.

Je me trompe peut-être ici. Si vous savez le contraire, veuillez expliquer car cela aiderait à expliquer pourquoi il faudrait utiliser thread local ().

Cette déclaration semble éteinte, pas fausse: "Si vous voulez modifier de manière atomique tout ce à quoi un autre thread a accès, vous devez le protéger avec un verrou." Je pense que cette déclaration est -> effectivement <- correcte mais pas tout à fait exacte. Je pensais que le terme "atomique" signifiait que l'interpréteur Python créait un bloc d'octet-code qui ne laissait aucune place pour un signal d'interruption au CPU.

Je pensais que les opérations atomiques sont des morceaux de code octet Python qui ne donnent pas accès aux interruptions. Les instructions Python comme "running = True" sont atomiques. Vous n'avez pas besoin de verrouiller le CPU des interruptions dans ce cas (je crois). La ventilation du code d'octet Python est à l'abri de l'interruption de thread.

Le code Python comme "threads_running [5] = True" n'est pas atomique. Il y a deux morceaux de code d'octet Python ici; un pour dé-référencer la liste () pour un objet et un autre morceau de code d'octet pour attribuer une valeur à un objet, dans ce cas un "endroit" dans une liste. Une interruption peut être déclenchée -> entre <- les deux octets-code -> morceaux <-. C'est là que de mauvaises choses se produisent.

Quel est le rapport entre thread local () et "atomic"? C'est pourquoi la déclaration me semble mal orientée. Sinon, pouvez-vous expliquer?