Les "threads natifs" sont des contextes d'exécution distincts, gérés par le noyau du système d'exploitation, accédant à un espace mémoire partagé et pouvant s'exécuter simultanément sur des cœurs distincts. Comparez cela aux processus distincts, qui peuvent s'exécuter simultanément sur plusieurs cœurs mais disposent d'espaces mémoire séparés. Il est facile de s'assurer que les processus interagissent bien puisqu'ils ne peuvent communiquer entre eux que par l'intermédiaire du noyau. S'assurer que les threads n'interagissent pas de manière imprévisible et boguée est très difficile, car ils peuvent lire et écrire dans la même mémoire de manière illimitée.
La situation de R est assez simple : R n'est pas multithreadé . Python est un peu plus compliqué : Python prend en charge le threading, mais en raison de l'utilisation de la fonction verrouillage global de l'interpréteur (GIL) Dans ce cas, aucune exécution simultanée du code Python n'est possible. D'autres langages dynamiques open source populaires se trouvent dans divers états mitigés en ce qui concerne le threading natif (Ruby : non/un peu/oui ? Node.js : pas de ), mais en général, la réponse est non, ils ne supportent pas le threading natif totalement concurrent, donc Julia n'est pas seule dans ce cas.
Quand nous ajouterons le parallélisme de la mémoire partagée à Julia, comme nous prévoyons de le faire - que l'on utilise des threads natifs ou des processus multiples avec mémoire partagée - il s'agira d'une véritable concurrence et il n'y aura pas de GIL empêchant l'exécution simultanée du code Julia. Cependant, c'est une fonctionnalité incroyablement délicate à ajouter à un langage, comme en témoigne le support inexistant ou limité dans d'autres langages dynamiques matures et très populaires. Ajouter un modèle de concurrence en mémoire partagée est techniquement difficile, mais le vrai problème est de concevoir un modèle de programmation qui permettra aux programmeurs d'utiliser efficacement la concurrence matérielle d'une manière productive et sûre. Ce problème n'est généralement pas résolu et constitue un domaine très actif de recherche et d'expérimentation - il n'y a pas de "norme d'excellence" à copier. Nous pourrions simplement ajouter le support des threads POSIX, mais ce modèle de programmation est généralement considéré comme dangereux et incroyablement difficile à utiliser correctement et efficacement. Go a une excellente histoire de concurrence, mais il est conçu pour écrire des serveurs hautement concurrents, pas pour opérer simultanément sur de grandes données, donc il n'est pas du tout clair que copier simplement le modèle de Go est une bonne idée pour Julia.
