OVH Cloud OVH Cloud

Temps partagé !

3 réponses
Avatar
Ioda
Bjr,

J'ai un petit soucis sur la gestion des processus en temps partagé. Peut
etre que quelqu'un ici aurait une idée pour m'éclairer.

La problematique : j'ai 5 processus, le quamtum est de 20 ms. Pas de
priorité au niveau des processus.

L'ordonnancement suivant est il exact ?

00 à 20ms : proc1
20 à 40 ms : proc2
40 à 60 ms : proc3
60 à 80 ms : proc4
80 à 100 ms : proc5
100 à 120 ms proc1
etc...

Merci de me confirmer ou de m'infirmer.

Ioda

3 réponses

Avatar
Erwann ABALEA
On Tue, 8 Feb 2005, Ioda wrote:

La problematique : j'ai 5 processus, le quamtum est de 20 ms. Pas de
priorité au niveau des processus.

L'ordonnancement suivant est il exact ?

00 à 20ms : proc1
20 à 40 ms : proc2
40 à 60 ms : proc3
60 à 80 ms : proc4
80 à 100 ms : proc5
100 à 120 ms proc1


Non. Il *peut* être exact à un moment donné, mais il peut aussi être tout
autre chose. En fait, il n'est pas déterministe, il dépend de ce que font
les tâches, de la charge du système (d'autres process auront peut-être une
priorité plus élevée ailleurs).

En règle générale, ne pas compter sur un ordre précis de la part de
l'ordonnanceur.

Si tu ajoutes les systèmes SMP et/ou SMT, c'est encore plus faux.
(SMP=multiprocesseur, SMT=hyperthreading).

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Newsgroups: fr.comp.mail
je suis à la recherche d'un shema électronique d'un émetteur G.P.S
(Global position system) ou à defaut une adrs Email
-+- N in Guide du Neuneu Usenet - Sans son GNU, on est perdu -+-

Avatar
Ioda
Merci d'avoir pris du temps pour me répondre,
je donne plus de précision sur ma problématique (c'est une partie de sujet
de partiel) :

Un programme destiné à contrôler un processus industriel comporte à un
instant donné 5 tâches, dont la consommation en temps processeur est la
suivante :
tâche 0 : 5 sec
tâche 1 : 10 sec
tâche 2 : 2 sec
tâche 3 : 1 sec
tâche 4 : 3 sec

Il n'existe aucune priorité entre tâches (technique du temps partagé), la
durée de commutation est négligée devant la durée du quantum (20 ms). Le
quatum correspond à la durée d'execution du noyau (cette durée est
considérée comme fixe).

a) donner la répartition du temps processeur (systeme mono processeur),
entre le temps consacré aux tâches et celui consacré au noyau jusq'à
l'execution des 5 tâches.

b) au bout de combien de temps chaque tâches est terminée ?

c) Le noyau utilisé est maintenant capable de gérer des priorités. La
politique de priorité choisie est la suivante :

Niveau 1 de priorité : 1 quantum
Niveau 2 de priorité : 2 quantum etc...

Les tâches rpriorité respectives sont les suivantes : T0:6, T1: , T2:3,
T3:4, T4:5

Le niveau 6 est le niveau de priorité maximal, donner les instants de début
et de fin d'éxecution de chaque tâche. Comparer à celui obtenu au b)


Voilou,
Qu'en pensez vous, moi j'ai des idées mais aucune certitude lol

Ioda
Avatar
Vincent Bernat
OoO En cette matinée pluvieuse du mardi 08 février 2005, vers 10:25,
"Ioda" disait:

Un programme destiné à contrôler un processus industriel comporte à un
instant donné 5 tâches, dont la consommation en temps processeur est la
suivante :
tâche 0 : 5 sec
tâche 1 : 10 sec
tâche 2 : 2 sec
tâche 3 : 1 sec
tâche 4 : 3 sec

Il n'existe aucune priorité entre tâches (technique du temps partagé), la
durée de commutation est négligée devant la durée du quantum (20 ms). Le
quatum correspond à la durée d'execution du noyau (cette durée est
considérée comme fixe).

a) donner la répartition du temps processeur (systeme mono processeur),
entre le temps consacré aux tâches et celui consacré au noyau jusq'à
l'execution des 5 tâches.


Je vois guère comment on peut donner le temps accordé au noyau quand
on a aucun renseignement dessus. Ensuite, si on suppose que les tâches
n'ont aucun passé, que la priorité des tâches est statique, la tâche 3
se finit en 5 secondes alors que toutes les autres tâches ont été
exécuté pendant une seconde, la tâche 2 finit 4 secondes plus tard, la
tâche 4 3 secondes plus tard, etc.

À mon avis, cela doit être rudement plus simple à comprendre en
regardant les conventions utilisées en cours.
--
BOFH excuse #120:
we just switched to FDDI.