C++

thread et nanosleep( )

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : thread et nanosleep( )

10couNAS

Bonjour :cry:

Je voudrais faire ceci

exécuter le code du thread_01

endormir le thread_01 pendant 1ms
exécuter le code du thread_02 pendant une partie de cette 1ms

endormir le thread_02 pendant 1ms
exécuter le code du thread_01 pendant une partie de cette 1ms

.....

Les fonctions usleep, nanosleep, setitimer ne sont valables que pour les processus (elles endorment le processus entier si on l'utilise dans un thread) et en plus elles ne permettent pas d'obtenir un delai avec un précision inférieure à 10ms

La seule solution qui me vient, c'est d'installer RT Linux et d'utiliser les fonctions pthread_make_periodic_np et pthread_wait_np :ouch:

Le pb c'est que ça va pas être simple du tout :fou:

Donc si qq'un connait une fonction comme nanosleep qui puisse
1)être valable pour les threads et
2) avoir une précision inférieure à 10ms
ça me ferais gagner beaucoup de temps

C'est surtout la précision <10ms qui m'interresse

Publicité

velleronnais

up !
j'suis preneur egalement pour le parametrage inferieur a 10 ms ...

bb138

La vie est belle ...

Peut-être que si tu n'utilises pas les thread et que tu crées des pipes entre tes applis ce serait une solution pour utiliser nanosleep !
Seul soucis (et de taille) je ne suis pas du tout sûr de moi et je ne connais les pipes que de nom... (si on peu dire)

10couNAS

"Peut-être que si tu n'utilises pas les thread et que tu crées des pipes entre tes applis ce serait une solution pour utiliser nanosleep ! "
J'ai pas bien compris, mais de toute façon, même si il n'y a qu'un seul thread, la fonction nanosleep ne marche pas en dessous de 10ms

bb138

La vie est belle ...

Oups j'oubliai qu'il ne fonctionnait pas...
En fait, ce que je voulais dire c'est que tu ne t'amuses pas avec des threads mais tu fais à la place de chacun d'eux une application. Les applications dialogues ensuite entre elles via des pipes. C'est comme s'il y avait des connections de type réseau entre chaque appli mis à part qu'elles tournent toutes sur la même machine et qu'elles peuvent avoir directement accès à la bonne zone de mémoire (du moins je crois). Mais là-dedans je ne suis pas trop calé... Un gar m'a dit trois mots là-dessus et alors je lui ai dit : "Mais voyons pourquoi s'embêter puisqu'il existe les threads ?" La réponse était simple : à son époque, pourtant pas si lointaine, les threads n'étaient qu'à leur balbutiement d'où cette technique.... Mais bon je ne lui en ai pas demandé plus car je me suis dit "Heureusement pour moi que les threads existent !"

Désolé, mais pour le moment je n'en sais pas plus et je crois que cela risque de durer un peu car je n'ai pas trop de temps en ce moment pour faire de la lecture tranquille le soir

SoWhatIn22

10couNAS a écrit a écrit :

Bonjour :cry:

