Salut, je n'ai pas un niveau très élaboré en c++...même voir pas du tout. Mais je me demandais, comment arrive-on à faire un thread sans librairie?
Je pensais à quelque chose de très vague...qui ferais une fonction qui séparerais le main et le thread en suite de IF() ELSE().
Reste que je ne vois pas cela comme un thread à proprement parler.

Je pense que les thread sont "géré" grâce à des fonction écrite en langage assembleur (asm).
MAis à cette heure ci (01:52 am) j'ai du mal à penser .

Il n'y a pas de thread standard en C++ (du moins, pas encore). Tu peux utiliser l'API Win32 pour des threads sous Windows, ou alors les threads POSIX pour Linux et Mac OS X.

Ensuite, pour ces deux API, un thread est une fonction de C...

El roux : tu ne peux pas de manière portable réaliser un thread sans librairie. Je te conseille donc d'en utiliser une car

1) c'est portable
2) c'est plus simple
3) tu peux profiter d'un code efficace fait par des pro
4) réinventer la roue ne sers à rien.

ensuite si tu ne veux toujours pas : utilise l'API de ton OS

POSIX semble un bon choix... sinon boost, le passage à C++0x sera moins "difficile".

Juste une question, est ce que le langage D gère les threads ? (Parce que j'ai vu quelque part le mot clef synchronized avant le type de retour d'une fonction, qui montre un mutex )

http://www.digitalmars.com/d/2.0/phobos/std_thread.html

Mais tu aurais dû partir un sujet sur Autres langages.

ce n'était pas vraiment comment on peut en "faire" un, je peux déjà avec la sfml et utiliser d'autre libraries ne me parait pas vraiment un problème...je ne veux pas réinventer la roue
c'est plutôt une question de curieux, comment on les "creer" ces thread?
comment c'est fait? Et j'imagine qu'avec mon niveau actuel je n'y comprendrai pas grand chose, mais j'aimerais bien savoir pareil.

C'est l'OS qui s'en occupe. Il sépare les temps processeurs entre chaque processus et séparer le temps processus entre chaqu'un de ses threads.

Un peu comme une boucle à interuption?
C'est ce que j'essaye de déterminer, mais ca ne fais pas "vraiment" de sens pour un dual core, à moin que la séparation ne se fasse sans interuption.
Et cela reviendrait à dire que...
Tous les programmes ne fonctionnes que dans un petit intervalle de temps? Étant donné que chaque programme représente un peu un "thread", c'est un processus calculé par le processeur, cela veu dire que chacun des programmes tourne une fraction de seconde en boucle?

C'est assez compliqué et ce l'est encore plus pour le Dual-Core. Au moins l'OS s'en occupe très bien. En fait selon la priorité du processus il sera accorder du temps processeurs. C'est a dire que si tu as 10 processus à prioritée normal ils auront chaqu'un 10% du temps. Imaginons que le Processeurs est vieux et lent et qu'il n'effectue que 1000 instructions en 1 milliseconde et bien le processeur effectuera 100 instructions de chaque processus.

C'est à l'OS de décider comment il sépare les instructions et comment il les diriges au processeur.

Si je fais un programme qui gère x boucles séparées, tous executé et stoppé à la milliseconde près à tours de role, puis-je appeler ca un thread à proprement parlé ?

Citation : El roux

Si je fais un programme qui gère x boucles séparées, tous executé et stoppé à la milliseconde près à tours de role, puis-je appeler ca un thread à proprement parlé ?

C'est déjà un thread puisque tout programme en comporte au moins un. En C++, ce thread est lancé à l'entrée de la fonction main() et s'arrête à la fin de celle-ci.

Un thread est créé en appelant une fonction définie dans un API quelconque et en lui passant l'adresse d'une autre fonction. Le thread sera donc cette fonction, et il s'arrêtera à la fin de celle-ci.