PureBasic

Bonjour à tous,

Quelques questions sur les threads. Soyez indulgent, j'essaye de comprendre le principe.

Je pose:
Prog1: programme principal
Thread1:programme 1 que je veux exécuter en parallele du prog1
Threadn:programme n que je veux exécuter en parallele du prog1
µMnem(Xn): instruction élémentaire éxécuté en un cycle processeur
Mnem(Xn): instruction assembleur
Macro(X): instruction Purebasic

Donc, instruction purebasic est la somme des instructions assembleurs elles même la somme de microinstructions processeur.

Mes questions:
Comment s'éxécute un thread en parallele d'un programme principal ?

prog1-macro(1)
thread1-macro(1)
threadn-macro(1)
...
prog1-macro(2)
thread1-macro(2)
threadn-macro(2)
etc ...

ou

prog1-Mnem(1)
thread1-Mnem(1)
threadn-Mnem(1)
...
prog1-Mnem(2)
thread1-Mnem(2)
threadn-Mnem(2)
etc...

ou

prog1-µMnem(1)
thread1-µMnem(1)
threadn-µMnem(1)
...
prog1-µMnem(2)
thread1-µMnem(2)
threadn-µMnem(2)
etc...

Sachant qu'ensuite, évidemment, suivant la structure du/des processeurs, toutes ses instructions sont traités en paralleles ou autre (pipeline plus ou moins longues/lentes etc)

Est ce que le purebasic permet d'assigner un thread à un coeur physique ?

Est ce que je me goure complétement sur le principe ?

Merci de m'expliquer

Salut,

En toute indulgence, je te dirais que les threads servent à rassurer l'utilisateur quand une tâche particulièrement astreignante s'exécute.

Exemple de tâche astreignante, en toute indulgence :
- Impression
- Téléchargement
- Conversion de données
- Etc...

En toute indulgence, je lis ce post, et je constate que, par défaut, un thread n'est pas propre à un coeur sauf si on l'y invite, ce qui n'est pas une mince affaire.

PS: Certaines instructions assembleur (comme les instructions de chaîne) peuvent être interrompues, mais c'est pour des raisons de gestion de mémoire virtuelle. Pour le reste du jeu d'instruction, je n'en sais rien (je ne pense pas mais ça demande vérif).

PS2: pourquoi demandes-tu de l'indulgence?

Je vais me servir d'un thread pour l'affichage...
prog principal: gestion des deplacement etc... bref, tout ce qui modifie la carte principale d'affichage (souris, deplacements, animations des sprites...)
thread1: affichage en soit des éléments présents dans la portion de carte visible l'écran.
thread2: pathfinding
thread3: IA
...

bref, j'ai besoin de savoir si les instructions d'affichages vont être perturbées en fct de ce que je fais avec les autres threads ou si l'affichage sera régulier ...

C'est possible d'utiliser un thread pour l'affichage ?

PS: je n'ai jamais l'idée de fureter sur le forum anglais je vais y jeter un coup d'oeil.

PS2: Je demande de l'indulgence car j'ai bien conscience d'être un nain qui essaye de grimper sur des épaules de géants... pour paraphraser. Alors je réclame l'indulgence des géants...

Si tu ouvre la fenêtre dans le thread je pense que tu peut gérer l'affichage dans ce dernier.

Pour ce qui est des perfs cela dépend du processeur. par exemple si le processeur gère l'hyperthreading il pourra faire tourner plusieurs thread sur un core dans le cas contraire un thread par core.

Après il pour ce qui est des données partagées tu devra utiliser les mutex pour éviter par exemple que deux thread tente d'accéder a la même chose (sa donne des choses amusantes et aléatoire). Il faut faire attention au mutex car ils bloquent l'exécution en attendant que la ressource soit accessible, c'est pourquoi il faut bien réfléchir a ton architecture avant de commencer a coder.

Je pense qu'on est plutôt une bande de nains de jardin

cha0s a écrit :Si tu ouvre la fenêtre dans le thread je pense que tu peut gérer l'affichage dans ce dernier.

Après il pour ce qui est des données partagées tu devra utiliser les mutex pour éviter par exemple que deux thread tente d'accéder a la même chose (sa donne des choses amusantes et aléatoire). Il faut faire attention au mutex car ils bloquent l'exécution en attendant que la ressource soit accessible, c'est pourquoi il faut bien réfléchir a ton architecture avant de commencer a coder.

Je ne devrais pas avoir besoin des mutex puisque ma routine d'affichage se contente de lire le tableau de jeu sans y modifier quoique ce soit (non ?)

Le problème est que l'on ne sait pas trop comment cela va réagir si deux processeur essaye d'accéder a la même donnée en même temp il faut faire des tests.

Code : Tout sélectionner

Global test = 5


Procedure Thread(Null)
  Protected n
    For n=1 To 10000000
    If Not (test = 5)
      Debug "erreur"
    EndIf
  Next n
EndProcedure


