std::string

Matthieu Moy wrote:

"Stan" <z.y.l.o.g@wanadoo.fr ( remove the dots )> writes:

Avant ça ne pouvait pas être le cas, Linux ne supportant pas
les threads !

J'ai fait un programme multithreadé sous Linux avant la sortie
du 2.6. J'ai du rêver alors.

Aujourd'hui, la 2.6 gére les threads et comme le fait
remarquer James, un process est en fait un (super) thread.

Ben justement, en 2.4, chaque thread a un PID différent. La
création d'un thread est grosso-modo un fork() + partage de la
mémoire et autres ressources. En 2.6 avec la NPTL, le kernel
fait une nette différence entre un thread et un processus.

C'est donc un pas en arrière. C'est marrant, parce que Solaris
évolve dans l'autre sens.

En fait, pour differents raisons, il faut bien qu'il y ait un
identificateur de processus, en plus d'un identificateur pour
chaque thread. Pour m'exprimer mieux, je dirais qu'il n'y a pas
de différences fondamentales entre les threads d'aujourd'hui, et
les processus d'autres fois. On continue à avoir les processus
aussi, au moins en nom, mais un processus d'aujourd'hui, c'est
une collection de threads. Dans un OS bien conçu, au moins. Et
si l'OS est réelement bien conçu, avec des couches internes, les
couches les plus basses ne connaîtrait pas les processus,
seulement les threads. Les processus d'aujourd'hui n'existent
que pour la commodité de l'utilisateur (qui ne veut pas avoir à
spécifier systèmatiquement tout ce qu'il veut partager), et
n'est pas fondamental pour des parties basses de l'OS (comme le
schéduleur).

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Arnaud Meurgues wrote:

kanze@gabi-soft.fr wrote:

différents processus. Une des applications sur laquelle je
travaille ici utilise bien de la mémoire partagée (au moyen
de mmap), et synchronise ses « processus » au moyen des
mutex situé dans cette mémoire. Du coup, je me sers des
moyens de communication traditionnellement associés à des
threads pour la communication entre processus.

Sauf qu'ils sont gérés dans de la mémoire partagée, qui, elle,
dispose d'une gestion spécifique adaptée à de la communication
entre processus.

C-à-d ? Dans notre application ici, j'ai bien des rwlock dans la
mémoire partagée (au moyen de mmap) -- c'est exactement la même
chose que si j'avais deux threads, plutôt que deux processus. Et
je n'ai pas d'autre gestion : j'utilise mmap pour dire à l'OS
que je veux cette mémoire-là à cette adresse, et du moment que
je m'arrange pour que deux processus ait la même mémoire aux
mêmes adresses...

La seule distinction, c'est que dans le cas des threads, la
mémoire est partagée par défaut (mais je peux obtenir de la
mémoire locale au thread), tandis que dans le cas des processus,
la mémoire est locale au processus par défaut (mais je point
obtenir de la mémoire partagée).

Dans un système plus évolué que Unix, je pourrais avoir une
gestion encore plus fine (si je la voulais), avec de la mémoire
partagée par exactement les threads que je veux, indépendamment
du processus auquel ils appartiennent. (Mais il y a des raisons
historiques. Le PDP-11 n'avait que trois ségments, et pas de
pagination. Du coup, c'était difficile à faire mieux. Et il y a
bien peu d'applications qui ont besoin d'une gestion plus fine.)

C'est simplement par une bonne séparation des couches (la
mutex d'une part et la mémoire partagée d'autre part) que l'on
a le sentiment de gérer la communication entre threads de la
même manière que la communication entre processus.

Encore, je ne comprends pas trop ce que tu essaies de dire. Dans
Linux, et aussi dans les dernières versions de Solaris (et les
versions plus anciennes, avec des bonnes options), les threads,
et non les processus, sont schédulés par le OS. Les mutex, les
rwlock, etc., gèrent les threads, irrespectivement de si les
threads sont dans le même processus ou non. La seule chose
nécessaire, c'est que le mutex ou le rwlock soit visible de tous
les threads qui veut l'utiliser.

En somme, la distiction thread-processus est plus
conventionnelle que fondamentale.

Je dirais que dans ton cas, elle reste fondamentale, mais que
la mémoire partagée te donne un moyen de t'abstraire de cette
distinction. En tout cas, c'est plutôt comme ça que je le
vois.

Mais il y a une chose qui, je crois, ressort de ce que tu dis
(notamment ton expérience avec certains systèmes temps-réel),
c'est que les notions de thread et de processus sont
éminemment conventionnelles.

