> Le pire de tout c'est le 1:N , dans ce cas là grosso-modo c'est quasiment
> comme si les threads n'existait pas. Tout se dérouel en userland et totu est
> rattaché au même processus (donc au même thread kernel, donc au même CPU)
tout depend du point de vu et surtout de l'usage que l'on fait des threads.
Ainsi que je le disait precedement, les threads permettent d'offrir aux programmeurs un acces au paradigme de la programmation concurente qui peut s'averer plus adapté pour ecrire certains types de programmes.
Dans ce cas la, la gestion des threads en 1:N est bien souvent celle qui permet la gestion la plus fine pour le scheduler. Ainsi si tu considere la simulation d'un tres grand nombre d'entités et que tu a un imperatif de reactivité, ce mode est le plus adapté.
Je me pose d'ailleur une question : est il si simple de savoir si l'on gere plusieurs threads legers (géré par le langage ou user-land si on veut) en mode 1:N.
Apres tout lorsqu'on programme, le runtime du langage sur lequel on repose
peut tout a fait switcher plusieurs threads legers (si le langage integre bien sur les threads leger en interne, ce qui est loin d'être le cas de tout les langages) sur plusieurs threads kernell (process) si cela lui lui semble plus adapté à l'archi sur laquelle il repose, par exemple si le code s'execute sur du multi-core.
Il n'est en effet pas a la charge du programmeur d'un langage haut niveau de s'adresser directement à l'un ou l'autre des coeurs.
Donc au final pour arriver à la fin de cette digression alambiquée (c'est confu dans ma tete aussi) la gestion des threads par le kernel en 1:1 ne pose aucun probleme particulier, et n'empeche pas necessairement les langages qui permettent de faire de manière interne du 1:N d'un coté et de faire usage des threads kernel de l'autre, d'optenir du M:N.
Un langage generaliste moderne doit donc pouvoir offrir les moyens de programmer aisement de manière concurrente et ceci en permettant de gerer des threads user-land ET kernel-land.
Je pense au langage Haskell et plus particulierement à l'implementation GHC de celui-ci, pour laquelle une active discussion est mené pour gérer la concurrence.
[^] # Re: ...
Posté par brouillon . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 4.
> comme si les threads n'existait pas. Tout se dérouel en userland et totu est
> rattaché au même processus (donc au même thread kernel, donc au même CPU)
tout depend du point de vu et surtout de l'usage que l'on fait des threads.
Ainsi que je le disait precedement, les threads permettent d'offrir aux programmeurs un acces au paradigme de la programmation concurente qui peut s'averer plus adapté pour ecrire certains types de programmes.
Dans ce cas la, la gestion des threads en 1:N est bien souvent celle qui permet la gestion la plus fine pour le scheduler. Ainsi si tu considere la simulation d'un tres grand nombre d'entités et que tu a un imperatif de reactivité, ce mode est le plus adapté.
Je me pose d'ailleur une question : est il si simple de savoir si l'on gere plusieurs threads legers (géré par le langage ou user-land si on veut) en mode 1:N.
Apres tout lorsqu'on programme, le runtime du langage sur lequel on repose
peut tout a fait switcher plusieurs threads legers (si le langage integre bien sur les threads leger en interne, ce qui est loin d'être le cas de tout les langages) sur plusieurs threads kernell (process) si cela lui lui semble plus adapté à l'archi sur laquelle il repose, par exemple si le code s'execute sur du multi-core.
Il n'est en effet pas a la charge du programmeur d'un langage haut niveau de s'adresser directement à l'un ou l'autre des coeurs.
Donc au final pour arriver à la fin de cette digression alambiquée (c'est confu dans ma tete aussi) la gestion des threads par le kernel en 1:1 ne pose aucun probleme particulier, et n'empeche pas necessairement les langages qui permettent de faire de manière interne du 1:N d'un coté et de faire usage des threads kernel de l'autre, d'optenir du M:N.
Un langage generaliste moderne doit donc pouvoir offrir les moyens de programmer aisement de manière concurrente et ceci en permettant de gerer des threads user-land ET kernel-land.
Je pense au langage Haskell et plus particulierement à l'implementation GHC de celui-ci, pour laquelle une active discussion est mené pour gérer la concurrence.