Discussion :

[vaderetro33]

Bonjour, je doit réaliser un petit programme en C qui effectue une requête d'insertion dans une base de données toutes les secondes, je voudrais savoir avec quel fonction je peut lancer ma requête pour que le programme l'exécute toutes les seconds sans se terminer.
Merci.

[ram-0000]

Un truc comme cela ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
while(1)
{
   sleep(1);
   fonction_qui_fait_la_requete();
}

fonction sleep()

[Grulim]

Je ne sais pas sous quel os tu programmes, mais sous windows, et contrairement à Linux, Sleep attend une valeur en millisecondes, genre Sleep(1000) pour 1 seconde.

[ram-0000]

Sleep() sous windows oui, c'est des millisecondes
mais sleep() sous unix non, c'est des secondes

[Grulim]

Oui, c'est pourquoi j'avais pris la précaution d'écrire

...
mais sous windows, et contrairement à Linux
...

(Arf, je m'autocite, c'est y pas la gloire )

[souviron34]

du coup, c'est quand même pas trop compliqué :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
#ifdef _WIN32
#define INTERV  1000
#else
#define INTERV 1
#endif
 
while(1)
{
   sleep(INTERV);
   fonction_qui_fait_la_requete();
}

[Grulim]

Sans vouloir pinailler, sous Windows, il y a un 'S' majuscule...

[LittleWhite]

Et puis sleep c'est pas le best ...
Mais restons dans le simple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#if defined(__WIN32)
     #define SLEEP(x) Sleep(x)
#else
     #define SLEEP(x) sleep(x/1000)
#endif

Et hop, on a tout ce que l'on veut ...

[Mac LAK]

Mieux, et avec des millisecondes comme résolution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
#if defined(__WIN32)
     #include <windows.h>
     #define SLEEP_MS Sleep
#else
     #include <unistd.h>
     inline void SLEEP_MS ( unsigned int Milliseconds ) {
          /* Attente du nombre de secondes, au besoin */
          if (Milliseconds>1000) 
                    sleep(Milliseconds/1000); 
          /* Attente du reliquat */
          usleep((Milliseconds%1000)*1000);
     }
#endif

Un poil plus précis que l'attente arrondie à la seconde sur Unix, et avec le contournement du problème d'une attente supérieure à une seconde avec usleep.
On pourrait aussi utiliser nanosleep à la place, mais c'est plus lourd à mettre en œuvre (requiert une variable locale, donc potentiellement des soucis sous forme de macro).

Bon, faudrait blinder ça sur Unix côté signaux, mais bon, ça reste du détail.

[nicolas.sitbon]

Mieux, et avec des millisecondes comme résolution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
#if defined(__WIN32)
     #include <windows.h>
     #define SLEEP_MS Sleep
#else
     #include <unistd.h>
     inline void SLEEP_MS ( unsigned int Milliseconds ) {
          /* Attente du nombre de secondes, au besoin */
          if (Milliseconds>1000) 
                    sleep(Milliseconds/1000); 
          /* Attente du reliquat */
          usleep((Milliseconds%1000)*1000);
     }
#endif

Un poil plus précis que l'attente arrondie à la seconde sur Unix, et avec le contournement du problème d'une attente supérieure à une seconde avec usleep.
On pourrait aussi utiliser nanosleep à la place, mais c'est plus lourd à mettre en œuvre (requiert une variable locale, donc potentiellement des soucis sous forme de macro).

Bon, faudrait blinder ça sur Unix côté signaux, mais bon, ça reste du détail.

This function is marked obsolescent.

[LittleWhite]

Le message posté à minuit qui tue

Certes usleep était bien simple mais maintenant il est préférable d'utiliser nanosleep. De plus, si on veut vraiment avoir un truc identique, faut faire nanosleep pour linux et une histoire avec les cycles sous windows. Dans les deux cas, le code devient un peu lourd.
Sinon, pour windows on installe le posix :p

[nicolas.sitbon]

Personnellement, mes codes sont pour la plupart multiplexés, de fait, j'ai tendance à délaisser ces fonctions, pour des apis plus puissantes, je recommande sur un système POSIX (REALTIME) timer_create(), sur un linux timerfd_create(), sur Windows CreateWaitableTimerEx()

[Mac LAK]

This function is marked obsolescent.

Certes : j'en tiendrais compte le jour où tous les compilos C et noyaux *nix suivront cette norme... Ce qui n'est pas pour tout de suite, et de toutes façons non-gênant vu que je n'appelle jamais ces fonctions en dehors d'un wrapper portable.

