programmation asynchrone : plusieurs traitement sont réalisé au sein d'un même flux de programmation (program flow).
Ce ne serait pas plutôt l'idée qu'il est possible de faire des appels non-bloquants depuis le flow actuel pour lancer des traitements "en parallèle" (donc dans un autre flow ? Que faut-il appeler un flow ? Pour moi la notion était purement séquentielle !). Les résultats peuvent ensuite être attendus (par l'entremise d'un appel sur un futur ou une promesse).
Quant à la discussion sur la distinction entre parallélisme et concurrence. La différence se situerait effectivement dans le niveau d'abstraction.
Je vais donner "mes" définitions succinctes :
parallélisme : exécution simultanée de plusieurs tâches (suppose l'existence de plusieurs unités d'exécution indépendantes). Le cas le plus pur étant l'exécution de tâches sur des processeurs physiquement distincts.
concurrence : exécution de front de tâches causalement indépendantes
Considérant qu'une tâche peut consister à simuler une unité d'exécution (dans un paradigme plus haut niveau), plusieurs tâches indépendantes peuvent simuler des unités d'exécution indépendantes. Ainsi la concurrence au niveau d'abstraction n correspond au parallélisme du niveau n+1.
Supposons qu'on programme avec l'API threads de son langage préféré. Alors 2 tâches s'exécutant sur des threads différents s'exécutent en parallèle du point de vue de l'API exposée. Pourtant, du point de vue de la machine, si elle est mono-core, l'exécution n'est que concurrente.
Maintenant, si au lieu de programmer les tâches directement sur les threads, on les soumet plutôt à un ThreadPoolExecutor (Java) utilisant un seul thread, même du point de vue de l'API thread, l'exécution est seulement concurrente.
[^] # Re: Rx
Posté par Aldoo . En réponse au journal La programmation concurrente en mode Goto. Évalué à 4.
Ce ne serait pas plutôt l'idée qu'il est possible de faire des appels non-bloquants depuis le flow actuel pour lancer des traitements "en parallèle" (donc dans un autre flow ? Que faut-il appeler un flow ? Pour moi la notion était purement séquentielle !). Les résultats peuvent ensuite être attendus (par l'entremise d'un appel sur un futur ou une promesse).
Cette définition cadre avec Wikipedia(en).
Quant à la discussion sur la distinction entre parallélisme et concurrence. La différence se situerait effectivement dans le niveau d'abstraction.
Je vais donner "mes" définitions succinctes :
Considérant qu'une tâche peut consister à simuler une unité d'exécution (dans un paradigme plus haut niveau), plusieurs tâches indépendantes peuvent simuler des unités d'exécution indépendantes. Ainsi la concurrence au niveau d'abstraction n correspond au parallélisme du niveau n+1.
Supposons qu'on programme avec l'API threads de son langage préféré. Alors 2 tâches s'exécutant sur des threads différents s'exécutent en parallèle du point de vue de l'API exposée. Pourtant, du point de vue de la machine, si elle est mono-core, l'exécution n'est que concurrente.
Maintenant, si au lieu de programmer les tâches directement sur les threads, on les soumet plutôt à un ThreadPoolExecutor (Java) utilisant un seul thread, même du point de vue de l'API thread, l'exécution est seulement concurrente.