Discussion :

[PP(Team)]

Bonjour,

J'ai besoin de faire du multiphreading, mais quand je trouve quelquechose, il ne fait pas quelque de très simple : gèrer les threads en même temps (cf fork() ), et non pas l'un après l'autre.
Quand je pense que ca marche, c'est juste que le temps est trop court pour que le pc puisse voir la différence.

voici le code que j'ai trouvé pour le moment :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 
#include <boost/thread/mutex.hpp>
#include <boost/thread/xtime.hpp>
#include <boost/thread/thread.hpp>
#include <iostream>
 
boost::mutex io_mutex; // The iostreams are not guaranteed to be thread-safe!
 
class counter
{
public:
    counter() : count(0) { }
 
    int increment() {
        boost::mutex::scoped_lock scoped_lock(mutex);
        return ++count;
    }
 
private:
    boost::mutex mutex;
    int count;
};
 
counter c;
 
void change_count()
{
    int i = c.increment();
    boost::mutex::scoped_lock scoped_lock(io_mutex);
 
    //D'abord, testez avec les commentaires, puis enlevez les
    // boost::xtime xt;
    //boost::xtime_get(&xt, boost::TIME_UTC);
    //xt.sec += m_secs;
 
    //boost::thread::sleep(xt);
 
    std::cout << "count == " << i << std::endl;
}
 
int main(int, char*[])
{
    const int num_threads = 4;
    boost::thread_group thrds;
    for (int i=0; i < num_threads; ++i)
        thrds.create_thread(&change_count);
 
    thrds.join_all();
 
    return 0;
}

Code très simple montrant bien le problème (je trouve ).

[khayyam90]

Bien le bonjour,

J'ai regardé rapidement, mais ton code a l'air de fonctionner.
Tu protèges l'incrémentation du compteur et tu protèges le std::cout.
Tu as également pris soin d'utiliser deux mutex différents, les ressources sont donc correctement protégées.

Par contre, je mettrais boost::mutex::scoped_lock scoped_lock(io_mutex); du cout juste avant l'appel à std::cout<< et pas avant le sleep. Enfin ça dépend si tu autorises que plusieurs threads puissent dormir en même temps ou pas.

[PP(Team)]

Bien le bonjour,

J'ai regardé rapidement, mais ton code a l'air de fonctionner.
Tu protèges l'incrémentation du compteur et tu protèges le std::cout.
Tu as également pris soin d'utiliser deux mutex différents, les ressources sont donc correctement protégées.

Par contre, je mettrais boost::mutex::scoped_lock scoped_lock(io_mutex); du cout juste avant l'appel à std::cout<< et pas avant le sleep. Enfin ça dépend si tu autorises que plusieurs threads puissent dormir en même temps ou pas.

D'accord, ce code ne plante pas, mais les processus s'enchainent, en attendant l'un l'autre que le précédent se finisse (il me semble).
Hors, j'ai besoin que tous soient lancé en même temps.

[khayyam90]

Non, les threads ne se lancent pas une fois que le précédent est terminé.
Ils se lancent tous au début et ensuite chacun vit sa vie jusqu'à ce que la fonction change_count soit terminée. Tu ne peux pas faire de prévision sur l'ordre d'exécution, c'est géré par le système d'exploitation, même si tu peux te douter que le premier thread a de fortes chances de se finir avant le dernier.
Les 4 threads lancés sont en parallèles et tout ce dont tu es sûr, c'est que les ressources (le std::cout et le compteur) sont protégées des accès concurrents.

[JolyLoic]

En mettant le mutex avant le sleep (qui est là où le thread passe le plus clair de son temps) et jusqu'à la fin du thread, c'est toi qui empêche leur exécution en parallèle. Si tu mets dans ton code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
void change_count()
{
    int i = c.increment();
 
    //D'abord, testez avec les commentaires, puis enlevez les
    // boost::xtime xt;
    //boost::xtime_get(&xt, boost::TIME_UTC);
    //xt.sec += m_secs;
 
    //boost::thread::sleep(xt);
    { 
        boost::mutex::scoped_lock scoped_lock(io_mutex);
        std::cout << "count == " << i << std::endl;
    }
}

Tu devrait avoir un comportement plus proche de ce que tu imagines (même si rien n'empêche qu'il exécute les affichages dans l'ordre.

[nicroman]

Je vais peut-être dire une bétise... mais il n'existe pas de "multi-threading" pur sur un processeur unique (simple core), et la granularité de switch (thread quantum) entre les threads est assez "grosse":
Sous windows, de l'ordre de 94ms sur ma machine, au minimum 15,625ms sur d'autres OS, vu que c'est la fréquence des clock-interrupts.

Ce qui veut dire, qu'un thread qui ne durerait 'que' 94ms (sans jamais rendre son 'quantum' avec un sleep(0)) n'à aucun interêt. Mais aussi que 'n' threads d'une durée inférieur à 94ms seront toujours executés séquentiellement.
Et avec les machines actuelles, en 94ms... on en fait des choses !

Si tu fais un 'sleep' constant dans chaque thread, le seule résultat sera de décaler l'éxecution... Essaye avec un cout avant le sleep (ceux là apparaitront tous d'un coup, séquentiellement), et apres le sleep (a nouveau, tous séquentiellement).

Et je ne sais pas comment boost répartit les threads entre plusieurs core/cpu quand ils sont disponible...

[PP(Team)]

Bon, j'ai trouvé un tutoriel excellent, qui montre chaque aspect des phreads, notamment :
-2 threads
-n threads
-n threads et sémaphore
-n threads et zone critique.

Je n'ai plus le lien ici, mais j'essayerais de vous le donner dès que je reprend le boulot (lundi).

Même si ce n'est pas avec Boost, mais bon, tant que ca marche....