Les fonctions usleep, nanosleep, setitimer ne sont valables que pour les processus (elles endorment le processus entier si on l'utilise dans un thread) et en plus elles ne permettent pas d'obtenir un delai avec un précision inférieure à 10ms

La fonction select fonctionne bien avec les threads.

Code :

int MySleepMs( unsigned int timeout_ms )
{
struct timeval tv;
tv.tv_sec = timeout_ms/1000;
tv.tv_usec = (timeout_ms%1000) * 1000;
select(0, NULL, NULL, NULL, &tv);
return 0;
}

Pour faire passer la main aux autres threads, tu devrais pouvoir utiliser la fonction pthread_yield. Mais je ne suis pa sûr que ce soit dans toutes les implémentations des threads POSIX.

Jar Jar

Intaigriste

nanosleep marche très bien dans les threads (testé sur Linux et Solaris).

Au passage, pour ce que tu fais, ce serait mieux d'utiliser des sémaphores en plus des nanosleep.

---------------
« No question is too silly to ask, but, of course, some are too silly to answer. » -- Perl book

10couNAS

Jar Jar, tu arrives à obtenir quoi comme précision avec nanosleep?

10couNAS

En ayant programmé un delai de 1ms, voici les résultats :
Duree du nanosleep => 16,397 ms
Duree du select => 7,466 ms
Duree du pselect => 9,355 ms

Code :

#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <time.h>
int main(void)
{
struct timeval date_debut;
struct timeval date_fin;
struct timespec duree_nanosleep;
struct timeval duree_select;
struct timespec duree_pselect;
duree_nanosleep.tv_sec=0;
duree_nanosleep.tv_nsec=1000000; //1 ms
fprintf(stdout,"NANOSLEEP => Durée = %ld.%09ld",duree_nanosleep.tv_sec,duree_nanosleep.tv_nsec);
puts("" );
gettimeofday(&date_debut,NULL);
nanosleep(&duree_nanosleep,&duree_nanosleep);
gettimeofday(&date_fin,NULL);
fprintf(stdout,"Avant le nanosleep date = %ld.%06ld\n",date_debut.tv_sec,date_debut.tv_usec);
fprintf(stdout,"Après le nanosleep date = %ld.%06ld\n",date_fin.tv_sec,date_fin.tv_usec);
duree_select.tv_sec=0;
duree_select.tv_usec=1000; //1ms
fprintf(stdout,"SELECT ====> Durée = %ld.%06ld",duree_select.tv_sec,duree_select.tv_usec);
puts("" );
gettimeofday(&date_debut,NULL);
select(0,NULL,NULL,NULL,&duree_select);
gettimeofday(&date_fin,NULL);
fprintf(stdout,"Avant le select date = %ld.%06ld\n",date_debut.tv_sec,date_debut.tv_usec);
fprintf(stdout,"Après le select date = %ld.%06ld\n",date_fin.tv_sec,date_fin.tv_usec);
duree_pselect.tv_sec=0;
duree_pselect.tv_nsec=1000000; //1ms
fprintf(stdout,"PSELECT ===> Durée = %ld.%09ld",duree_pselect.tv_sec,duree_pselect.tv_nsec);
puts("" );
gettimeofday(&date_debut,NULL);
pselect(0,NULL,NULL,NULL,&duree_pselect);
gettimeofday(&date_fin,NULL);
fprintf(stdout,"Avant le pselect date = %ld.%06ld\n",date_debut.tv_sec,date_debut.tv_usec);
fprintf(stdout,"Après le pselect date = %ld.%06ld\n",date_fin.tv_sec,date_fin.tv_usec);
}

Jar Jar

Intaigriste

BUGS
The current implementation of nanosleep is based on the normal kernel
timer mechanism, which has a resolution of 1/HZ s (i.e, 10 ms on
Linux/i386 and 1 ms on Linux/Alpha). Therefore, nanosleep pauses
always for at least the specified time, however it can take up to 10 ms
longer than specified until the process becomes runnable again. For the
same reason, the value returned in case of a delivered signal in *rem
is usually rounded to the next larger multiple of 1/HZ s.

As some applications require much more precise pauses (e.g., in order
to control some time-critical hardware), nanosleep is also capable of
short high-precision pauses. If the process is scheduled under a real-
time policy like SCHED_FIFO or SCHED_RR, then pauses of up to 2 ms will
be performed as busy waits with microsecond precision.

Donc il faut mettre en place une politique de scheduling avec pthread_setscheduler et tu auras la précision requise.

---------------
« No question is too silly to ask, but, of course, some are too silly to answer. » -- Perl book

Publicité

10couNAS

Ok Jar Jar et merci

Par contre, j'ai rajouté ça dans mon programme

Code :

struct sched_param param;
param.sched_priority=1;
if (sched_setscheduler (getpid(), SCHED_RR, & param) < 0) {
perror ("setscheduler" );
exit (1);
}

j'ai compilé gcc -o mon_prog mon_prog.c
tout s'est bien passé
après j'ai fait

>su
>Password ****
#chown root.root mon_prog
#chmod u+s mon_prog
#exit
>./mon_prog
Mon programme s'est lancé et au bout de deux secondes, tout a planté apparemment.
Je ne peux plus rien faire du tout sous mon linux!!

Jar Jar

Intaigriste

Là je suis désolé, je ne peux pas t'aider, je n'ai jamais fait mumuse avec les schedulers.

---------------
« No question is too silly to ask, but, of course, some are too silly to answer. » -- Perl book

Musaran

Cerveaulté

10 ms, c'est (environ) la durée de temps minimum allouée par le système.
On peut toujours l'abréger avec sleep, mais rien ne garantit que c'est l'autre thread qui aura la main.

Approches générales:
-N'avoir qu'un seul thread. Quel intérêt d'en avoir 2 s'ils ne doivent pas s'exécuter en même temps ?
-Créer un troisième thread chargé du travail.

Approches Windows:
-Augmenter la priorité de l'autre thread avec SetThreadPriority avant un Sleep(durée 0).
-SwitchToThread, mais il n'y a pas de paramètres.
-ConvertTheadToFiber sur les threads, SwitchToFiber pour passer de l'un à l'autre avec un seul fil d'exécution.
-CreateMutex et WaitForSingleObject.

---------------
Bricocheap: Montage de ventilo sur paté de mastic silicone

yung3001

Hello

Programmez sous Windows les gas, la fonction Sleep() SDK de Windows, n'endore que le thread qui l'appelle, et pas le processus...

Nanannn! je suis pas un pro Windows, loin de là...
:sol:

10couNAS

Sous Linux, j'ai réussi à obtenir un délai de 20µs en mettant l'ordonnancement RR (temps réel) et en me mettant en root. :hap:
Par contre, il y a un gros pb sous linux :
si il y a plusieurs threads ayant une priorité indentique, il sera impossible qu'ils s'exécutent en parallèle (le premier thread s'exécutera, puis le 2ème qd le 1er sera terminé, pui...)
et pire, si un thread fait une boucle infini par exemple pour actualiser l'ITF toutes les secondes, les autres threads de même priorité n'auront jamais la main

Pour résumer: si on veut un ordonnancement tps réel on ne pourra pas utiliser des threads :non:

Jar Jar

Intaigriste

yung3001 a écrit a écrit :

Programmez sous Windows les gas, la fonction Sleep() SDK de Windows, n'endore que le thread qui l'appelle, et pas le processus...

C'est bien, tu veux dire que ça marche comme sous Unix ?

Tu ne m'as pas convaincu d'acheter une licence de Windows XP, là, essaye encore.

---------------
« No question is too silly to ask, but, of course, some are too silly to answer. » -- Perl book

yung3001

Citation :

C'est bien, tu veux dire que ça marche comme sous Unix ?

Tu ne m'as pas convaincu d'acheter une licence de Windows XP, là, essaye encore.

Linux, Solaris, Windows, Mac OS, Amiga OS, BeOS... le tout n'est pas de savoir qui est le meilleurs, mais c'est d'avoir un système qui nous convienne. Windows c'est pas le top (c'est pas un scoop, mais ça s'améliore...quoi que), mais c'est malheureusement la seul plateforme ou tu trouves ce que tu veux quand comme moi (et des millions d'autres): Tu aimes faire de la musique (carte d'extension pro, logiciels pro), tu aimes jouer de temps en temps, programmer un peu pour toi ou ton boulot, lire tes emails, regarder des DVDs, graver, imprimer, utiliser des logiciels pas courant (généalogie...); et tout ça sur la même bécane. Pour ça, y'a que Windows, ou à la rigueur MacOS; pour la zic par exemple, les cartes PCI que j'ai, leur drivers ne fonctionnent que sous Windows.
C'est pas l'envi qui me manque de passer à autre chose, mais ça ne me servirait à rien à part bidouiller. Et au boulot, que du Windows, et du Solaris (mais Solaris à la maison, faut être taré :pt1cable: ).
:bounce:

Jar Jar

Intaigriste

yung3001 a écrit a écrit :

Linux, Solaris, Windows, Mac OS, Amiga OS, BeOS... le tout n'est pas de savoir qui est le meilleurs, mais c'est d'avoir un système qui nous convienne. Windows c'est pas le top (c'est pas un scoop, mais ça s'améliore...quoi que), mais c'est malheureusement la seul plateforme ou tu trouves ce que tu veux quand comme moi (et des millions d'autres): Tu aimes faire de la musique (carte d'extension pro, logiciels pro), tu aimes jouer de temps en temps, programmer un peu pour toi ou ton boulot, lire tes emails, regarder des DVDs, graver, imprimer, utiliser des logiciels pas courant (généalogie...); et tout ça sur la même bécane. Pour ça, y'a que Windows, ou à la rigueur MacOS; pour la zic par exemple, les cartes PCI que j'ai, leur drivers ne fonctionnent que sous Windows.

Hmmmm non, ça ne me convainc pas.

Pourquoi tu cherches absolument à me faire passer à Windows ? Tu fais ce que tu veux chez toi, mais de mon point de vue, il n'a que des inconvénients.

---------------
« No question is too silly to ask, but, of course, some are too silly to answer. » -- Perl book

antp

Super Administrateur
Champion des excuses bidons

yung3001 > les trolls Windows - Linux c'est sur Soft & Reseau et sur OS Alternatifs. Ici ce sont plutôt les trolls concernant les langages. Merci de ne pas polluer avec ce genre de posts inutiles (surtout que Windows t'as pas une précision à la milliseconde près non plus)

---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire

erwan_oops

sur tru 64 unix il y a un nanaosleep un peut particulier (qui est _NP (nonportable)) et qui permet de n'endormir que le thread apelant mais la pression depant de se qui a ete programmer dans ton noyau (1ms ou plus en fonctionde l'install) sinon sur QNX nanosleep doit fonctionner nickel même pour 1 ms