Personnellement, mes codes sont pour la plupart multiplexés, de fait, j'ai tendance à délaisser ces fonctions, pour des apis plus puissantes, je recommande sur un système POSIX (REALTIME) timer_create(), sur un linux timerfd_create(), sur Windows CreateWaitableTimerEx()

La fonction timer_create pose le souci d'être unique sur un processus donné, sans parler des soucis parfois avec les clocks plus ou moins précises. Je préfère pour ma part coller le processus critique sur interruption / thread RT, et utiliser un nanosleep correctement implémenté : dommage qu'il ne le soit en général que sur des OS temps réel, c'est un peu le souci...

Quant à CreateWaitableTimerEx, c'est Windows Vista minimum pour l'avoir : rédhibitoire, à mon sens, car cela coupe la portabilité vers W2k et XP qui restent très majoritaires dans mon secteur d'activité.

[Grulim]

...
sur Windows CreateWaitableTimerEx()

C'est une fonction ajoutée récemment (Vista/Serveur 2008), pour les systèmes plus anciens (2000), y'a sa petite soeur CreateWaitableTimer()

[nicolas.sitbon]

Certes : j'en tiendrais compte le jour où tous les compilos C et noyaux *nix suivront cette norme... Ce qui n'est pas pour tout de suite...

POSIX 2004 est je trouve, au contraire, bien supporté de nos jours sur les environnement UNIX, tu parles de quel UNIX la? ça n'est pas Linux, BSD(like), Solaris, AIX, rien que là, on couvre la majeur partie et je n'ai pas fini.

La fonction timer_create pose le souci d'être unique sur un processus donné, sans parler des soucis parfois avec les clocks plus ou moins précises.

Je ne vois aucun problème avec timer_create() et ne comprend pas ce que tu racontes. On s'en sert (dans ma boite) dans des applications multithread sans soucis, quand à la précision, sous Linux au moins, il n'y a pas plus précis.

Quant à CreateWaitableTimerEx, c'est Windows Vista minimum pour l'avoir : rédhibitoire, à mon sens, car cela coupe la portabilité vers W2k et XP qui restent très majoritaires dans mon secteur d'activité.

Tu joues sur les mots, CreateWaitableTimer() existe depuis Windows 2000, la version extended n'est pas obligatoire pour ce que l'on veut faire.

[Mac LAK]

POSIX 2004 est je trouve, au contraire, bien supporté de nos jours sur les environnement UNIX, tu parles de quel UNIX la? ça n'est pas Linux, BSD(like), Solaris, AIX, rien que là, on couvre la majeur partie et je n'ai pas fini.

Notamment des Unix RT comme QNX, qui ne marquent pas cette fonction comme obsolète. Donc, aucune raison de ne pas l'utiliser, dixit le manuel fourni avec l'OS.

Je ne vois aucun problème avec timer_create() et ne comprend pas ce que tu racontes. On s'en sert (dans ma boite) dans des applications multithread sans soucis, quand à la précision, sous Linux au moins, il n'y a pas plus précis.

On a eu des soucis avec sur des applis multithread, avec des comportements un peu différents entre les différents *nix que l'on utilise, et/ou avec la précision des différentes horloges possibles (un coup c'est CLOCK_REALTIME qui est la plus précise, un coup c'est CLOCK_MONOTONIC, tout dépend du câblage de la machine et de l'OS).

D'où le fait de préférer mettre la tâche critique en IT, ou comme étant la seule et unique tâche RT. Dans ce contexte, laisser les autres tâches / threads se débrouiller à coup de nanosleep / usleep est amplement suffisant, de toutes façons elles ne sont pas prioritaires et leur temps d'exécution n'a pas énormément d'importance.

Tu joues sur les mots, CreateWaitableTimer() existe depuis Windows 2000, la version extended n'est pas obligatoire pour ce que l'on veut faire.

Mais cela reste celle que tu as citée, qui n'est pas la "bonne" (du moins dans le contexte actuel). Reste que certes, cette fonction est plus précise, mais elle est aussi bien moins pratique à utiliser qu'un Sleep : la création du timer prends du temps (donc, mort pour les attentes one-shot sauf à jouer avec le TLS), et elle demande bien plus d'instructions pour être utilisée.

Il faut voir aussi l'usage final : pour une fonction devant être exécutée à des intervalles de l'ordre du quantum de temps de l'OS, ces timers sont en effet la bonne solution (en dessous, c'est l'IT qui est préférable).
Mais quand c'est juste pour passer la main aux autres threads à partir d'un thread non-critique (thread IHM, par exemple), pour des attentes "longues" (> 500 ms, surtout lorsque le temps d'exécution de la routine est négligeable par rapport à l'attente), un Sleep est bien plus pratique, pour ne pas dire plus efficace.