Oui et non. Les noms qu'on donne à quelque chose sont toujours
conventionnels. Autrefois, quand on parlait de processus, on
parlait d'un fil d'exécution. Typiquement (mais pas dans les
systèmes embarqués les plus primitifs), on y associait aussi la
notion de propriété de certaines ressources. Mais très tôt, il a
aussi été possible de partager ces ressources entre plusieurs
processus, la ressource n'étant définitivement libérée que
lorsque le dernier processus « propriétaire » le libérait.
(C'était, au moins, courant dans les OS que j'utilisais dans les
années 1970.) Ce qui correspond de très près à ce qu'on entend
par thread aujourd'hui. Le processus d'aujourd'hui est en fait
une collection de threads ; il a un identificateur propre, qui
permet à l'utilisateur d'agir sur tous les threads d'un coup, et
il y a partage par défaut (voire obligatoire pour certaines
ressources) de beaucoup de ressources. Mais c'est une conception
de haut niveau : au plus bas, quand on crée un thread, on doit
pouvoir spécifier ce qui est partagé, et ce qui ne l'ai pas. En
fait, fork() et pthread_create() font exactement la même chose,
avec des paramètres légèrement différents, de façon à ce que
dans le premier cas, le système copie, et ne partage pas, et
dans le deuxième, le système partage, et ne copie pas. (C'est
une simplification, évidemment.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze@gabi-soft.fr writes:

| Matthieu Moy wrote:
| > "Stan" <z.y.l.o.g@wanadoo.fr ( remove the dots )> writes:
|
| > > Avant ça ne pouvait pas être le cas, Linux ne supportant pas
| > > les threads !
|
| > J'ai fait un programme multithreadé sous Linux avant la sortie
| > du 2.6. J'ai du rêver alors.
|
| > > Aujourd'hui, la 2.6 gére les threads et comme le fait
| > > remarquer James, un process est en fait un (super) thread.
|
| > Ben justement, en 2.4, chaque thread a un PID différent. La
| > création d'un thread est grosso-modo un fork() + partage de la
| > mémoire et autres ressources. En 2.6 avec la NPTL, le kernel
| > fait une nette différence entre un thread et un processus.
|
| C'est donc un pas en arrière. C'est marrant, parce que Solaris
| évolve dans l'autre sens.

cette assertion est logiquement aussi valable que :

# C'est donc un pas en avant. C'est marrant, parce que Solaris
# évolve dans l'autre sens.

| En fait, pour differents raisons, il faut bien qu'il y ait un
| identificateur de processus, en plus d'un identificateur pour
| chaque thread. Pour m'exprimer mieux, je dirais qu'il n'y a pas
| de différences fondamentales entre les threads d'aujourd'hui, et
| les processus d'autres fois. On continue à avoir les processus
| aussi, au moins en nom, mais un processus d'aujourd'hui, c'est
| une collection de threads.

Oui mais quand je pance un processus, c'est le processus avec la
définition d'aujourd'hui que j'ai pas celui d'il y a 40 ans.

À bas la logique temporelle selective.

| Dans un OS bien conçu, au moins.

C'est un axiome ou un théorème ?

| si l'OS est réelement bien conçu, avec des couches internes, les
| couches les plus basses ne connaîtrait pas les processus,
| seulement les threads. Les processus d'aujourd'hui n'existent
| que pour la commodité de l'utilisateur (qui ne veut pas avoir à
| spécifier systèmatiquement tout ce qu'il veut partager), et
| n'est pas fondamental pour des parties basses de l'OS (comme le
| schéduleur).

Ton raisonnement devrait conclure qu'il n'y a pas de difference entre
Java et C++ ; encore moins entre C++ et un langage binaire. Gare à la
prochaine fois où tu feras une distinction entre C++ Java.

-- Gaby

kanze@gabi-soft.fr writes:

[...]

| Oui et non. Les noms qu'on donne à quelque chose sont toujours
| conventionnels.

mon dieu, que fait la police.

| Autrefois, quand on parlait de processus, on
| parlait d'un fil d'exécution.

On est pas autrefois ; aujourd'hui c'est le 15 Juillet 2005.

[...]

| fait, fork() et pthread_create() font exactement la même chose,
| avec des paramètres légèrement différents, de façon à ce que
| dans le premier cas, le système copie, et ne partage pas, et
| dans le deuxième, le système partage, et ne copie pas. (C'est

Ah oui, copier et ne pas copier c'est la même chose.
Et entre être et ne pas être, il y a une différence ?

-- Gaby

Michel Michaud wrote:

Dans le message 1121246203.855782.221360@o13g2000cwo.googlegroups.com,

Oui et non. Toutes les primitives de communication
« inter-processus » sont aussi disponibles pour la communication
entre threads.

Oui, mais on ne fait pas des threads pour ça, plutôt pour
faire ce qu'on ne peut pas faire avec des processus séparés...

Et qu'est-ce qu'on ne peut pas faire avec des processus séparés,
du moment qu'il partage de la mémoire ?

Mais tu parles des utilisations. Je ne nie pas qu'il y a deux
idiomes distincts. Mais ça ne change pas le fait que la
techologie en-dessous est la même. Ni, surtout, qu'il y a des
stratégies intermédiaires.

En fait, sous Linux (et sous la dernière version de Solaris,
et je crois aussi sous Windows), il n'y a pas de processus
au sens classique ; il n'y a que des threads.

Alors nous n'avons plus à discuter des différences, puisque
tout dépend de ce point de vue de départ... Si tu pars du
principe que c'est la même chose alors oui, ce sera la même
chose ! Pour moi, quand il y a des appels systèmes différents,
c'est différent.

Il y a différents niveaux d'appels systèmes. Sous Linux, par
exemple, il y a fork(), et pthread_create(). Mais tous les deux
appelle clone(), avec simplement différents paramètres.

En fait, je ne me suis pas trop bien exprimé. Ce qu'on appelle
aujourd'hui « thread », c'est exactement ce qu'on appelait, il
n'y a pas si longtemps, processus. Et ce qu'on appelle
aujourd'hui processus, c'est un ensemble de threads. Dans la
mesure où une collection d'X est autre chose qu'un X, les
processus sont différents des threads. Mais quand on programme,
on écrit du code qui s'exécute dans un de ces threads. Le
défaut, c'est que tous les threads dans un même processus
partagent tout, et qu'il ne partage rien avec les threads dans
un autre processus, mais on n'est pas toujours obligé à se
limiter aux défauts.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Gabriel Dos Reis wrote:

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis wrote:
| > Fabien LE LEZ <gramster@gramster.com> writes:

| > [...]

| > | Et d'après le même dictionnaire, le mot "truck" existe
| > | en français, mais a un autre sens ("wagon en plate-forme
| > | pour le transport des objets encombrants et pesants").

| > Ici, « truck » existe aussi en Americain (devrais-je dire
| > « Texan » ?) et il a tout un autre sens :-) :-)

| Le mot « truck » est un bon mot américain (non seulement
| texan), avec deux significations fréquentes : camion, et
| bogie. En

Au Texas, cela a une autre signification.

En plus de, et non à la place de celles que j'ai données, sans
doute.

Ça ne m'étonne pas trop. D'où vient ma mère (près d'Atlanta), on
entend quelque chose du genre « I ain't got no truck with » pour
dire, « je ne supporte pas ». Je ne l'ai pas cité, parce que je
crois que c'est vraiment local. Qu'il y a d'autres
significations locales à d'autres endroits (ou dans d'autres
communités) ne m'étonnerait pas ; Un ami anglais me dit que
« pushing the truck » existe dans le « Cockney rhyming slang ».

Je n'ai jamais habité Texas. Je sais que le dialect local fait
partie des dialects du sud-est, mais c'est tout. C'est juste
pour dire que le mot « truck » existe bien en américain standard
aussi, avec des significations qu'il n'a pas en anglais
d'Angleterre (c-à-d l'anglais qu'apprend la plupart des
français).

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis wrote:
| > kanze@gabi-soft.fr writes:
|
| > | Gabriel Dos Reis wrote:
| > | > Fabien LE LEZ <gramster@gramster.com> writes:
|
| > | > [...]
|
| > | > | Et d'après le même dictionnaire, le mot "truck" existe
| > | > | en français, mais a un autre sens ("wagon en plate-forme
| > | > | pour le transport des objets encombrants et pesants").
|
| > | > Ici, « truck » existe aussi en Americain (devrais-je dire
| > | > « Texan » ?) et il a tout un autre sens :-) :-)

[...]

| C'est juste
| pour dire que le mot « truck » existe bien en américain standard
| aussi, avec des significations qu'il n'a pas en anglais
| d'Angleterre (c-à-d l'anglais qu'apprend la plupart des
| français).

Je crois que Gaby ne disait pas le contraired dès le début.

-- Gaby