---------------
la théorie c quant tout dois fonctionner mais rien ne marche la pratique c quant tout marche mais personne ne c pourquoi ici on fais un bon compromis rien ne marche et personne ne c pourquoi :D

erwan_oops

corection de 2 ou 3 faute de frappe C pas pression mais precision et le non du nanosleep C pthread_delay_np

Jar Jar

Intaigriste

erwan_oops a écrit a écrit :

sur tru 64 unix il y a un nanaosleep un peut particulier (qui est _NP (nonportable)) et qui permet de n'endormir que le thread apelant mais la pression depant de se qui a ete programmer dans ton noyau (1ms ou plus en fonctionde l'install) sinon sur QNX nanosleep doit fonctionner nickel même pour 1 ms

Il me semble avoir vu traîner aussi ce genre de trucs (avec des #define spécifiques et des _NP) pour Linux, ce n'est peut-être pas si non-portable...

---------------
« No question is too silly to ask, but, of course, some are too silly to answer. » -- Perl book

Publicité

FORUM HardWare.fr

Programmation

C++

thread et nanosleep( )

Sujets relatifs
faire un wait() sur un Thread déjà suspendu + comment killer 1 thread	agir sur un groupe de thread, méthode activeCount()
thread	classe anonyme et création de thread à la volée
Multi thread	[VC++]PB de thread
[C++] Killer un thread, mais pas comme un gros cochon :o	Thread
thread	[JAVA] probleme de thread
Plus de sujets relatifs à : thread et nanosleep( )

Page générée en 0.088 secondes