Comportement de l'objet dans multithread

Question

J'essaie d'utiliser boost::thread_group pour gérer mes threads. La conception était telle que chaque thread dans le groupe de thread invoque une séquence de foncteurs de struct A.

pseudocode:

struct A { 
    int n; 
    vector p; 

    void operator()() { 
     for(number_of_steps) // Do computations involving members n, p, x and y. 
    } 
private: 
    float x; 
    vector y; 
}; 

struct parallel_A : boost::thread_group { 
    parallel_A(const A* a) : m_a(a) { 
     for(number_of_cpu) { 
      create_thread(inner_struct(this)); 
     } 
    } 

    void run() { 
     (*m_a)(); 
    } 
private: 
    struct inner_struct { 
     parallel_A* a; 

     inner_struct(parallel_A* _a) : a(_a) {} 

     void operator()() { 
      a->run(); 
     } 
    } 
    const A* m_a; 
} 

Ma question est:

1. Est-ce que les variables de données n, p, x et y et le calcul dans l'objet A, être intercalés par les discussions?

2. Si nous devions aller plus loin en ayant plus d'appels à Functor A pour chaque CPU, par exemple 1 fil pour 1 CPU et pour chaque thread 4 plus invocation de foncteur A pour faire le calcul, quel sera le comportement termes de l'état des variables et le calcul de A?

Answer 1

1. Basé sur le code:

   for(number_of_cpu) { 
       create_thread(inner_struct(this)); 
   

   la même valeur du pointeur this sera transmis à tous les fils et donc les fils partagent la même n, p, x et y variables de données. Les calculs de A seront entrelacés dans tous les cas (sauf éventuellement pour les sections critiques) mais maintenant que les calculs partagent les mêmes variables de données, il est fort probable qu'un calcul utilisera des valeurs intermédiaires pour un autre calcul entraînant une corruption de données.

   Je suggère qu'une certaine forme de stockage local-thread soit utilisée ici en définissant un tableau d'objets A et/ou en utilisant un mécanisme formel tel que boost::thread_specific_ptr.

2. Si le stockage local n'est pas utilisé (le code ci-dessus est conservé tel quel), l'ajout d'invocations du foncteur A augmente les risques de corruption des données.

   Si un stockage local à thread est utilisé, puisque les instructions sont toujours exécutées séquentiellement dans un thread, l'ajout de 4 invocations du foncteur A dans chaque thread signifie que le calcul prendra environ 5 fois plus de temps. Cela suppose qu'aucun sous-threads n'est créé dans chaque thread pour gérer les appels supplémentaires.