Bonjour!
 
Je travaille actuellement sur un projet C++ multi-thread en temps réel, et je voudrais savoir s'il existe une fonction C++ (ou C) ou une méthode permettant à une suite d'instructions de ne pas être interrompues par un autre thread ou par l'execution d'instructions dans un autre objet que celui qui ne doit pas être interrompu. Je me demande donc si il existe une fonction permettant de dedier le CPU à un objet pendant une courte période (de l'ordre de 500 ms maximum). Il faut savoir qu'à un instant donné il peut y avoir jusqu'à 50 threads en même temps. Pour le moment j'utilise des sections critiques, le problème est que celle ci peut être interrompue.
 
Merci d'avance pour votre réponse, j'espère avoir été assez claire.

A ma connaissance ce n'est pas possible par soft, mais seulement par interruption hardware.
En gros il faudrait une carte qui "fasse" le temps réel si on peut dire de façon à ne donner à windows que le temps restant.

 
ptet en passant en priorité max, genre real time (sous win) ?

Maintenant que j'y pense Il existe un RT pour win, fait par une filiale Microsoft, WinRiver il me semble ...

De toute facon windobe n'est pas temps reel apres faut te rabattre sur des solution s plus ou moin couteuse

suivant l'os sur lequel t'es y a peut etre une fonction qui fait ce que veux
 
sinon il s'agit simplement de desactiver les interruptions pendant ton traitement, comme ca t'es sur que ton programme a le cpu pour lui tout seul.
 
/slvn

Oui, mais avec ça windows n'est plus qu'une tache de ce RT
Je n'étais pas dans le projet mais des collègues ont testé cette solution avec succès.

WindRiver, c'est l'OS temps réel Tornado, apparemment racheté par Microsoft (ils ont tellement d'argent qu'ils n'ont que ça à faire maintenant). Il est bien évident qu'une appli développée pour du TR sous cet OS ne sera vraisemblablement pas portable aisément sur du Windoze de base.

ouai et elle est a combien la licence de tornado?!? c'est pas donnée

Merci pour vos réponses, mais en fait mon problème est, d'une part affecter le CPU au prg, mais d'autre part au sein de ce processus, affecter le CPU à l'execution d'instructions liés à un objet. Comme j'ai 16 objets et 5 threads par objet et que une courte partie du code doit être executée très rapidement (donc sans être interrompue), je me demande s'il n'existerait pas une methode permettant d'éviter tout types d'interruption (système, mais également le fait que le cpu passe naturellement d'un objet à l'autre, d'un thread à l'autre). Pour les interruptions systèmes j'ai appris à l'école qu'on peut les intercepter, pour l'autre...je ne sais absolument pas. Sinon je travaille effectivement sous Windows.

y'a pas un mutex global sous windows, qui permette de bloquer les autres applis ?

A vrai dire je n'en ai aucune idée, mais mon plus gros problème se trouve à l'interieur même de mon appli : comment affecter pour une courte période le CPU à un bout de mon code. Comme j'ai plusieurs objets et plusieurs threads dans mon appli, pour qu'on ait l'impression que tout se passe en même temps, le cpu pase de l'un à l'autre naturellement, cela devient un pb si des instructions doivent être exécutées rapidement et que le fait d'executer un bout de code de chaque objet au court du temps ralenti l'ensemble.

c'était pas une réponse sérieuse

Tu peux jouer sur la priorité de tes thread,  ou utiliser des fibres à la place des thread. Les fibres sont aux threads ce que les thread sont aux processus. C'est toi qui gère l'ordonancement des fibres. En augmentant la priorité de ton processus et de tes thread (+ configuration de l'OS), tu peux allonger le quantum de temps alloué avant préemption.
Tu peux controller que tes propres threads ne s'interrompent pas entre eux, mais tu ne peux pas bloquer les autres processus. C'est le pricipe même d'un OS multitâche pré-emptif. Comme on te l'a dit Windows n'est pas temps réel, donc tu n'auras pas de solution temps réel. Tu auras toujours un certain temps de latence, et aucune garantie de non pré-emption. Tu peux arriver à d'assez bon résultats à condition d'avoir une charge CPU faible (en gros que y'ai que ton appli qui tourne quoi). Si t'as doom 3 en tâche de fond...