Voici, un tableau récapitulatif de l'implémentation de la synchronisation pour les processus lourds et les processus légers.
Type | processus lourd, fork wait | processus lourd, sémaphore IPC | processus lourd, tube | processus lourd, message IPC | processus lourd, segment partagé | Java Thread |
---|---|---|---|---|---|---|
système de nommage | PID / getPId | cle IPC | interne | cle IPC | cle IPC | les objets |
nombre d'activités | 2 | N | 2 | N | N | N |
appel bloquant | wait() | p() | read() | receive() | non | syncronized/wait() |
communication | exit(p) | non | stream | message | taille du segment | les objets |
volume de la communication | 2 octets | non | non limité | taille de la boite aux lettres | non limité | machine virtuelle |
D'une manière générale, plus le nombre de tâches est élevé dans un programme, plus ce programme passe son temps à effectuer des verrouillages et plus il passe son temps à échanger des messages entre tâche. Autrement lorsque le nombre de tâche augmente trop, la programmation concourante ne permet plus d'augmenter la vitesse d'exécution du programme ou plus précisément de diminuer la durée de son chemin critique car le programme passe son temps à mettre en sommeil les taches qui le composent et à écrire des informations qui permettent l'échange d'information entre tâches. Ce phénomène est appelé le parallel slowdown ⇔ ralentissement parallèle.
D'ailleurs les applications sont souvent classées en fonction la fréquence à laquelle ses tâches dialoguent ou se synchronisent. Les applications ayant beaucoup d'échanges ou de synchronisations entre ses sous-tâches sont dite fine-grained à grain fin, celle qui ont au contraire peu d'échanges et de synchronisations sont dite coarse-grained c'est-à-dire à gros grain. L'algorithme est dit Embarrassingly parallel, c'est-à-dire de « parallélisme embarrassant » s'il n'y a aucun contact entre les sous-tâches. Ce dernier est le plus simple à programmer.