Forum Programmation.c Occupation CPU

Posté par  .
Étiquettes : aucune
0
5
août
2004
Salut à vous,
Je suis en train de coder un petit serveur en utilisant les pthreads. Le problème, c'est que le thread faisant tourner la fonction serveur utilise 99% du CPU, à cause des i/o non bloquantes. Le code ressemble à ça :

void *server(void)
{
....while ( contrôle du serveur)
....{
......../* Prépare le select à grand coup de FD_SET */
......../* Prépare la structure timeval, avec un timeout de 5000 uS */
........select
......../* Teste le set de socket et lance des threads interpreteurs */
......../* Teste une variable globale contrôlant l'état du serveur */
....}
....pthread_exit(code d'erreur);
}

Comment faire pour réduire la charge CPU à quelque chose de plus raisonnable ? J'ai joué un peu avec le timeout de select, mais ça n'a pas amélioré les choses. D'autre part, on m'a dit qu'utiliser les variables globales en C, c'était Mal, mais je ne vois pas comment m'en passer avec les threads. Y a-t-il un procédé plus élégant ?

Merci pour votre aide :)

  • # select() + timeout

    Posté par  . Évalué à 3.

    Ici sur un select() qui boucle à chaque 50 milisecondes la charge CPU tombe à 0 sur un projet de serveur que j'ai. J'ai besoin de faire ce bouclage sous Windows pour vérifier les événements de la console. Sous Linux je ne boucle pas sur un timeout mais ayant essayé le timeout qui fait boucler la charge CPU est aussi à 0. Par contre, je n'ai jamais joué avec les pthreads.

  • # Non ce n'est pas mal

    Posté par  . Évalué à 3.

    D'autre part, on m'a dit qu'utiliser les variables globales en C, c'était Mal
    Non ce n'est pas mal tant que c'est utilisé judicieusement.
    Mais si c'est mal utilisé c'est catastrophique pour la lisiiblité et la maintenance. C'est pour cela que l'on conseille souvent eux débutants de ne pas les utiliser.

  • # timeout

    Posté par  (site web personnel) . Évalué à 4.

    déjà un timeout de 5000 uS c'est à dire 5 ms c'est très peu. il faut savoir que la résolution sur ta machine est sûrement de 10 ms de toutes façons, si ton HZ est à 100 comme c'est par défaut (seuls les processus root realtime pourront faire des choses plus précises). je pense que si tu l'augmentes il n'y a pas de raison que ça continue à tout bouffer.

    • [^] # Re: timeout

      Posté par  (site web personnel) . Évalué à 3.

      Pour compléter, le HZ a 100 (== 10 ms) est le default des noyaux 2.4. Le 2.6 est passé à 1 ms. Il existe des kernel red hat 2.4 à Hz=512 (<2ms).

      Donc boucler à moins que le HZ, fait que la tache est tout le temps prète.

      sinon, je pense que le timout du select peut être très élevé sans que cela gène quoi que se soit.

      "La première sécurité est la liberté"

      • [^] # Re: timeout

        Posté par  (site web personnel) . Évalué à 5.

        le défaut du 2.6 est à 100 aussi pour raison de compatibilité, en tous cas c'est ce que j'ai lu de la main de Robert Love il y a quelques jours..

        tes deux dernières phrasent se contredisent, tu ne crois pas ?

  • # Ma méthode à moi...

    Posté par  . Évalué à 4.

    Je fais généralement un pipe entre un thread de contrôle et le thread serveur; la sortie du pipe est dans les descripteurs surveillés par select, comme ça, pas besoin de timeout.
    Lorsque le thread de contrôle veut dire quelque chose au thread serveur, il le réveille en écrivant dans le pipe, le reste de la comm se fait par segments de mémoire partagés.

    • [^] # Re: Ma méthode à moi...

      Posté par  . Évalué à 2.

      Merci beaucoup, je pensais boucler à 50 ms et non 5... honte sur moi !!
      Pour le contrôle, en fait ma fonction serveur lance un mini shell dans un autre thread au début, avant de boucler, en lui passant un pointeur vers une structure contenant quelques booleens et un pointeur sur requête. Comment ça se présente au niveau code la technique du pipe ? C'est portable ?

      • [^] # Re: Ma méthode à moi...

        Posté par  . Évalué à 2.

        OK, j'ai trouvé un tutorial assez succint, si j'ai bien compris ça consiste à partager un descripteur pour éviter d'utiliser des mutex... Je vais essayer ça.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.