dark calculator Ecris:

Bon je vais me mettre au multithreading mais se qui me casser les pieds avec, c'est le passsage de parametre et surtout leur recuperation mais bon je vais m'en remettre

En fait le passage de parametres à ton thread dépend un peu du système de threads. Mais quoi qu'il en soit puisque tu partages le meme espace mémoire tu peur agir de la facon suivante :

Je te propose un exemple en java (non pas parce que c'est ce que tu vas utiliser mais c'est un des plus simples que je connaisse et surtout c'est celui dont je me souviens le mieux, voici :

public class MonThread extends Thread {
  int param1;
  String param2;

  public MonThread(int p1, String p2) {
    param1 = p1;
    param2 = p2;
  }

  public void run() {
     // code execute par le thread.
     for (int i=0; i<p1; i++) {
       System.out.println(param2);
     }
  }

  public static void main(String[] args) {
     MonThread fil = new MonThread();

     // lancement du thread
     fil.start();

     // on attend qu'il ait fini son execution
     fil.join();
  }
}

Voici en 2 mots ce que ca fait :
En java tout est codé sous forme de classes, les threads y compris. En l'occurrence on va donc développer une classe héritant de java.lang.Thread. Le code exécuté par le thread sera celui contenu dans la méthode run(). Cette méthode a le meme role que main pour un programme. Puisqu'on travaille avec des objets, la méthode run() a accès aux champs de son objet. Ici 2 champs param1 et param2 qui sont affectés par le constructeur.
Enfin on lance le thread sur une instance de cette classe avec la méthode start() (cf. main exemple)

Comprends bien ceci :
le multithreading a l'avantage de multiplier les fils d'exécution tout en partageant la même zone de mémoire (les variables, pointeurs etc). Aussi les différents threads vont accéder aux mêmes variables. Donc pour "configurer" un thread (ce que tu appelles à juste titre passage de parametres par analogie avec le main), il faut renseigner des variables et ensuite lancer le thread. Celui-ci "doit" consulter ces variables pour etre configuré. La condition est naturellement que ce code ait accès à ces variables (problème de portée). En C il suffit d'utiliser des variables globales, en C++ comme en Java et tout langage POO, une instance de classe est le plus naturel et le plus pertinent.

• ---

dark calculator Ecris:

Sinon est ce que je dois faire attention a que tous les threads n'accedent pas a la meme donne en meme temps ou ca n'a pas d'importance ?

Ceci est de ta responsabilité !
En fait ce problème n'a d'impact que sur la viabilité de tes données. Si 2 threads accèdent en meme temps à la même variable et que les opérations effectuées ne sont pas atomiques, il y a un risque important que ces opérations se fasse en même temps et que cela ait des conséquences facheuses. Tu ne maitrises pas l'ordonnancement, c'est à dire l'ordre dans lequel les threads sont executés (je rappelle qu'on ne peut pas faire tourner 2 threads au meme moment sur le meme cpu (ou du moins sur le meme coeur de cpu...)). C'est le "systeme" (la JVM pour java, le noyau en C/C++) qui décide de quel thread s'execute.

Ainsi pour eviter les problèmes (et quand cela est indispensable) on cherche à protéger certaines sections de codes de toute préemption (cad de perte du CPU au profit d'un autre thread). Ces sections de codes sont nommées "sections critiques" car elle doivent être protégées. Généralement on code cela avec des verrous, selon le schéma suivant :
1) acquisition du verrou
2) section critique
3) libération du verrou

Tu comprendras facilement que ces aspects là sont très rapidement pénibles. Mais également souvent indispensable. Aussi quand on développe un programme parallele il convient à un moment donné de déterminer quel sections de codes sont critiques (de point de vue accès concurrentiel) et comment il faudra les protéger.

Dans ton cas je ne pense pas "a priori" qu'il y en ait.
Ceci est du à 2 choses :
Les actions critiques sont celles qui modifient le modèle. Celui-ci ne sera a priori pas modifié en meme temps par 2 joueurs (tu peux interdire les actions du joueur tant que l'adversaire n'a pas joué, et finalement ca crée des sections critiques).
Les actions de modifications seront pour la plupart atomiques. On dit qu'une action est atomique quand elle ne peut pas etre interrompue par le système, exemple : affectation, incrémentation opération binaire ou unaire. Cela dépend un peu d'un systeme / langage à l'autre, mais ca reste un concept commun à toute l'informatique parallèle.


Je pense que tu as compris par toi même qu'un programme, même modeste, a très vite besoin de beaucoup de petites briques. Cependant il est indispensable de commencer par des programmes modestes pour maîtriser les concepts élémentaires et réussir à produire quelque chose qui marche.
Après le passage à une plus grande échelle n'est souvent qu'une question de temps (donc de moyens).

bon courage

fred