Les parties Linux et (étonnement) Windows NT sont assez documentées...
Aller plus loin
- Le rapport (16 clics)
Quel OS pour le multiprocesseur ?
21
jan.
2002
Quel OS pour le multiprocesseur ? C'est la question posée à un futur ingénieur CNAM. La conclusion : "Dans l'état actuel des choses, nous pouvons signaler que les systèmes à base d UNIX sont en avance (contrairement aux systèmes Microsoft qui n'ont pas encore complètement résolu le problème du multitache) et qu'ils semblent, du moins dans un futur proche, pérennes (contrairement à BeOS), même si un « challenger », JavaOS, semble intéresser de plus en plus les spécialistes".
Les parties Linux et (étonnement) Windows NT sont assez documentées...
Les parties Linux et (étonnement) Windows NT sont assez documentées...
# linuuuuuuuuuuuuux
Posté par - neuro (site web personnel) . Évalué à 10.
En fait, je n'ai jamais vu ca sur aucune architecture.
Le plus probant, a mon avis, pour le demontrer est de faire de la compilation avec l'option -jx ou x est le nombre de processeurs. C'est fabuleux :)
[^] # linuuuuuuuuuuuuux
Posté par kalahann . Évalué à 10.
ça marche vraiment très bien. A part 1 ou 2 options à ne pas oublier à la compil du noyau (apm, enhanced rtc, apic), y'a rien à faire ça marche tout seul.
Avec le smp, on ne bénéficie pas d'une puissance incroyable (à moins de mettre 2 processeurs haut de gamme) et un bi-cpu n'est pas 2x plus puissant qu'un mono-cpu à même vitesse. Il peut même être plus lent si on utilise une appli très gourmande non-parallélisable. Exemple: quake 3 est parfois plus rapide (ça dépend des tests) en up qu'en mp.Par contre, le temps de réponse est excellent. La machine répond toujours tout de suite, même en étant très chargée.
Les cartes mères smp ne coûtent pas excessivement cher (j'ai acheté une asus p2b-d il y a 3 ans, qui est excellente, pour 2000F)
Quand on voit la différence de prix entre 2 processeurs milieu de gamme et un processeur très haut de gamme, il est parfois un peu moins cher d'acheter un système bi-cpu (c'est le calcul que j'avais fait à l'époque)
Perso, je suis convaincu. Essayez et vous le saurez aussi :)
[^] # Re: linuuuuuuuuuuuuux
Posté par ToasteR (site web personnel) . Évalué à 7.
J'ai plongé dans le bipro depuis fin 98 avec une ASUS P2B-DS.
Si le support APM est déconseillé avec SMP, ça ne veut pas dire qu'il est completement inexploitable ;
Lorsqu'on inclut le support APM avec un noyau SMP, on a un message au démarrage de la machine qui nous dit : "APM disabled ... not SMP safe".
Comme ça m'énervait ;
- d'appuyer sur le bouton power pour eteindre la machine
- d'appuyer sur le bouton power de mon écran pour éviter qu'il fonctionne à plein régime 24/24 quand je ne suis pas devant
- que d'autres OS comme "fenêtre" ou "soleil" étaient capables de le faire
je me suis renseigné et il faut donc savoir ceci ;
1 - inclure le support APM avec SMP n'a jamais fait planter ma machine
2 - pour pouvoir faire un soft power-off lors d'un shutdown, il suffit de faire un append="apm=power-off" dans lilo.conf. Au reboot, le noyau informe alors que APM est désactivé mais que power-off est actif
3 - pour utiliser APM sous X avec ça, il faut ajouter 'option "DPMS"' dans la section monitor du fichier XF86Config-4. Avec la v3 il me semble que c'était option "power_saver".
J'espère que ça servira à ceux qui sont énervés par les mêmes choses que moi :))
[^] # Re: linuuuuuuuuuuuuux
Posté par Vanhu . Évalué à 10.
en fait, une compilation lourde (un noyau, par ex) fait pas mal d'entrées/sorties, et le processeur passe donc une partie de som temps à attendre des données.
En faisant make -j x ou x ~= 2x nombre de processeurs, tu as un gain généralement significatif, surtout si tu es en SCSI ou en DMA (qui consomment peu de CPU). Cela est valable aussi avec un seul processeur.
En faisant x ~= 3x nombre de procs, la différence avec 2x etait peu significative sur mes tests, et on commencait a avoir une chute de perfs assez nette a 4x. Mais bon, c'était des tests empiriques...
En fait, je trouve que le plus simple pour tester l'efficacité du multipro est de faire tourner une appli bien lourde en usage CPU (mais pas trop en disque et RAM), et de constater que le système réagit encore très bien a coté....
[^] # Re: linuuuuuuuuuuuuux
Posté par kalahann . Évalué à 10.
Sinon, sur une bi-PII 550 avec 256 Mo de ram: ms-office dans vmware + staroffice + plusieurs fenêtres de mozilla ouvertes + d'autres trucs, et ça rame pas, le système répond toujours aussi vite!
[^] # Re: linuuuuuuuuuuuuux
Posté par maggic . Évalué à 10.
J'avais fait l'expérience avec xmms-1.0.0 il me semble.
Le temps de compilation était minimum avec make -j 12 (machine avec 512Mo de RAM, SCSI)
[^] # Re: linuuuuuuuuuuuuux
Posté par pfrenard . Évalué à 10.
-pipe
Use pipes rather than temporary files for communication between the various stages of compilation. This fails to work on some systems where the assembler is unable to read from a pipe; but the GNU assembler has no trouble.
Au lieu d'utiliser des fichiers temporaires, on pipe les commandes d'ou economie d'IO :)
RuZed
[^] # Re: linuuuuuuuuuuuuux
Posté par Vanhu . Évalué à 9.
Noyau 2.2.x (6-7, si je me souviens bien) qui tourne, et dont on compile les sources avec a peu pres les memes options:
Sur un K6-2 450 - UW SCSI, au dela de make -j 3, je gagne plus, et a partir de -j 6 ou 7, ca recommence a chuter. Soit 2-3x Nb proc
Sur un bi céléron 500 - DMA33, au dela de -j 5, ca commence a chuter. Je suppose que cela est lié au FSB (66Mhz seulement) et a l'IDE (quoique DMA quand meme....). Soit aussi 2-3x Nb Proc
Su un Quadri-Xeon 500 - U2W-SCSI (ne bavez pas, c'était une machine de la fac...), j'avais les meilleurs temps vers -j 16 - 20, si je me souviens bien..... soit 4-5x le nombre de processeurs.
Mais bon, la compilation d'un noyau Linux n'est pas forcément le bench optimal, et de gros progrès ont encore été effectués entre les 2.2 et les 2.4 ...
[^] # Re: linuuuuuuuuuuuuux
Posté par VACHOR (site web personnel) . Évalué à 10.
Rien qu'en clickant avec une souris, cela se sent.
Quand on a 5-6 applis lancée sous win, tout se met à ramer quasi systématiquement. Ce n'est pas le cas avec Linux, qui conserve une disponibilité étonnante...
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à -3.
Notes que sous Windows on n'a pas encore de patchs pour pouvoir interrompre les threads quand elles sont dans le kernel, c'est d'origine :+)
Ah aussi, les affinites de threads avec les processeurs aussi, les I/O completion ports, les threads du meme process qui ont la bonne idee d'avoir toutes le meme process ID contrairement a certaines implementations que je ne citerais pas, les threads signalables sur des timers, sur des threads,...
Non, faut rester serieux quand meme.
[^] # Re: linuuuuuuuuuuuuux
Posté par Jar Jar Binks (site web personnel) . Évalué à 9.
Les plantages quand une appli acquiert une priorité supérieure au kernel, c'est d'origine aussi ?
les threads du meme process qui ont la bonne idee d'avoir toutes le meme process ID
Attends, tu ne vas pas nous expliquer que Windows implémente mieux les normes POSIX, quand même ?
les threads signalables sur des timers
Rhôôôôôô, on ne peut pas faire de timers sous *nix ? On m'aurait menti ?
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à 3.
- uniquement pour les priorites REALTIME
- pour des raisons precisees dans la doc(les threads de managment n'ont plus le temps de tourner si un thread de plus haute priorite monopolise le CPU trop longtemps)
- infaisable par quiconque d'autre que l'administrateur
Tout comme ecrire dans /dev/kmem peut faire torcher ta machine.
En gros c'est une facilite donnee aux gens, en leur disant bien que c'est dangereux et comment faire pour ne pas torcher le systeme, et son utilisation est interdite a quiconque d'autre que l'admin pour eviter les abus, maintenant si tu trouves que ce genre de choses est un bug, ben faudra penser a corriger pas mal de choses se trouvant dans /dev et dans /proc.
Windows n'implemente pas mieux les normes POSIX vu que ce n'est pas un systeme qui se veut POSIX, mais il fait les choses correctement et proprement lui, ce qui n'est pas vraiment le cas du multithread sous Linux.
Sinon, tu me montres comment sous Linux tu fais la chose suivante:
4 threads qui tournent.
1 thread se reveille toutes les 30 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 40 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 30 secondes, les 40 secondes et les 2 minutes 15.
1 thread se reveille toutes les 30 secondes et les 40 secondes.
J'ai beau avoir gratte la doc sur http://www.unix-systems.org/single_unix_specification_v2/xsh/thread(...)) et dans mon superbe bouquin de Richard Stevens j'ai rien vu d'evident pour faire ca, peut-etre en jouant avec des conditions et encore j'en suis pas sur du tout.
Et inutile de decrire la peine que j'ai eu a trouver cette doc, sur la page de Linuxthreads il est dit que c'est maintenant partie de la libc, et dans la doc de la libc pas un seul mot sur les threads.
Voila, tu peux aller t'amuser a modifier le handler de SIGALRM et faire un code degueu pour ca vu que les signaux sont partages par tous les threads, ou bien creer un thread qui passe son temps a recevoir les signaux et les dispatcher aux autres threads, pendant ce temps moi je cree sous Windows 3 objets timer , je leur assigne les temps, je fais WaitForMultipleObjects() dans chaque thread et c'est fini, c'est moins couteux en ressources car chaque thread n'est reveille que quand c'est necessaire et c'est plus propre a programmer. Mais bon ca c'est pas vraiment la faute a Linux, quasiment tous les Unix sont comme ca.
Si tu veux on peut aussi parler du probleme suivant:
T'as un soft qui cree un thread a chaque connection, le thread fait 2-3 choses et cree un process(avec fork) avec des droits reduits histoire de faire d'autres choses qui peuvent durer longtemps, apres le fork() le thread n'a plus d'utilite donc il est detruit, par contre tu veux savoir quand le process enfant est termine pour nettoyer 2-3 trucs.
Ben avec Linux tu peux t'amuser, le PID parent du process enfant c'est le PID du thread qui a ete detruit, resultat il est impossible de le faire savoir au process grace au signal SIGCHLD et il faut faire des magouilles degueulasses genre stocker les PID des child process et faire du polling pour savoir si ils existent encore.
Et c'est pas un exemple theorique, c'est un soft de load balancing que j'avais ecrit sous Solaris et que j'ai du modifier de maniere assez lourde pour qu'il veuille bien tourner sous Linux, et inutile de dire que c'est bien moins performant comme methode, mais bon il n'y a pas le choix vu le bug.
[^] # Re: linuuuuuuuuuuuuux
Posté par VACHOR (site web personnel) . Évalué à 4.
Le coup des 4 threads qui tournent, ça troue le c.. Cela montre à quel point les gens de M$ sont décérébrés : dès qu'ils ont pas l'API qui permet de faire en 2 instructions max ce qu'ils veulent faire, ils disent que c'est impossible ;-)
De toute façon, il s'accable lui-même :
"ces plantages sont :
- uniquement pour les priorites REALTIME
- pour des raisons precisees dans la doc(les threads de managment n'ont plus le temps de tourner si un thread de plus haute priorite monopolise le CPU trop longtemps)
- infaisable par quiconque d'autre que l'administrateur"
-> Sans commentaires...
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à 0.
Quand a m'accabler... ben prouve moi que c'est plus dangereux que /dev/kmem et on en reparlera.
[^] # Re: linuuuuuuuuuuuuux
Posté par Toufou (site web personnel) . Évalué à 2.
[^] # Re: linuuuuuuuuuuuuux
Posté par Gaël Le Mignot . Évalué à -2.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à -4.
Mais a part ca, je vois pas trop ce que ca a voir avec le sujet, on parlait de multithreading/multitache et multiprocessing.
[^] # Re: linuuuuuuuuuuuuux
Posté par Jar Jar Binks (site web personnel) . Évalué à 4.
- une erreur dans la compilation du noyau,
- un bug du noyau,
- un problème matériel.
Donc si tu as vu un kernel panic, tu as effectivement vu un bug de l'OS. Maintenant, avec un noyau stable, je n'en ai jamais vu (même les pires plantages SCSI sur la partition de root n'étaient pas complètement bloquants).
[^] # Re: linuuuuuuuuuuuuux
Posté par Alberto . Évalué à 7.
Dans ce cas, il s'agit d'un kernel panic du a un bug d'une appli qui demande les droits roots pour s'executer ou un polio qui tourne sous le compte root.
Mais la seule fois ou j'ai vu un kernel panic s'etait en retirant la partition mote sur / a chaud (coup de pied dans la tour avec rack mal branche). Les ecrans bleus/plantage windows je ne les compte plus. Sans compter les fois ou il faut rebooter lorsqu'on a installe un soft sous windows.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à 0.
Un des drivers fait le con, et degueulasse des structures du kernel mais pas trop, ca crashe pas immediatement.
Le kernel fait son petit bout de chemin, et apres un petit moment se met a traiter ces donnees corrompues, il voit que c'est le merdier --> kernel panic.
[^] # Re: linuuuuuuuuuuuuux
Posté par Gaël Le Mignot . Évalué à 5.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: linuuuuuuuuuuuuux
Posté par Alberto . Évalué à 2.
[^] # Re: linuuuuuuuuuuuuux
Posté par Jar Jar Binks (site web personnel) . Évalué à -1.
Mettre dans le noyau des trucs instables, je range ça dans la première catégorie. Un noyau stable, ce n'est pas un noyau avec des drivers immondes.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à -3.
T'en sais rien, peut-etre que ces drivers qui sont dans le kernels depuis des annees ont des bugs qui font des kernel panics, mais personne n'a encore eu la malchance de tomber dessus.
Tu n'es jamais sur a 100% qu'un soft est bug free, ca vaut aussi pour les drivers.
[^] # Re: linuuuuuuuuuuuuux
Posté par #3588 . Évalué à 0.
Sur les noyaux stables, les seuls kernel panic qu'on a l'occasion de voir c'est quand on s'est planté à la compilation et que le boot déconne. Dans ce cas ce n'est pas un bug. Les autres cas de kernel panic, c'est provoqué quand on le cherche vraiment et qu'on veut tenter l'expérience pour s'amuser. En pratique, une fois que le système a booté, on est tranquille. Rien à voir effectivement avec des plantages multiples et en cours d'utilisation.
[^] # Re: linuuuuuuuuuuuuux
Posté par Jar Jar Binks (site web personnel) . Évalué à 4.
Je ne suis pas d'accord avec ce genre de politiques (de même que je ne suis pas d'accord avec Linus quand il refuse d'intégrer un patch qui interdirait de niquer physiquement le disque dur sous prétexte que root peut niquer ses disques durs s'il en a envie). Mais il y a quand même une grosse différence entre un /dev/kmem et une fonction d'API à laquelle il suffit d'attribuer une valeur pour planter le système. Peut-être que tu as un gros « NE PAS UTILISER » dans ta doc, mais les développeurs de Winamp n'ont pas du lire la même doc. C'est vrai que c'est plutôt le problème des développeurs de logiciels, mais il ne faut pas non plus les encourager...
Windows n'implemente pas mieux les normes POSIX vu que ce n'est pas un systeme qui se veut POSIX, mais il fait les choses correctement et proprement lui, ce qui n'est pas vraiment le cas du multithread sous Linux.
Sauf que l'exemple que tu prends (les PIDs des threads) a pour unique conséquence sous linux que les normes POSIX ne sont pas respectées.
Et inutile de decrire la peine que j'ai eu a trouver cette doc, sur la page de Linuxthreads il est dit que c'est maintenant partie de la libc, et dans la doc de la libc pas un seul mot sur les threads.
Chapitre 34 de la doc de la glibc, POSIX Threads. Je n'ai pas eu à chercher longtemps. Il y est écrit noir sur blanc qu'il ne faut pas mélanger threads et signaux. Ça tombe bien, les threads ça permet de se passer complètement des signaux.
Sinon, tu me montres comment sous Linux tu fais la chose suivante:
Un thread qui fait le timing et qui réveille les autres ?
Mais bon ca c'est pas vraiment la faute a Linux, quasiment tous les Unix sont comme ca.
Ce n'est pas tout à fait exact. J'ai essayé sous Solaris, on peut mélanger threads et signaux, et ça marche à peu près. C'est quand même tout aussi déconseillé.
T'as un soft qui cree un thread a chaque connection, le thread fait 2-3 choses et cree un process(avec fork) avec des droits reduits histoire de faire d'autres choses qui peuvent durer longtemps, apres le fork() le thread n'a plus d'utilite donc il est detruit, par contre tu veux savoir quand le process enfant est termine pour nettoyer 2-3 trucs.
Hé bin tu laisses le thread sur un waitpid(); c'est si compliqué que ça ? De toute façon, ça ne prend quasiment rien, comme ressources, vu qu'il y a déjà d'autres threads.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à -3.
- Certaines choses sont rendues bien plus compliquees par rapport a d'autres systemes
- Ca oblige a refaire l'architecture des softs a cause d'un systeme qui fait differemment de tous les autres Unix
En gros ca fait bien chier et quand on sait que PID veut dire PROCESS ID, on se demande comment les threads d'un meme process ont un PID different.
Quand a la doc de glibc, ben sur http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_toc.html(...) il n'y a rien du tout, tu l'a prise ou ou ta doc ?
Pour ce qui est du timing, c'est donc bien ce que je disais, il faut faire un truc assez moche(mettre le code pour l'attente hors du thread, pas un bon design car tu delocalise le code) qui prend plus de ressources(1 thread en plus qui gere la chose) et il faut gerer quand tu ajoutes des threads, enleve,... histoire que le thread de gestion se melange pas les pinceaux et oublie pas de threads.
Sinon pour mon probleme a moi, ben OUI laisser sur un waitpid() c'est un TRES GROS probleme.
Apres 500 connections tu te retrouves avec 500 threads attendant sur un waitpid(), dans le genre performance killer c'est dans le top 10, le scheduler il claque avec ca(sans compter les 2Mo de stack bouffes par chaque thread). Quand tu fais du load balancing t'essayes d'habitude d'avoir les meilleures perfs possibles, le waitpid() c'est hors de question.
[^] # Re: linuuuuuuuuuuuuux
Posté par Jar Jar Binks (site web personnel) . Évalué à 3.
Un peu plus compliquées parfois, j'en conviens. N'en rajoute pas non plus, on pourrait en trouver des trucs mal foutus dans les API de Windows.
- Ca oblige a refaire l'architecture des softs a cause d'un systeme qui fait differemment de tous les autres Unix
Non, car les routines bas niveau ne devraient jamais être utilisées directement par le programmeur. LinuxThreads a été fait quelque peu cradement au départ, mais il a été fait pour que les applications threadées existantes recompilent sans problème.
En gros ca fait bien chier et quand on sait que PID veut dire PROCESS ID, on se demande comment les threads d'un meme process ont un PID different.
Quel est le véritable problème à part la façon dont ça apparaît dans top ?
Quand a la doc de glibc, ben sur www.gnu.org/manual/glibc-2.2.3/html_node il n'y a rien du tout, tu l'a prise ou ou ta doc ?
Dans /usr/share/doc/glibc-doc/html/, j'ai une excellente doc.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à -1.
Mon soft n'avait rien de bas niveau, c'etait 100% user-mode. Et j'ai ete oblige de le refaire justement a cause de ce probleme de PID qui fait que ce n'est pas le process lui meme qui recoit le SIGCHLD et le refile a un thread, mais le thread createur, qui pourrait tout a fait avoir disparu. Et ca c'est : 1) contraire a la norme 2) TRES embetant, la preuve en est que j'ai du completement modifie mon soft a cause de ca, et je suis surement pas le seul dans ce cas, sans compter que le resultat est moins performant que le soft original.
[^] # Re: linuuuuuuuuuuuuux
Posté par Toufou (site web personnel) . Évalué à 0.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: linuuuuuuuuuuuuux
Posté par Aza . Évalué à 2.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à -1.
[^] # Re: linuuuuuuuuuuuuux
Posté par Toufou (site web personnel) . Évalué à 1.
[^] # Re: linuuuuuuuuuuuuux
Posté par Toufou (site web personnel) . Évalué à 1.
[^] # Re: linuuuuuuuuuuuuux
Posté par Gaël Le Mignot . Évalué à 4.
Tu rajoutes quelques stuctures de données, une fonction addtimer(timer_t *timer, unsigned int seconds); et une fonction waittimer(timer_t *timer); et la fonction waittimer() calcule le moment où le prochain timer va se déclencher, et fait un sleep() de ce qu'il faut. C'est pas si compliqué que ça; ça doit prendre 10 minutes à coder, et tu peux le mettre dans une lib pour faire encore plus propre.
D'ailleurs ça existe déjà dans la boucle d'évènements de la GLib (cf http://developer.gnome.org/doc/API/glib/glib-the-main-event-loop.ht(...))
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à 1.
Comment tu fais pour synchroniser 2 processus separes avec ca ?
Tu as 2 processus:
1 fait un boulot xyz, et pose un timer pour se reveiller dans 20 secondes chaque fois avant de prendre un autre job.
l'autre processus a besoin de se reveiller en meme temps que le processus 1 car il a des trucs a faire avec le boulot du process 1.
Pas possible avec ta methode, il n'y a aucun moyen de signaler au 2eme processus qu'il faut se reveiller, tout simplement car ton timer est local a un thread. Pour faire un truc du genre il faut un truc qui soit accessible globalement sur le systeme comme les mutex et semaphores. Ca serait en theorie possible en rajoutant du bordel pour balancer des signaux a l'autre process, mais la ton soft devient dependant du 2eme process, il doit le connaitre. Avec un timer global, le 1er process n'a meme pas besoin de savoir que le 2eme existe, le 2eme prend un handle sur le meme timer et fait son job.
[^] # Re: linuuuuuuuuuuuuux
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à 1.
Sinon, ce genre de choses est plus frequent que tu ne pourrais le penser.
[^] # Re: linuuuuuuuuuuuuux
Posté par Gaël Le Mignot . Évalué à 0.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à 1.
Si ton process 1 fait son boulot periodique et acquiert le mutex(le lock a la fin dans la fonction my_func) avant que le 2eme process ait ete schedule, le 2eme process ne pourra par faire son boulot car il sera encore bloque sur son g_mutex_lock(mutex).
D'autre part, il y a le probleme suivant(on regarde en boucle):
P1...................P2
lock(mutex)
attend
unlock(mutex)
bosse...............lock(mutex)
......................bosse
......................unlock(mutex)
lock(mutex)
lock(mutex)
attend
unlock(mutex)........--> P2 ne peut pas locker le mutex, car P1 a fait 2 locks de suite, il faut donc 2 unlock
bosse
lock(mutex)
[^] # Re: linuuuuuuuuuuuuux
Posté par Gaël Le Mignot . Évalué à -1.
Pour l'histoire de l'ordonencement, il suffit de rajouter un deuxième mutex:
P1:
g_mutex_unlock(mutex);
/* Le boulot périodique */
g_mutex_lock(mutex2);
g_mutex_lock(mutex);
g_mutex_unlock(mutex2);
P2:
g_mutex_lock(mutex2);
g_mutex_lock(mutex);
g_mutex_unlock(mutex2);
/* Ce qu'il doit faire */
g_mutex_unlock(mutex);
g_mutex_lock(mutex2);
Donc là on a:
P1 dévérouille mutex, effectue son traitement et attend que P2 ait libéré mutex2
P2 se bloque sur mutex, et dévourille mutex2 dés que possible, puis effectue son traitement
P1 peut reprendre la main (à un moment quelconque du traitement de P2) et vérouille mutex, qui est actuellement vérouillé par P2
P2 termine son traitement, et libère mutex, puis se bloque sur mutex2
P1 peut reprendre son exécution, et libère mutex2. On est de retour dans la situation de départ, près pour un autre cycle.
-1 car HS
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à 1.
Je lis:
" GMutex is not guaranteed to be recursive, i.e. a thread might block, if it already has locked the GMutex. It will deadlock then, of course."
Un thread ne peut pas locker 2 fois de suite le meme mutex. Donc ton P2 ne fonctionne pas, le 1er g_mutex_lock(mutex2) et le dernier se suivent des la 2eme boucle --> deadlock car P2 ne peut pas unlocker mutex2 vu qu'il est bloque sur le deuxieme g_mutex_lock(mutex2).
[^] # Re: linuuuuuuuuuuuuux
Posté par Olivier Jeannet . Évalué à 1.
1 thread se reveille toutes les 30 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 40 secondes AINSI que toutes les 2 minutes 15.
1 thread se reveille toutes les 30 secondes, les 40 secondes et les 2 minutes 15.
1 thread se reveille toutes les 30 secondes et les 40 secondes.
Tu es sûr que ça sert à qqchose ce truc-là ?! Je n'ai jamais eu besoin d'avoir des trucs aussi tordus.
Ton message apporte des infos intéressantes (comme souvent), notamment avec ton histoire de load balancing, mais là tu cherches la petite bête.
[^] # Re: linuuuuuuuuuuuuux
Posté par pasBill pasGates . Évalué à 1.
Des threads qui doivent se reveiller a des intervalles precis c'est hyper frequent, pouvoir specifier plus d'un intervalle par thread c'est utile aussi.
Ensuite avoir plusieurs threads qui font de meme avec des timers differents, c'est simplement plusieurs requetes qui ont ete faites, rien d'extraordinaire.
Tu peux tout a fait imaginer plusieures sources de donnees, certaines produisent de nouvelles donnees toutes les 30 secondes, d'autres toutes les 2 minutes 10, etc...
Un thread peut avoir besoin des donnees de la source 1 et la source 4, un autre des sources 2,3 et 5, etc... Voila, ca te donne le probleme ci-dessus.
[^] # Hors sujet ?
Posté par Antoniop . Évalué à 2.
[^] # Re: linuuuuuuuuuuuuux
Posté par Stephane Pion . Évalué à 1.
tu crée tes flots via la méthode adhoc et tu utilise un "sleep"ou un "nanosleep" avec un temps adapté.
Ca marche parfaitement. Mais j'ai sans doute du manquer quelque chose.
Maintenant, au niveau des signaux, je n'ai jamais fais de mutithreading poussé sous linux, mais il FAUT de toute façon un flot intercepteur qui agit en conséquence.
Stéphane
[^] # Re: linuuuuuuuuuuuuux
Posté par Vanhu . Évalué à 2.
Il veut peut etre simplement dire que Windows propose des possibilités qui ne sont pas disponibles par les threads POSIX.
Je n'ai jamais utilisé les threads windows, donc je peux pas dire, mais c'est clair que les threads POSIX ont des faiblesses et des lourdeurs dans certains cas.
[^] # Re: linuuuuuuuuuuuuux
Posté par Alberto . Évalué à 3.
Pour l'histoire des pid differents entre threads, je cite un bout de la man page de clone:
Thread groups are feature added in Linux 2.4 to support the POSIX threads notion of a set of threads sharing a single PID.
Donc apparement c'est regle en 2.4 et ca respecte pleinement Posix.
Voila, j'espere que j'ai pas dit trop de betises, ca fait longtemps que j'ai pas fait de systeme moi.
# traule ?
Posté par jerdent (site web personnel) . Évalué à -10.
[^] # Re: traule ?
Posté par jerdent (site web personnel) . Évalué à -8.
# Un regret...
Posté par Anonyme . Évalué à -4.
[^] # Re: Un regret...
Posté par Jak . Évalué à 10.
http://www.openbsd.org/faq/faq8.html#SMP(...(...)) :)
Sans troller, en quoi il est meilleur ? Une explication siouplè m'sieur.
[^] # Re: Un regret...
Posté par Vanhu . Évalué à 7.
Euh... tu parles de quel BSD, la ?
Open ?
Le projet de support a démarré il y a pas longtemps, cf le lien du post au dessus.
Free ?
Leur support est plutot moyen d'après les tests que j'ai vu/fait.
Net ?
Ah, la j'avoue, j'ai pas d'infos ....
[^] # Re: Un regret...
Posté par Anonyme . Évalué à -2.
Le projet de support a démarré il y a pas longtemps, cf le lien du post au dessus.
toutafé
Free ?
Leur support est plutot moyen d'après les tests que j'ai vu/fait.
Ben justement, c'est à plutôt à celui là que je pensais ; j'avoue que je sais pas trop pour linux 2.4, mais le support du SMP sur le 2.0 et le 2.2 n'est pas super et celui de FreeBSD a été fait en apprenant des erreurs commises dans linux et a été au moins un certain temps meilleur que celui de linux.
J'avoue aussi que j'ai légèrement exagéré pour lancer un ptit troll...
Net ?
Ah, la j'avoue, j'ai pas d'infos ....
moi non plus...
Cela dit, l'étude est loin d'être echaustive, et même sur les OS cités, seuls Windows NT (assez vieux) et Linux 2.pas beaucoup (assez vieux aussi) sont expliqués plus en détail.
Je regrette que rien ne soit plus dit sur les BSD et sur BeOS.
Quant à MacOSX, il néglige de préciser que c'est un micronoyau Mach à la base, et que c'est à lui qu'il incombe de supporter le SMP, pas au "serveur" BSD (comment ça je me répète ?). Et je doute que le fonctionnement en SMP de Mach (il me semble limité à 2 procs) soit le même que celui de linux...
# microtroll Word !
Posté par Philippe Martin . Évalué à 5.
[^] # Re: microtroll Word !
Posté par Jean . Évalué à -2.
Mais c'est dommage de ne pas avoir fait de liens entre le menu du rapport et les parties s'y raportant. Idem pour les références bibliographiques, y'a le nom mais on sait pas y accéder.
Si le rédacteur me lit...
Mes 0.02euros
[^] # Re: Fatal Error
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Les apostrophes sont codées à la microsoft. Il est pourtant pécisé au début du source : "charset=iso-8859-1" et c'est faux.
Le titre est aussi très bien : "<title>Document sans-titre</title>".
Quant au validator du W3C (respect de la norme) :
" Fatal Error: no document type declaration; will parse without validation"
" I could not parse this document, because it uses a public identifier that is not in my catalog"
C'est dommage, car le document valait mieux que ça.
Vous pouvez essayer http://validator.w3.org/check/referer(...(...)) ... et avant de critiquer trop fort, essayez le sur vos pages ;-)
# Il faut conserver cette avance !
Posté par eolyte . Évalué à 9.
Car en ce qui concerne les serveurs, notre Linux reste encore en avance, mais de par le fait que de plus en plus de développeurs concentrent leurs efforts sur le Desktop et négligent le coté serveur, M$ et ses commerciaux commencent à grignoter ce marché.
Je ne dis pas que développer des applications Desktop soit une mauvaise chose, mais je pense que développer moins d'applications Desktop similaires ET concurrentes pour continuer à améliorer la qualité de Linux en tant que serveur serait une chose bénéfique à notre OS favori.
Avant de vouloir dépasser M$ sur son terrain, je pense qu'il faut l'empêcher de progresser sur le notre !
[^] # Il faut conserver cette avance !
Posté par kalahann . Évalué à 10.
En plus la gestion du smp n'est qu'une petite partie des choix permettant de choisir un os plutôt qu'un autre (y'a aussi la fiabilité de l'ensemble, la rapidité, la sécurité, les services disponibles, le matos supporté...)
Il ne parle pas non plus du 2.4 (qui est sorti quand même depuis un moment... même s'il commence à peine à être vraiment envisageable pour un serveur), par contre il parle du 2.0 (qui chie carrément point de vue multi-processing)
Enfin, il me semble qu'on a déjà lancé linux sur des machines avec plus de 4 processeurs! par exemple, sur des wildfire (stations alpha à 32 voies)
Quelques bons points dans son article (dont celui de nous carresser dans le sens du poil) par contre, pas mal de défauts, et il n'est certainement pas exaustif!
[^] # Re: Il faut conserver cette avance !
Posté par Olivier . Évalué à 2.
un moment... même s'il commence à peine à être vraiment envisageable
pour un serveur), par contre il parle du 2.0 (qui chie carrément
point de vue multi-processing)..."
Et bin vaut mieux qu'il n'en parle pas. J'ai 3 machines bi-proc (bi-PII, bi-Celeron, biPIII) et j'ai été franchement décu par les perfs avec le 2.4. Les premiers 2.4 étaient vraiment pourri.
Il y a même des cas où on avait l'impression de tourner sur une patte.
Pour le 2.0, ca marchait pas mal pour un truc experimental. Contrairement au 2.4 qui ne l'est plus...
# javaos
Posté par kesako . Évalué à 7.
ah bon ? pour des multipros ?
jamais entendu parler pour ce type de machine.
Quelqu'un a des infos ?
[^] # Re: javaos
Posté par Franck Yvonnet . Évalué à 2.
[^] # Re: javaos
Posté par Romain Langlois . Évalué à 1.
pour ceux qui veulent en savoir plus sur JavaOS ...
Je vous invite aussi à vous documenter sur SavaJe XE , Système d'exploitation Java sorti en Decembre dernier.
# Le rapport...
Posté par VACHOR (site web personnel) . Évalué à 10.
Exemple : JavaOS n'est plus d'actualité depuis longtemps (et c'est probablement regrettable)... a moins que l'intérêt récent des fabriquants de mobiles pour les JVM embarqués ne relance le sujet.
C'est cependant une intéressante compilation.
# bi proc
Posté par johann berchet . Évalué à -4.
les performances etaient miniblables,c'etait tjs le meme proc qui morflait
Avec 2000 c'est meiux y'en a tjs qun qui morfle mais c'est jamais le meme
Avec linux, c'est le paradis je compile plein de truc en parallele.......................Xfree tabasse.........
# (contrairement à BeOS)
Posté par Francois Revol (site web personnel) . Évalué à 3.
Non, sérieux, c'est Be Inc. qui est mort, BeOS lui, il a jamais été aussi vivant, même il va renaitre de ses cendres... J'en profite pour passer les urls que j'avais mis dans ma news qui n'est pas passée (si quelqu'un peut m'expliquer POURQUOI ???) :
http://www.openbeos.org/(...(...))
http://blueos.free.fr/(...(...)) (cocorico :))
[^] # Re: (contrairement à BeOS)
Posté par Parandroid . Évalué à 3.
http://linuxfr.org/topic/Be/5611,0,1,0,1.php3(...(...))
# une qualité du texte...
Posté par Rin Jin (site web personnel) . Évalué à 6.
Jusqu'à présent, je savais que les systémes multi processeur ont plusieurs processeur (logique non?) mais mes connaissances s'arrétaient là.
maintenant, ça m'étonnerais que ce que j'ai appris en lisant ce texte me soit réellement utile dans un avenir proche0
[^] # Re: une qualité du texte...
Posté par Olivier Dupuis . Évalué à 1.
un sens à cet extrait :
qui se comporte de manière à ce que deux processeurs ne dispSystème dExploitationent pas de deux versions différentes de la meme donnée
[^] # Re: une qualité du texte...
Posté par Rin Jin (site web personnel) . Évalué à 2.
Je suis effectivement largué par moment, quand il entre dans des détails qui sont plus pointu et réservé à des informaticien.
Comme je l'ai dit, avant la lecture de ce texte, je savais juste qu'existait des micro à plusieurs processeur.
Quant à la phrase que tu cites, j'y voit une coquille plus qu'autres chose. Je suppose qu'il veut dire (en remplaçant dispSystème dExploitationent par dispose* ) que le cache s'arrange pour que deux processeur travaillant sur la même donnée au même moment n'ai pas 2 valeur différentes de celle ci.
*il a du remplacer toutes les occurences de os par systéme d'exploitation et a mal relu
[^] # Re: une qualité du texte...
Posté par Olivier Dupuis . Évalué à 1.
Par contre, je n'avais pas vu le s/OS/Système d'Exploitation/
[^] # Re: une qualité du texte...
Posté par Romain Langlois . Évalué à 0.
# Réponse de l'auteur ...
Posté par Romain Langlois . Évalué à 10.
1- sur la forme :
Oui, j'utilise Word. J'avais que ca sous la main. Et je ne suis pas sectaire, j'avoue utiliser autant WindoZ que Linux.
Je corrigerai prochainement les ptites erreurs. Je rajouterai les liens demandés.
2- sur le fond :
C vrai que je reste assez "grand public" : j'ai découvert le multipro avec ca, j'allais pas ecrire une these tout de suite.
Je caresse, parait-il, les linuxiens dans le sens du poil. Vrai et faux : Je parle avant tout des *nix et si je détaille plus linux, c'est evidemment qu'on trouve plus d'infos sur Linux que sur MacOS. Par ailleurs, chui objectif, non ?
J'ai recu par mail un commentaire disant que j'avais un peu skizzé la partie mac Os : J'ai dis que MacOS X devait fonctionner comme un *nix, on me l'a confirmé depuis. Pour les autres (OS 9), Apple communique peu et je n'ai pas trouvé d'expérience concluante concernant l'utilisation en multiprocesseur. Des spécialistes mac m'ont meme dit que ca cafouillait un peu, mais n'ayant pas d'info fiable, j'ai abandonné cette piste. si kkun veut commenter...
OpenBeOS est un projet interessant (j'ai BeOS sur ma machine), mais je pense effectivement qu'il est trop tot pour "investir" dans ce système, contrairement à Linux par exemple. Et puis, j'ai noté "avenir incertain", pas "avenir foutu!"... A suivre donc
En ce qui concerne JavaOS, avez vous des infos sur l'abandon par Sun de cet OS ? Moi, on m'a dit que si sun communiquait moins, c'etait purement commercial, mais que le projet continuait...
Bon , CT un peu long, sorry. J'incluerai, avec les permission des auteurs, les commentaires interessants dans la page d'accueil...
A+
[^] # Re: Réponse de l'auteur ...
Posté par Aza . Évalué à 1.
Le noyau Mach utilisé par Mac OS X n'a rien de secret : Tannenbaum le décrit déja dans son bouquin en 1990.
pour la documentation apple, on peut aller chercher la : http://developer.apple.com/techpubs/(...)
# OS multipro ??
Posté par laurent Belmonte . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.