./10 > SI tu devais choisir une fréquence au pif, tu aurais plutôt intérêt à choisir 60Hz ou un multiple… Particulièrement depuis le passage aux écrans LCD, c'est très rare de trouver des écrans avec des fréquences autres que 60Hz (ou le 59,94Hz du HDMI…)
Sinon, si SDL n'est pas capable de gérer le VSync en mode fenêtré, le problème vient certainement directement de SDL et pas de Windows… (La synchro VSync en mode fenêtré est peut-être moins fiable (ne marche pas forcément sur *n'importe quelle* config logicielle/matérielle), mais c'est malgré tout une fonctionnalité supportée…)

Sinon, tu auras un autre problème avec les threads, c'est que le rendu graphique ne peut pas être partagé proprement entre plusieurs threads. (Un seul doit s'en occuper, sauf avec des API récents comme DX11)

Et pour le coup, j'insisterai spécifiquement sur cette partie du post de Kevin:

Kevin Kofler (./3) :
Désavantages:[ul][li]nécessitent souvent des synchronisations (ou des opérations atomiques, mais ce n'est pas toujours possible et suffisant) à quelques endroits, alors que le problème ne se pose pas si on a le contrôle sur quand on exécute quoi[/li][li]risque de deadlocks (si on synchronise de manière incorrecte)[/li][/ul]

Kevin Kofler (./9) :
Et d'ailleurs, le x86 est plus flexible en ce qui concerne les opérations atomiques, tu peux mettre un lock; devant presque toutes les instructions pour les rendre atomiques.

Note d'ailleurs qu'un certain nombre d'opérations mémoire sont atomiques par nature en x86 et que le préfixe lock n'est pas toujours nécessaire dans ce cas de figure précis. En revanche, lock a d'autres utilités…



Et donc le pourquoi du comment de utiliser des threads… (Question initiale, non ?)
Ben c'est compliqué parce qu'il y a plusieurs raisons possibles. Tu peux vouloir utiliser des threads pour traiter de manière parallèle des évènements parallèles (connexions réseau ^^); ou bien pour diviser le temps de calcul d'un gros calcul par jusqu'à ton nombre de CPU ; ou bien pour gérer séparément des ressources qui sont séparées et qui ont des contraintes d'accès différentes… (interface graphique vs traitement long en arrière plan)
Les possibilités sont bien sûr plus étendues quand tu possèdes plusieurs cœurs CPU, puisque tu as la possibilité de faire effectuer plein de travail vraiment parallèle à ton CPU ou bien d'économiser de l'énergie (en travaillant moins fort/plus vite, donc moins longtemps), sinon, en dehors de ça, les threads vont surtout te servir à simplifier ton développement en te permettant de découpler différents traitements entre eux. (typiquement le truc de l'interface graphique et du traitement en arrière plan)