CreateThread(@Thread(), #Null)
Thread = CreateThread(@Thread(), #Null)
While IsThread(Thread) : Wend

essaye ceci moi j'ai pas de problème sur mon dual core je sait pas ce que sa donne sur un proco avec l'hyperthreading

cha0s a écrit : essaye ceci moi j'ai pas de problème sur mon dual core je sait pas ce que sa donne sur un proco avec l'hyperthreading

Marche tres bien sur mon P4

Sur mon portable core duo T2050 ca marche bien.

J'ai fais des essais sinon, pour lire les valeurs de mon tableau et afficher les éléments de décors, alors que, pendant ce temps la, ils sont aléatoirement modifiés par mon prog principal. Ca fonctionne tres bien sans mutex et même sans utiliser la protection /thread à la compilation.
Bon on verra en complexifiant si ca déconne...
Pour l'instant je suis vraiment content: plus d'animations à vitesses aléatoires comme par le passé même en essayant de morceler ma boucle d'affichage pour équilibrer la vitesse ...

Juste, parfois, à la fin du prog, je dois manuellement switcher (alt+Tab) pour revenir sur le bureau et tuer le programme. Je n'ai pas encore compris pourquoi... Peut être parce que j'ouvre l'ecran avec le prog principal (??) sans tenir compte de la recommandation de chaOs.

cha0s a écrit :Le problème est que l'on ne sait pas trop comment cela va réagir si deux processeur essaye d'accéder a la même donnée en même temp il faut faire des tests.

Je viens de faire un tour sur le forum anglais et effectivement je réalise que c'est un gros problème d'essayer d'animer proprement de nombreux éléments+traitement lourd en // avec un thread.

Ta remarque prend un autre relief du coup...
Si les deux coeurs essayent d'acceder : un en lecture et l'autre en écriture à la même case mémoire ... il se passe quoi ?
Il me semble que dans un proce pentium première (vieille?) génération, il y a une logique qui bloc un des deux traitement momentanément pour éviter ce genre de problème entre les différents pipelines (si je me rappelle bien U,V un truc comme ça) pas besoin de le gérer en soft (je me goure ?)
Je ne veux pas me meler de ce qui ne me regarde pas mais si Intel ne s'est pas posé ce genre de question en créant leur proce double quadri (etc) coeurs et qu'il (intel est male ou femelle ?? male je suppose sinon on dirait Unetel

) laisse ce soin au programmeur ... je suis inquiet

Donc effectivement g du bol, mais il va falloir utiliser les mutex pour bloquer les changements dans le tableau lors de ces lectures pour affichage... pffiou

It sucks !

Comment ils font nos amis qui ont codé leur superbe jeu de shoot'n up avec les astéroids pour l'affichage ?

Fig a écrit :Comment ils font nos amis qui ont codé leur superbe jeu de shoot'n up avec les astéroids pour l'affichage ?

heu ! on peut coder un jeux sans treads !!

les treads, sont surtout utile pour les "utilitaires " !!
pour encoder une video , tout en laissant la possibillité des faire autre chose

ou bien pour la routine de sauvegarde d'un fichier important, pour ne pas bloquer le process principal !!

mais pour un jeu, ça sert a rien les treads !!
enfin plutot , c'est pas indispensable !!

pour certain traitement en parallèle les timers, font tres bien l'affaire !!

Ce Pdf que j'ai trouvé au bout de l'article wikipédia explique vraiment en détail (contrairement à l'article wiki) l'interêt et comment fonctionne les threads (dont on peut effectivement se servir pour l'affichage à la condition que le prog tourne sur un multicoeur avec un syst d'exploitation pouvant en tirer parti comme xp; ce qui est/devient maintenant la norme.)

Pour ceux qui veulent vraiment comprendre...

http://perso.numericable.fr/~pdeiberale ... -leger.pdf

sur mon portable j'ai un mono-coeur (pentium M)et je peut faire tourner deux threads a la fois.

Bloquer un accès mémoire est a la charge du système d'exploitation pas du processeur sinon autant faire du java et bloquer la gestion de la mémoire :p.

Sinon comme la dit Dobro on utilise un thread seulement lorsque c'est vraiment utile. Si on a une action gourmande qui risque de bloquer l'application, la on peut utiliser un thread.

Noter que sur certain système d'exploitation les processus peuvent tourner sur un des cœurs disponibles (ce qui est géré par l'ordonnanceur) or si on a des taches de fonds utiles il vaut mieux éviter de monopoliser tout les cœurs pour une seule application.

cha0s a écrit :Le problème est que l'on ne sait pas trop comment cela va réagir si deux processeur essaye d'accéder a la même donnée en même temp il faut faire des tests.

Ça abouti généralement au plantage mémoire de l'appli (généralement un Invalid Memory Access ou un truc du genre). Tout comme pour les threads, il faut protéger les accès mémoire en y ajoutant des sémaphores lors des accès aux données (lecture & écriture).

J'ai cru lire qu'on pouvait choisir un processeur pour l'exécution ? Si c'est le cas, ça m'intéresse fortement ! Est - ce fiable ? Quel système est ciblé et comment fait - on ?

Euh... Je seconde la question de Cls.

PureBasic

Thread (encore...)

Thread (encore...)