> > C'est bien possible. Mais je vois aucun rapport entre ce que tu viens de > dire et la norme POSIX.
LES POSIX_THREAD font partie d'une norme POSIX.
Je suis loin de bien connaître ce sujet, mais il me semble qu'il existe des implémentations de la norme posix des threads, purement en userland, par exemple les gnu pth. Même si les implémentations performantes font appel à une partie dans le kernel (c'est le cas des threads de Linux ou de FreeBSD). Dans ce cas ça tendrait à prouver que Stéphane a raison, si on se place du point de vue de l'utilisateur de ces threads, en première approximation il se fout de savoir si l'implémentation est userland ou kernelland. En deuxième il ne s'en fout pas si l'implémentation est incomplète ou a des performances désastreuses, mais c'est une autre question.
--
Michel TALON
Richard Delorme <abulmo@nospam.fr> wrote:
>
> C'est bien possible. Mais je vois aucun rapport entre ce que tu viens de
> dire et la norme POSIX.
LES POSIX_THREAD font partie d'une norme POSIX.
Je suis loin de bien connaître ce sujet, mais il me semble qu'il existe
des implémentations de la norme posix des threads, purement en userland,
par exemple les gnu pth. Même si les implémentations performantes font
appel à une partie dans le kernel (c'est le cas des threads de Linux ou
de FreeBSD). Dans ce cas ça tendrait à prouver que Stéphane a raison, si
on se place du point de vue de l'utilisateur de ces threads, en première
approximation il se fout de savoir si l'implémentation est userland ou
kernelland. En deuxième il ne s'en fout pas si l'implémentation est
incomplète ou a des performances désastreuses, mais c'est une autre
question.
> > C'est bien possible. Mais je vois aucun rapport entre ce que tu viens de > dire et la norme POSIX.
LES POSIX_THREAD font partie d'une norme POSIX.
Je suis loin de bien connaître ce sujet, mais il me semble qu'il existe des implémentations de la norme posix des threads, purement en userland, par exemple les gnu pth. Même si les implémentations performantes font appel à une partie dans le kernel (c'est le cas des threads de Linux ou de FreeBSD). Dans ce cas ça tendrait à prouver que Stéphane a raison, si on se place du point de vue de l'utilisateur de ces threads, en première approximation il se fout de savoir si l'implémentation est userland ou kernelland. En deuxième il ne s'en fout pas si l'implémentation est incomplète ou a des performances désastreuses, mais c'est une autre question.
--
Michel TALON
pehache-tolai
On 23 juil, 10:21, JKB wrote:
Le 23-07-2009, ? propos de Re: Pour mettre tout le monde d'accord: Window9, pehache-tolai ?crivait dans fr.comp.os.linux.debats :
> On 23 juil, 08:53, Richard Delorme wrote:
>> LES POSIX_THREAD font partie d'une norme POSIX.
> et ils sont implémentée dans Windows, si je ne m'abuse.
Raté. Pas sous Vista. L'implantation est là :
http://sourceware.org/pthreads-win32/
Le type a fait un énorme boulot, mais c'est à peu pr ès du niveau de Cygwin en terme de fiabilité. Tant qu'on reste sur un UP, ça fonction ne à peu près, en SMP, c'est plus aléatoire (c'est même inscrit en n oir sur blanc dans la page bugs).
OK. En plus ça n'a pas l'air activement développé et maintenu.
-- pehache
On 23 juil, 10:21, JKB <knatsc...@koenigsberg.fr> wrote:
Le 23-07-2009, ? propos de
Re: Pour mettre tout le monde d'accord: Window9,
pehache-tolai ?crivait dans fr.comp.os.linux.debats :
> On 23 juil, 08:53, Richard Delorme <abu...@nospam.fr> wrote:
>> LES POSIX_THREAD font partie d'une norme POSIX.
> et ils sont implémentée dans Windows, si je ne m'abuse.
Raté. Pas sous Vista. L'implantation est là :
http://sourceware.org/pthreads-win32/
Le type a fait un énorme boulot, mais c'est à peu pr ès du niveau de
Cygwin en terme de fiabilité. Tant qu'on reste sur un UP, ça fonction ne
à peu près, en SMP, c'est plus aléatoire (c'est même inscrit en n oir sur
blanc dans la page bugs).
OK. En plus ça n'a pas l'air activement développé et maintenu.
Le 23-07-2009, ? propos de Re: Pour mettre tout le monde d'accord: Window9, pehache-tolai ?crivait dans fr.comp.os.linux.debats :
> On 23 juil, 08:53, Richard Delorme wrote:
>> LES POSIX_THREAD font partie d'une norme POSIX.
> et ils sont implémentée dans Windows, si je ne m'abuse.
Raté. Pas sous Vista. L'implantation est là :
http://sourceware.org/pthreads-win32/
Le type a fait un énorme boulot, mais c'est à peu pr ès du niveau de Cygwin en terme de fiabilité. Tant qu'on reste sur un UP, ça fonction ne à peu près, en SMP, c'est plus aléatoire (c'est même inscrit en n oir sur blanc dans la page bugs).
OK. En plus ça n'a pas l'air activement développé et maintenu.
-- pehache
talon
pehache-tolai wrote:
On 23 juil, 08:53, Richard Delorme wrote: > > LES POSIX_THREAD font partie d'une norme POSIX.
et ils sont implémentée dans Windows, si je ne m'abuse.
-- pehache
En tout cas il existe des librairies dont le but principal est de masquer la différence entre Unix et Windows et d'offrir une interface commune aux threads, par exemple chez Boost.
--
Michel TALON
pehache-tolai <pehache.7@gmail.com> wrote:
On 23 juil, 08:53, Richard Delorme <abu...@nospam.fr> wrote:
>
> LES POSIX_THREAD font partie d'une norme POSIX.
et ils sont implémentée dans Windows, si je ne m'abuse.
--
pehache
En tout cas il existe des librairies dont le but principal est de
masquer la différence entre Unix et Windows et d'offrir une interface
commune aux threads, par exemple chez Boost.
On 23 juil, 08:53, Richard Delorme wrote: > > LES POSIX_THREAD font partie d'une norme POSIX.
et ils sont implémentée dans Windows, si je ne m'abuse.
-- pehache
En tout cas il existe des librairies dont le but principal est de masquer la différence entre Unix et Windows et d'offrir une interface commune aux threads, par exemple chez Boost.
--
Michel TALON
remy
Richard Delorme a écrit :
Le 23/07/2009 07:11, Stephane TOUGARD a écrit :
JKB wrote:
Tu ne comprends rien à rien et tu ne t'es _jamais_ posé la question de savoir ce qu'est un mutex ni a fortiori une opération atomique (au passage, si on savait faire ça en userland, ça simplifierait pas mal le boulot des développeurs et ça éviterait aussi de se taper le développement d'une libc sous Unix). Implanter de tels trucs en userland pose un tas de problèmes, en particulier d'atomicité. Même en kernelland, c'est difficile à faire (c'est pour cela que linuxthreads a été abandonné au profit de NPTL car linuxthreads n'était en particulier pas capable de rendre sem_post() async safe.). Retourne jouer aux billes.
C'est bien possible. Mais je vois aucun rapport entre ce que tu viens de dire et la norme POSIX.
LES POSIX_THREAD font partie d'une norme POSIX.
c'est possible je n'en sais rien
par contre là si je ne m'abuse la problématique est tout autre
si le thread est en userland cela revient à redécouper le temps du process en sous ensemble
et si le thread est dans le noyau cela offre la posibilité exploitée ou pas je n'en sais rien, de considérer le thread comme un processus indépendant du process qui a lancé le thread d'un point de vue de la gestion du temps machine
toute la subtilité doit se cacher dans les méandres de la norme posix
parce que à l'époque où je codais en java les thread étaient un sous ensemble de process java ,mais ils n''étaient peut être pas posix je ne me suis pas posé la question a l'epoque
remy
-- http://remyaumeunier.chez-alice.fr/
Richard Delorme a écrit :
Le 23/07/2009 07:11, Stephane TOUGARD a écrit :
JKB wrote:
Tu ne comprends rien à rien et tu ne t'es _jamais_ posé la question
de savoir ce qu'est un mutex ni a fortiori une opération atomique (au
passage, si on savait faire ça en userland, ça simplifierait pas mal le
boulot des développeurs et ça éviterait aussi de se taper le
développement d'une libc sous Unix). Implanter de tels trucs en userland
pose un tas de problèmes, en particulier d'atomicité. Même en
kernelland, c'est difficile à faire (c'est pour cela que linuxthreads a
été abandonné au profit de NPTL car linuxthreads n'était en particulier
pas capable de rendre sem_post() async safe.). Retourne jouer aux billes.
C'est bien possible. Mais je vois aucun rapport entre ce que tu viens de
dire et la norme POSIX.
LES POSIX_THREAD font partie d'une norme POSIX.
c'est possible je n'en sais rien
par contre là si je ne m'abuse la problématique est tout autre
si le thread est en userland cela revient à redécouper le temps du
process en sous ensemble
et si le thread est dans le noyau cela offre la posibilité exploitée
ou pas je n'en sais rien, de considérer le thread comme un processus
indépendant du process qui a lancé le thread
d'un point de vue de la gestion du temps machine
toute la subtilité doit se cacher dans les méandres de la norme posix
parce que à l'époque où je codais en java les thread étaient un sous
ensemble de process java ,mais ils n''étaient peut être pas posix je
ne me suis pas posé la question a l'epoque
Tu ne comprends rien à rien et tu ne t'es _jamais_ posé la question de savoir ce qu'est un mutex ni a fortiori une opération atomique (au passage, si on savait faire ça en userland, ça simplifierait pas mal le boulot des développeurs et ça éviterait aussi de se taper le développement d'une libc sous Unix). Implanter de tels trucs en userland pose un tas de problèmes, en particulier d'atomicité. Même en kernelland, c'est difficile à faire (c'est pour cela que linuxthreads a été abandonné au profit de NPTL car linuxthreads n'était en particulier pas capable de rendre sem_post() async safe.). Retourne jouer aux billes.
C'est bien possible. Mais je vois aucun rapport entre ce que tu viens de dire et la norme POSIX.
LES POSIX_THREAD font partie d'une norme POSIX.
c'est possible je n'en sais rien
par contre là si je ne m'abuse la problématique est tout autre
si le thread est en userland cela revient à redécouper le temps du process en sous ensemble
et si le thread est dans le noyau cela offre la posibilité exploitée ou pas je n'en sais rien, de considérer le thread comme un processus indépendant du process qui a lancé le thread d'un point de vue de la gestion du temps machine
toute la subtilité doit se cacher dans les méandres de la norme posix
parce que à l'époque où je codais en java les thread étaient un sous ensemble de process java ,mais ils n''étaient peut être pas posix je ne me suis pas posé la question a l'epoque
remy
-- http://remyaumeunier.chez-alice.fr/
JKB
Le 23-07-2009, ? propos de Re: Pour mettre tout le monde d'accord: Window9, remy ?crivait dans fr.comp.os.linux.debats :
Richard Delorme a écrit :
Le 23/07/2009 07:11, Stephane TOUGARD a écrit :
JKB wrote:
Tu ne comprends rien à rien et tu ne t'es _jamais_ posé la question de savoir ce qu'est un mutex ni a fortiori une opération atomique (au passage, si on savait faire ça en userland, ça simplifierait pas mal le boulot des développeurs et ça éviterait aussi de se taper le développement d'une libc sous Unix). Implanter de tels trucs en userland pose un tas de problèmes, en particulier d'atomicité. Même en kernelland, c'est difficile à faire (c'est pour cela que linuxthreads a été abandonné au profit de NPTL car linuxthreads n'était en particulier pas capable de rendre sem_post() async safe.). Retourne jouer aux billes.
C'est bien possible. Mais je vois aucun rapport entre ce que tu viens de dire et la norme POSIX.
LES POSIX_THREAD font partie d'une norme POSIX.
c'est possible je n'en sais rien
par contre là si je ne m'abuse la problématique est tout autre
si le thread est en userland cela revient à redécouper le temps du process en sous ensemble
et si le thread est dans le noyau cela offre la posibilité exploitée ou pas je n'en sais rien, de considérer le thread comme un processus indépendant du process qui a lancé le thread d'un point de vue de la gestion du temps machine
toute la subtilité doit se cacher dans les méandres de la norme posix
parce que à l'époque où je codais en java les thread étaient un sous ensemble de process java ,mais ils n''étaient peut être pas posix je ne me suis pas posé la question a l'epoque
Oh pétard !... J'espère qu'avec une telle compréhension, tu ne codes pas des trucs sensibles avec les threads Posix...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 23-07-2009, ? propos de
Re: Pour mettre tout le monde d'accord: Window9,
remy ?crivait dans fr.comp.os.linux.debats :
Richard Delorme a écrit :
Le 23/07/2009 07:11, Stephane TOUGARD a écrit :
JKB wrote:
Tu ne comprends rien à rien et tu ne t'es _jamais_ posé la question
de savoir ce qu'est un mutex ni a fortiori une opération atomique (au
passage, si on savait faire ça en userland, ça simplifierait pas mal le
boulot des développeurs et ça éviterait aussi de se taper le
développement d'une libc sous Unix). Implanter de tels trucs en userland
pose un tas de problèmes, en particulier d'atomicité. Même en
kernelland, c'est difficile à faire (c'est pour cela que linuxthreads a
été abandonné au profit de NPTL car linuxthreads n'était en particulier
pas capable de rendre sem_post() async safe.). Retourne jouer aux billes.
C'est bien possible. Mais je vois aucun rapport entre ce que tu viens de
dire et la norme POSIX.
LES POSIX_THREAD font partie d'une norme POSIX.
c'est possible je n'en sais rien
par contre là si je ne m'abuse la problématique est tout autre
si le thread est en userland cela revient à redécouper le temps du
process en sous ensemble
et si le thread est dans le noyau cela offre la posibilité exploitée
ou pas je n'en sais rien, de considérer le thread comme un processus
indépendant du process qui a lancé le thread
d'un point de vue de la gestion du temps machine
toute la subtilité doit se cacher dans les méandres de la norme posix
parce que à l'époque où je codais en java les thread étaient un sous
ensemble de process java ,mais ils n''étaient peut être pas posix je
ne me suis pas posé la question a l'epoque
Oh pétard !... J'espère qu'avec une telle compréhension, tu ne codes
pas des trucs sensibles avec les threads Posix...
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 23-07-2009, ? propos de Re: Pour mettre tout le monde d'accord: Window9, remy ?crivait dans fr.comp.os.linux.debats :
Richard Delorme a écrit :
Le 23/07/2009 07:11, Stephane TOUGARD a écrit :
JKB wrote:
Tu ne comprends rien à rien et tu ne t'es _jamais_ posé la question de savoir ce qu'est un mutex ni a fortiori une opération atomique (au passage, si on savait faire ça en userland, ça simplifierait pas mal le boulot des développeurs et ça éviterait aussi de se taper le développement d'une libc sous Unix). Implanter de tels trucs en userland pose un tas de problèmes, en particulier d'atomicité. Même en kernelland, c'est difficile à faire (c'est pour cela que linuxthreads a été abandonné au profit de NPTL car linuxthreads n'était en particulier pas capable de rendre sem_post() async safe.). Retourne jouer aux billes.
C'est bien possible. Mais je vois aucun rapport entre ce que tu viens de dire et la norme POSIX.
LES POSIX_THREAD font partie d'une norme POSIX.
c'est possible je n'en sais rien
par contre là si je ne m'abuse la problématique est tout autre
si le thread est en userland cela revient à redécouper le temps du process en sous ensemble
et si le thread est dans le noyau cela offre la posibilité exploitée ou pas je n'en sais rien, de considérer le thread comme un processus indépendant du process qui a lancé le thread d'un point de vue de la gestion du temps machine
toute la subtilité doit se cacher dans les méandres de la norme posix
parce que à l'époque où je codais en java les thread étaient un sous ensemble de process java ,mais ils n''étaient peut être pas posix je ne me suis pas posé la question a l'epoque
Oh pétard !... J'espère qu'avec une telle compréhension, tu ne codes pas des trucs sensibles avec les threads Posix...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
Michel Talon, dans le message <h497so$lf5$, a écrit :
Je suis loin de bien connaître ce sujet, mais il me semble qu'il existe des implémentations de la norme posix des threads, purement en userland, par exemple les gnu pth.
Le P de GNU pth ne veut pas dire POSIX, il veut dire portable, et ce ne sont pas des threads POSIX, mais alors vraiment pas du tout.
Les GNU pth sont des threads coopératifs (par opposition à préemptifs) : les tâches commutent quand elles arrivent à des points de commutation, explicites ou implicites (dans les fonctions d'entrées-sorties bloquantes).
Michel Talon, dans le message <h497so$lf5$1@asmodee.lpthe.jussieu.fr>, a
écrit :
Je suis loin de bien connaître ce sujet, mais il me semble qu'il existe
des implémentations de la norme posix des threads, purement en userland,
par exemple les gnu pth.
Le P de GNU pth ne veut pas dire POSIX, il veut dire portable, et ce ne sont
pas des threads POSIX, mais alors vraiment pas du tout.
Les GNU pth sont des threads coopératifs (par opposition à préemptifs) : les
tâches commutent quand elles arrivent à des points de commutation,
explicites ou implicites (dans les fonctions d'entrées-sorties bloquantes).
Michel Talon, dans le message <h497so$lf5$, a écrit :
Je suis loin de bien connaître ce sujet, mais il me semble qu'il existe des implémentations de la norme posix des threads, purement en userland, par exemple les gnu pth.
Le P de GNU pth ne veut pas dire POSIX, il veut dire portable, et ce ne sont pas des threads POSIX, mais alors vraiment pas du tout.
Les GNU pth sont des threads coopératifs (par opposition à préemptifs) : les tâches commutent quand elles arrivent à des points de commutation, explicites ou implicites (dans les fonctions d'entrées-sorties bloquantes).
remy
JKB a écrit :
Oh pétard !... J'espère qu'avec une telle compréhension, tu ne codes pas des trucs sensibles avec les threads Posix...
je n'ai pratiquement jamais écrit du code en langage C, dans le pratiquement tu peux noter une petite exception pour un driver linux bête et méchant mais rien de très compliqué une carte entre sortie proprio
tout le code haut niveau (base de donnée, applicatif ) c'est du java alors les thread posix ....
je te les laisse sans aucune arrière pensée :-)
mais je te rassure j'ai codé pas mal d'applicatif multi thread, enfin de compte n'importe quel code java qui dépasse les 10 k de code source ,est relativement efficace, se doit de les implémenter
remy
-- http://remyaumeunier.chez-alice.fr/
JKB a écrit :
Oh pétard !... J'espère qu'avec une telle compréhension, tu ne codes
pas des trucs sensibles avec les threads Posix...
je n'ai pratiquement jamais écrit du code en langage C, dans le
pratiquement tu peux noter une petite exception pour un driver linux
bête et méchant mais rien de très compliqué une carte entre sortie
proprio
tout le code haut niveau (base de donnée, applicatif ) c'est du java
alors les thread posix ....
je te les laisse sans aucune arrière pensée :-)
mais je te rassure j'ai codé pas mal d'applicatif multi thread,
enfin de compte n'importe quel code java qui dépasse les 10 k de code
source ,est relativement efficace, se doit de les implémenter
Oh pétard !... J'espère qu'avec une telle compréhension, tu ne codes pas des trucs sensibles avec les threads Posix...
je n'ai pratiquement jamais écrit du code en langage C, dans le pratiquement tu peux noter une petite exception pour un driver linux bête et méchant mais rien de très compliqué une carte entre sortie proprio
tout le code haut niveau (base de donnée, applicatif ) c'est du java alors les thread posix ....
je te les laisse sans aucune arrière pensée :-)
mais je te rassure j'ai codé pas mal d'applicatif multi thread, enfin de compte n'importe quel code java qui dépasse les 10 k de code source ,est relativement efficace, se doit de les implémenter
remy
-- http://remyaumeunier.chez-alice.fr/
Stephane TOUGARD
Toxico Nimbus wrote:
Si l'implémentation complète de la norme POSIX sous Windows requiert impérativement du code exécuté en mode noyau, et que Microsoft ne veut pas écrire ce code, alors Windows ne sera jamais POSIX. Même Cygwin ne peut pas toucher au noyau Windows.
Sais tu quels systemes sont 100% POSIX ?
Les BSD ne le sont pas, meme Linux ne doit pas faire le compte. Windows NT 3.51 est POSIX.1, on est loin du compte pour dire que NT est une implementation complete de POSIX. Il en va bien sur de meme avec Cygwin, il est clair et net que des parties de la normes sont zapees.
Mais ca ne fait pas de Cygwin un emulateur POSIX. Ca en fait une implementation partielle.
Toxico Nimbus wrote:
Si l'implémentation complète de la norme POSIX sous Windows requiert
impérativement du code exécuté en mode noyau, et que Microsoft ne veut
pas écrire ce code, alors Windows ne sera jamais POSIX. Même Cygwin ne
peut pas toucher au noyau Windows.
Sais tu quels systemes sont 100% POSIX ?
Les BSD ne le sont pas, meme Linux ne doit pas faire le compte. Windows
NT 3.51 est POSIX.1, on est loin du compte pour dire que NT est une
implementation complete de POSIX. Il en va bien sur de meme avec Cygwin,
il est clair et net que des parties de la normes sont zapees.
Mais ca ne fait pas de Cygwin un emulateur POSIX. Ca en fait une
implementation partielle.
Si l'implémentation complète de la norme POSIX sous Windows requiert impérativement du code exécuté en mode noyau, et que Microsoft ne veut pas écrire ce code, alors Windows ne sera jamais POSIX. Même Cygwin ne peut pas toucher au noyau Windows.
Sais tu quels systemes sont 100% POSIX ?
Les BSD ne le sont pas, meme Linux ne doit pas faire le compte. Windows NT 3.51 est POSIX.1, on est loin du compte pour dire que NT est une implementation complete de POSIX. Il en va bien sur de meme avec Cygwin, il est clair et net que des parties de la normes sont zapees.
Mais ca ne fait pas de Cygwin un emulateur POSIX. Ca en fait une implementation partielle.
pehache-tolai
On 23 juil, 09:08, Toxico Nimbus wrote:
Si l'implémentation complète de la norme POSIX sous Windows requiert impérativement du code exécuté en mode noyau, et que Microsoft ne v eut pas écrire ce code, alors Windows ne sera jamais POSIX. Même Cygwin n e peut pas toucher au noyau Windows.
Peut-être, mais ça ne change rien au débat "cygwin est-il une implémentation ou une émulation de la norme POSIX".
Pour ma part je suis d'accord avec ST, c'est une implémentation (peut- être incomplète) et pas une émulation.
-- pehache
On 23 juil, 09:08, Toxico Nimbus <T...@free.fr> wrote:
Si l'implémentation complète de la norme POSIX sous Windows requiert
impérativement du code exécuté en mode noyau, et que Microsoft ne v eut
pas écrire ce code, alors Windows ne sera jamais POSIX. Même Cygwin n e
peut pas toucher au noyau Windows.
Peut-être, mais ça ne change rien au débat "cygwin est-il une
implémentation ou une émulation de la norme POSIX".
Pour ma part je suis d'accord avec ST, c'est une implémentation (peut-
être incomplète) et pas une émulation.
Si l'implémentation complète de la norme POSIX sous Windows requiert impérativement du code exécuté en mode noyau, et que Microsoft ne v eut pas écrire ce code, alors Windows ne sera jamais POSIX. Même Cygwin n e peut pas toucher au noyau Windows.
Peut-être, mais ça ne change rien au débat "cygwin est-il une implémentation ou une émulation de la norme POSIX".
Pour ma part je suis d'accord avec ST, c'est une implémentation (peut- être incomplète) et pas une émulation.
-- pehache
talon
Nicolas George <nicolas$ wrote:
Michel Talon, dans le message <h497so$lf5$, a écrit : > Je suis loin de bien connaître ce sujet, mais il me semble qu'il existe > des implémentations de la norme posix des threads, purement en userland, > par exemple les gnu pth.
Le P de GNU pth ne veut pas dire POSIX, il veut dire portable, et ce ne sont pas des threads POSIX, mais alors vraiment pas du tout.
Comme je disais, je ne suis pas du tout spécialiste. Cependant sur la première page de Gnu pth je lis:
Pth is a very portable POSIX/ANSI-C based library for Unix platforms which provides non-preemptive priority-based scheduling for multiple threads of execution (aka ``multithreading'') inside event-driven applications. All threads run in the same address space of the server application, but each thread has it's own individual program-counter, run-time stack, signal mask and errno variable. ... Additionally Pth provides an optional emulation API for POSIX.1c threads ("Pthreads") which can be used for backward compatibility to existing multithreaded applications.
Les GNU pth sont des threads coopératifs (par opposition à préemptifs) : les tâches commutent quand elles arrivent à des points de commutation, explicites ou implicites (dans les fonctions d'entrées-sorties bloquantes).
Oui, et alors? Je ne suis pas du tout certain que la norme des pthreads demande qu'ils soient préemptifs. J'ai un vague souvenir d'avoir lu que la norme a été rédigée de façon telle qu'on puisse la satisfaire aussi bien avec une vraie inmplémentation basées sur le scheduler de l'OS qu'avec des "green threads". (Voir Butenhof page 190.) Evidemment avec une implémentation userland on ne profite pas des multiprocesseurs, donc la performance est réduite, mais ça peut ne pas avoir d'importance selon les cas de figure.
--
Michel TALON
Nicolas George <nicolas$george@salle-s.org> wrote:
Michel Talon, dans le message <h497so$lf5$1@asmodee.lpthe.jussieu.fr>, a
écrit :
> Je suis loin de bien connaître ce sujet, mais il me semble qu'il existe
> des implémentations de la norme posix des threads, purement en userland,
> par exemple les gnu pth.
Le P de GNU pth ne veut pas dire POSIX, il veut dire portable, et ce ne sont
pas des threads POSIX, mais alors vraiment pas du tout.
Comme je disais, je ne suis pas du tout spécialiste. Cependant sur la
première page de Gnu pth je lis:
Pth is a very portable POSIX/ANSI-C based library for Unix platforms
which provides non-preemptive priority-based scheduling for multiple
threads of execution (aka ``multithreading'') inside event-driven
applications. All threads run in the same address space of the server
application, but each thread has it's own individual program-counter,
run-time stack, signal mask and errno variable.
...
Additionally Pth provides an optional emulation API for POSIX.1c threads
("Pthreads") which can be used for backward compatibility to existing
multithreaded applications.
Les GNU pth sont des threads coopératifs (par opposition à préemptifs) : les
tâches commutent quand elles arrivent à des points de commutation,
explicites ou implicites (dans les fonctions d'entrées-sorties bloquantes).
Oui, et alors? Je ne suis pas du tout certain que la norme des pthreads
demande qu'ils soient préemptifs.
J'ai un vague souvenir d'avoir lu que la norme a été rédigée de façon
telle qu'on puisse la satisfaire aussi bien avec une vraie
inmplémentation basées sur le scheduler de l'OS qu'avec des "green
threads". (Voir Butenhof page 190.)
Evidemment avec une implémentation userland on ne profite pas des
multiprocesseurs, donc la performance est réduite, mais ça peut ne pas
avoir d'importance selon les cas de figure.
Michel Talon, dans le message <h497so$lf5$, a écrit : > Je suis loin de bien connaître ce sujet, mais il me semble qu'il existe > des implémentations de la norme posix des threads, purement en userland, > par exemple les gnu pth.
Le P de GNU pth ne veut pas dire POSIX, il veut dire portable, et ce ne sont pas des threads POSIX, mais alors vraiment pas du tout.
Comme je disais, je ne suis pas du tout spécialiste. Cependant sur la première page de Gnu pth je lis:
Pth is a very portable POSIX/ANSI-C based library for Unix platforms which provides non-preemptive priority-based scheduling for multiple threads of execution (aka ``multithreading'') inside event-driven applications. All threads run in the same address space of the server application, but each thread has it's own individual program-counter, run-time stack, signal mask and errno variable. ... Additionally Pth provides an optional emulation API for POSIX.1c threads ("Pthreads") which can be used for backward compatibility to existing multithreaded applications.
Les GNU pth sont des threads coopératifs (par opposition à préemptifs) : les tâches commutent quand elles arrivent à des points de commutation, explicites ou implicites (dans les fonctions d'entrées-sorties bloquantes).
Oui, et alors? Je ne suis pas du tout certain que la norme des pthreads demande qu'ils soient préemptifs. J'ai un vague souvenir d'avoir lu que la norme a été rédigée de façon telle qu'on puisse la satisfaire aussi bien avec une vraie inmplémentation basées sur le scheduler de l'OS qu'avec des "green threads". (Voir Butenhof page 190.) Evidemment avec une implémentation userland on ne profite pas des multiprocesseurs, donc la performance est réduite, mais ça peut ne pas avoir d'importance selon les cas de figure.