Or, sur la demande de l'OP, c'est justement ce dernier cas de figure : une requête d'insertion en BD toutes les secondes, donc quelque chose de "court" à faire par rapport au délai d'attente. Certes, il est possible d'optimiser en mettant cette insertion en callback des timers, mais c'est plus lourd à mettre en œuvre, et moins facilement portable. Si la légère dérive temporelle dûe aux Sleeps n'est pas gênante, autant s'éviter les timers.

[souviron34]

La fonction timer_create pose le souci d'être unique sur un processus donné, sans parler des soucis parfois avec les clocks plus ou moins précises.

le lien n'est toujours par remis dans la partie code source C, mais je ne sais pas si tu as déjà essayé mon GetClock :

Le code est ici.

Ce lien sera rétabli sous peu dans la page des codes sources.

Merci à Franck.H pour avoir retrouvé ce lien

[nicolas.sitbon]

Or, sur la demande de l'OP, c'est justement ce dernier cas de figure : une requête d'insertion en BD toutes les secondes, donc quelque chose de "court" à faire par rapport au délai d'attente. Certes, il est possible d'optimiser en mettant cette insertion en callback des timers, mais c'est plus lourd à mettre en œuvre, et moins facilement portable. Si la légère dérive temporelle dûe aux Sleeps n'est pas gênante, autant s'éviter les timers.

Je crois qu'on imagine 2 contextes différents, dans le mien, j'ai plusieurs taches à faire simultanément, sleep() est bloquant, et ne me permet de traiter qu'une tache à la fois, avec les timers, je peux traiter plusieurs taches (comprendre : attendre plusieurs timers) simultanément. Dans le contexte que tu imagines, tu penses que le PO (je ne dis pas que tu as tord) n'as que cela à faire, et donc qu'il peut bloquer son thread sans soucis pour le reste. Si effectivement, il n'a qu'une tache à accomplir et que le temps n'est pas critique, un sleep() suffit largement, on est d'accord. Maintenant, s'il a plus d'une tache à accomplir, les timers restent la meilleure alternative à mon sens.

[souviron34]

Si effectivement, il n'a qu'une tache à accomplir et que le temps n'est pas critique, un sleep() suffit largement, on est d'accord. Maintenant, s'il a plus d'une tache à accomplir, les timers restent la meilleure alternative à mon sens.

je suis d'accord, mais moi ce que je préfère dans ce cas c'est me faire ma propre pile de timers.. (d'où l'intérêt de mon GetClock )

En gérer un seul, et gérer moi-même les appels successifs et les bloquages ou débloquages..

[Mac LAK]

le lien n'est toujours par remis dans la partie code source C, mais je ne sais pas si tu as déjà essayé mon GetClock

Je parlais de la précision entre REALTIME et MONOTONIC, en fait.
J'ai regardé ton code : classique, en effet, par contre je suis assez surpris de voir un gettimeofday sous Windows plutôt qu'un QueryPerformanceCounter : t'es sûr de ne pas avoir laissé du code Cygwin pour cet OS ? Parce que sous VS, en tout cas, il couine sur <sys/time.h>...

Je crois qu'on imagine 2 contextes différents, dans le mien, j'ai plusieurs taches à faire simultanément, sleep() est bloquant, et ne me permet de traiter qu'une tache à la fois, avec les timers, je peux traiter plusieurs taches (comprendre : attendre plusieurs timers) simultanément. Dans le contexte que tu imagines, tu penses que le PO (je ne dis pas que tu as tord) n'as que cela à faire, et donc qu'il peut bloquer son thread sans soucis pour le reste. Si effectivement, il n'a qu'une tache à accomplir et que le temps n'est pas critique, un sleep() suffit largement, on est d'accord. Maintenant, s'il a plus d'une tache à accomplir, les timers restent la meilleure alternative à mon sens.

Effectivement : pour moi, une tâche = un thread, donc il n'est absolument pas gênant de le bloquer (et pour cause ! ). A part les threads assurant un dispatching quelconque (et ils sont rares), aucun thread n'a plus d'une chose à faire, quoi qu'il arrive. C'est une simple question de fonctionnement maximal même si un thread vient à se planter, en fait, une sorte de mini tolérance de panne si tu préfères. Du coup, forcément, je n'utilise les timers que dans le cas d'attentes très courtes ET cycliques, de façon à avoir un comportement similaire à une IT, mais dans un contexte "normal".

Pour le reste, c'est surtout pour qu'un lecteur de passage lisant le topic aie le maximum d'infos en main pour choisir la bonne solution pour son propre usage. Au moins, là, c'est quasi-complet comme résolution du problème !