Bien que les technologies de multi-threading comme de multi-core offrent de nombreux avantages, l'intérêt de telles solutions est bien entendu soumis à la condition d'avoir plusieurs threads en exécution simultanée. Certes, le système d'exploitation à lui seul en comporte un grand nombre, mais la plupart sont en idle la majeure partie du temps, du moins comparativement à un thread prioritaire comme lors de l'exécution d'un jeu vidéo. Il faut donc que les programmeurs fassent l'effort d'envisager la programmation de leur programme d'une nouvelle façon, avec autant de threads qu'il y a de processeurs, si possible. Et justement, cela n'est pas toujours possible, parfois pour des raisons purement mathématiques, comme pour le cas des suites numériques admettant une relation entre deux termes consécutifs. Dans ce type de cas de figure, il est impossible de programmer l'application de manière à allouer par exemple le calcul de Un+1 à un thread et celui de Un+2 à un autre, car le calcul d'Un+2 ne peut se faire que connaissant le résultat d'Un+1.

Si les suites posent un problème a priori insurmontable, d'origine purement mathématique, certains programmes ne pourraient être exécutés sur deux threads pour des raisons d'ordre pratique, et l'analyseur syntaxique temps réel YOUM de www.onversity.com en est un bon exemple. Ledit YOUM a pour but d'analyser tout texte se trouvant sur Onversity, et de créer des liens sur des mots (ou des groupes de mots) présents dans un dictionnaire associé. Étant bien optimisé et d'une exécution rapide, dite "temps réel", YOUM n'a pas réellement besoin d'être "multi-threadé". Néanmoins, s'il devait l'être, il faudrait par exemple séparer le texte en deux parties, que chaque thread prendrait en charge. Or, si une telle chose était faite, alors on trouverait des mots associés à un lien plusieurs fois, à cause de la présence d'un historique pour chaque thread. Il faudrait donc une mémoire partagée, déjà plus complexe à réaliser. De plus, il subsisterait toujours un problème : en admettant que le thread 0 commence l'analyse à la ligne 1 d'un texte de 40 lignes, et le thread 1 à la ligne 20, alors la division serait équitable, mais si le mot "RAM", par exemple, apparaît à la ligne 10 et à la ligne 25, alors il y a de très fortes chances pour que celui de la ligne 25 soit analysé et donc associé par le thread 1 à un lien avant que celui de la ligne 10 ne le soit par le thread 0. Le lien se trouverait donc en plein milieu du texte, et non à la première occurrence du mot. Lors de la lecture, pour des raisons de confort, il est préférable d'avoir le lien au début.

Certes, ce point n'est qu'un détail, et ne serait pas si gênant que ça, mais le cas illustre parfaitement toutes les difficultés de programmation que peut présenter le portage d'un programme sur plusieurs threads, ainsi que l'intérêt tout relatif d'un tel portage. Dans ce cas précis, un deuxième core serait donc parfaitement inutile.