Ce qui ne l'thread_local moyenne en C++11?

Je suis confondue avec la description de thread_local en C++11. Ma compréhension est, chaque thread a copie unique de variables locales à une fonction. La global/variables statiques peuvent être consultées par tous les threads (éventuellement accès synchronisé à l'aide des verrous). Et le thread_local variables sont visibles pour tous les threads, mais ne peut que modifié par le thread pour lequel ils sont définis? Est-il correct?

InformationsquelleAutor polapts | 2012-08-16

c++c++11 multithreading thread-local thread-local-storage

114

Locale de Thread durée de stockage est un terme utilisé pour se référer à des données qui est en apparence globale ou statique de la durée de stockage (du point de vue des fonctions de l'utiliser), mais en réalité, il existe un exemplaire par thread.

Qu'il ajoute à l'automatique en cours (cours bloc/de fonction), statique (qui n'existe que pour la durée du programme) et dynamique (il existe sur le tas entre l'allocation et la libération).

Quelque chose qui est thread-local est amenés à l'existence, à la création de threads et éliminés lorsque le thread s'arrête.

Quelques exemples suivre.

Penser à un générateur de nombre aléatoire où la graine doit être maintenu sur une base par thread. À l'aide d'un fil-de semences locales qui signifie que chaque thread possède sa propre séquence des nombres aléatoires, indépendantes des autres threads.

Si votre semence est une variable locale dans la fonction aléatoire, il serait initialisé à chaque fois que vous l'avez appelé, vous donnant le même nombre à chaque fois. Si c'était un mondial, fils d'interférer les uns avec les autres séquences.

Un autre exemple est quelque chose comme strtok où la tokenisation état est stocké sur un fil spécifique. De cette façon, un seul thread peut être sûr que les autres threads ne pas bousiller son tokenisation efforts, tout en étant capable de maintenir l'état sur les appels multiples à strtok - ce fondamentalement rend strtok_r (la version thread-safe) redondant.

Ces deux exemples permettent de le thread variable locale d'exister dans la fonction qui l'utilise. En pré-threaded code, ce serait tout simplement une statique de la durée de stockage de la variable dans la fonction. Pour les threads, c'est modifié au fil local de stockage durée.

Encore un autre exemple serait quelque chose comme errno. Vous ne voulez pas des threads séparés modifiant errno après que l'un de vos appels échoue, mais, avant, vous pouvez vérifier la variable, et pourtant vous ne voulez une copie par thread.

Ce site a une description raisonnable de différentes durée de stockage des prescripteurs.
- +1 pour le strtok suggestion!
- À l'aide de fil local ne résout pas les problèmes avec strtok. strtok est brisé, même dans un seul thread de l'environnement.
- Désolé, permettez-moi de reformuler ce que. Il n'introduit pas d' nouvelles problèmes avec strtok 🙂
- En fait, la r est l'acronyme de "re-venu", qui n'a rien à voir avec la sécurité des threads. Il est vrai que vous pouvez faire certaines choses fonctionnent fil en toute sécurité avec du fil de stockage local, mais vous ne pouvez pas les faire ré-entrant.
- Dans un seul thread de l'environnement, les fonctions doivent être ré-entrant uniquement si elles font partie d'un cycle dans le graphe d'appel. Une feuille de fonction (celle qui n'a pas d'appeler d'autres fonctions) est, par définition, ne fait pas partie d'un cycle, et il n'y a aucune bonne raison de strtok devrait en appeler d'autres fonctions.
- ce serait louper: while (something) { char *next = strtok(whatever); someFunction(next); // someFunction calls strtok }
- Vous avez des problèmes si vous (essayer de) s'entrelacent deux strtok des séquences dans un thread; - dire, si vous êtes le traitement de deux cordes en même temps. C'est là que le réentrant variantes venir dans maniable (plus c'est plus propre --- non globales sont accessibles).
- Un thread_local object appelle sa deallocator à la fin de la discussion ?
- Je suppose qu'un autre exemple pourrait être celui d'une thread_local Allocateur de l'objet qui pourrait être utilisé pour allouer de la mémoire avec de nouvelles/le placement de nouveaux quoi que ce soit sur le tas. En d'autres termes, les différentes mémoire allouée par thread.
InformationsquelleAutor paxdiablo
106

Lorsque vous déclarez une variable thread_local puis chaque thread possède sa propre copie. Lorsque vous le désigner par son nom, puis la copie associés avec le thread courant est utilisé. par exemple,
```
thread_local int i=0;

void f(int newval){
    i=newval;
}

void g(){
    std::cout<<i;
}

void threadfunc(int id){
    f(id);
    ++i;
    g();
}

int main(){
    i=9;
    std::thread t1(threadfunc,1);
    std::thread t2(threadfunc,2);
    std::thread t3(threadfunc,3);

    t1.join();
    t2.join();
    t3.join();
    std::cout<<i<<std::endl;
}
```
Ce code de sortie "2349", "3249", "4239", "4329", "2439" ou "3429", mais jamais rien d'autre. Chaque thread possède sa propre copie de i, qui est affecté, incrémenté puis imprimé. Le thread en cours d'exécution main a également sa propre copie, ce qui est attribué au début et puis à gauche inchangé. Ces copies sont entièrement indépendants, et chacun a une adresse différente.

C'est seulement la nom qui est spécial à cet égard --- si vous prenez l'adresse d'un thread_local variable, alors vous avez juste normal d'un pointeur vers un objet normal, que vous pouvez passer librement entre les threads. par exemple,
```
thread_local int i=0;

void thread_func(int*p){
    *p=42;
}

int main(){
    i=9;
    std::thread t(thread_func,&i);
    t.join();
    std::cout<<i<<std::endl;
}
```
Depuis l'adresse de i est passé à la fonction de thread, puis la copie de i appartenant au thread principal peut être affecté, même si elle est thread_local. Ce programme permettra donc de sortie "42". Si vous le faites, alors vous devez prendre soin que *p n'est pas accessible après le thread qu'il appartient à a quitté, sinon vous obtiendrez un bancales pointeur et un comportement indéterminé comme tout autre cas où la pointe-à l'objet est détruit.

thread_local les variables sont initialisées "avant la première utilisation", donc si ils ne sont jamais touchés par un thread donné alors qu'ils ne sont pas nécessairement toujours initialisé. Ceci afin de permettre aux compilateurs pour éviter de construire tous les thread_local variable dans le programme pour un thread qui est entièrement autonome et ne touchez pas l'un d'eux. par exemple,
```
struct my_class{
    my_class(){
        std::cout<<"hello";
    }
    ~my_class(){
        std::cout<<"goodbye";
    }
};

void f(){
    thread_local my_class;
}

void do_nothing(){}

int main(){
    std::thread t1(do_nothing);
    t1.join();
}
```
Dans ce programme il y a 2 fils: le thread principal et de la main-créé fil. Aucun thread appelle f, de sorte que le thread_local objet n'est jamais utilisé. Il n'est donc pas spécifié si le compilateur va construire 0, 1 ou 2 cas de my_class, et le résultat peut être "", "hellohellogoodbyegoodbye" ou "hellogoodbye".
- Je pense qu'il est important de noter que le fil d'une copie locale de la variable est une nouvelle initialisé copie de la variable. C'est, si vous ajoutez un g() appel au début de threadFunc, alors la sortie sera 0304029 ou une autre permutation des paires 02, 03, et 04. Qui est, même si 9 est attribué à i avant la création de threads, les fils se fraîchement construit copie de i où i=0. Si i est attribué, avec thread_local int i = random_integer(), puis chaque thread obtient un nouveau nombre entier aléatoire.
- Pas exactement une permutation de 02, 03, 04, il y a peut être d'autres séquences comme 020043
InformationsquelleAutor Anthony Williams
20

Thread-local de stockage est dans tous les aspects comme statique (= global) de stockage, seulement que chaque thread a une copie de l'objet. L'objet de temps de la vie commence au début de fil (pour les variables globales) ou au début de l'initialisation (pour bloc locales statiques), et se termine lorsque le thread se termine (c'est à dire quand join() est appelé).

Par conséquent, seules les variables qui pourraient également être déclaré static peut être déclaré comme thread_local, c'est à dire des variables globales (plus précisément: les variables "à portée espace de noms"), les membres de classe statiques, et le bloc des variables statiques (dans ce cas, static est implicite).

Comme un exemple, supposons que vous disposez d'un pool de threads et vous voulez savoir comment bien votre charge de travail est équilibrée:
```
thread_local Counter c;

void do_work()
{
    c.increment();
    //...
}

int main()
{
    std::thread t(do_work);   //your thread-pool would go here
    t.join();
}
```
Ce serait d'imprimer thread statistiques d'utilisation, par exemple, avec une mise en œuvre comme ceci:
```
struct Counter
{
     unsigned int c = 0;
     void increment() { ++c; }
     ~Counter()
     {
         std::cout << "Thread #" << std::this_thread::id() << " was called "
                   << c << " times" << std::endl;
     }
};
```
InformationsquelleAutor Kerrek SB

Vous devez vous connecter pour publier un commentaire.