Cas particulier où il est permis de couper les tâches

max max 2C

C^NFM ≤ 4

4.4 Algorithmes optimaux pour deux cas particuliers

Dans cette section, nous étudions 2 cas particuliers et développons 2 algorithmes optimaux pour chacun des cas. Le premier cas suppose qu’il est possible de couper les tâches. Le deuxième cas considère une relation particulière entre les tailles des tâches.

4.4.1 Cas particulier où il est permis de couper les tâches

Dans cette section, nous étudions un cas particulier noté par

P|p-batch,r_j,p_j=p,v_j(split),B|C_max. Le mot « split » rajouté à la notation du problème général signifie que les tâches peuvent être coupées. Notons que quand une tâche est coupée en deux, on obtient 2 tâches dont les dates de disponibilité et les durées d’exécution sont égales. Et bien entendu, la somme de leurs tailles donne la taille de la tâche originale. Notons que le problème avec des tâches de taille unitaire est une façon particulière de couper les tâches. Dans ce cas particulier, nous supposons que les tâches sont composées de sous-tâches de taille unitaire, et la somme des tailles de toutes les sous-tâches compose la tâche principale. De plus, toutes les sous-tâches ont la même date de disponibilité.

Le problème qui considère les tâches de taille unitaire en présence des dates de disponibilité différentes a été étudié par Ikura et Gimple [56]. Leur objectif est la minimisation du Cmax sur une seule machine. Nous généralisons ce cas sur plusieurs machines et modifions un peu l’algorithme proposé par Ikura et Gimple [56]. Cette modification consiste à tout simplement affecter les batch consécutivement sur les machines en fonction du lemme 6.

L’algorithme proposé ici commence par créer une liste, L, des tâches triées en ordre décroissant des dates de disponibilité. Puis, une borne inférieure est

calculée pour le nombre de batch que l’on peut créer avec les tâches de la liste L

(cette borne inférieure est calculée en divisant la somme de toutes les tailles par la capacité des machines). Après avoir trouvé le nombre minimum de batch, on

Un batch est fermé si et seulement s’il est 100% plein ou si toutes les tâches sont placées dans un batch. Si une tâche n’entre pas complètement dans un batch, elle est coupée, sa première partie est mise dans le batch (comme cela on obtient un batch 100% plein) et sa deuxième partie est traitée comme une nouvelle tâche ayant la même date de disponibilité que la tâche non-coupée. Enfin, les batch sont triés en ordre croissant des dates au plus tôt sur les machines.

Algorithme « Split Job »

1. Trier les tâches en ordre décroissant des dates de disponibilité : L 2. Calculer le nombre minimum de batch, nb, par la formule

44 2 55

16^Nj=1^vj/B

3. Tant que nb > 0, ouvrir un batch : bm

3.1. Tant que bm n’est pas 100% plein ou la liste L n’est pas vide,

3.1.1. Mettre le premier élément de L dans le batch b_m. Mettre à jour L. Si le batch est 100% plein ou s’il n’y a plus d’élément dans L, fermer le batch et poser nb = nb -1. Si la tâche n’entre pas complètement dans le batch, la couper. Mettre sa première partie dans le batch afin d’avoir un batch plein. Fermer le batch et poser

nb = nb – 1. Mettre à jour la taille de la tâche coupée.

Fin tant que Fin tant que

4. Fixer pour chaque batch la date au plus tôt égale à la plus grande date de disponibilité des tâches qu’il contient.

5. Ordonnancer les batch consécutivement en ordre croissant des dates au plus tôt sur les machines.

Illustrons l’algorithme sur un exemple.

Exemple illustratif : Soient 3 machines de capacité 5. Soient 8 tâches,

numérotées de 1 à 8, de tailles 3, 4, 2, 4, 1, 2, 4.5, 3 et de dates de disponibilité 10, 20, 40, 45, 50, 80, 100, 100. La durée d’exécution d’un batch est égale à 100.

Résolution de l’exemple : Après avoir trié les tâches en ordre décroissant des

dates de disponibilité, on obtient la liste L contenant les tâche en ordre suivant : 8, 7, 6, 5, 4, 3, 2, 1. Les tâches 7 et 8 ont la même date de disponibilité, nous faisons notre choix arbitrairement.

Nous calculons ensuite la borne inférieure sur le nombre de batch :

1

(3+4+2+4+1+2+4.5+3)/5

2

=5 batch. Pour l’instant, tous ces batch sont vides. En commençant par le premier élément de la liste L, i.e. la tâche 8, on va remplir le premier batch. On met la tâche 8 dans le batch 1. La taille du batch est maintenant 3. La tâche 7 a une taille égale à 4.5, donc, elle ne peut pas entrer complètement dans le batch 1. Alors, la tâche 7 est coupée. Nous la coupons en

deux : la première partie a la taille 2 et la deuxième partie a la taille 2.5. Notons

par 71 la première partie de la tâche 7 et par 72 sa deuxième partie. Nous mettons

7₁ dans le batch 1 afin d’avoir un batch 100% plein.

A chaque fois qu’une tâche est mise dans un batch, la liste L est mise à

jour. Alors, après avoir placé les tâches 8 et 71 dans le batch 1, l’ordre des tâches

qui reste dans L est : 7₂, 6, 5, 4, 3, 2, 1. On remplit maintenant le batch 2 avec les

tâches 72, 6, 51. La tâche 5 est coupée en deux : 51 et 52 sont de même taille égale

à 0.5. Le troisième batch contient les tâches 52, 4, 31, le batch 4 contient les tâches 3₂ et 2₁ et enfin les tâches 2₂ et 1 sont dans le batch 5.

Affectons une date au plus tôt à chaque batch. Nous obtenons donc pour les batch de 1 à 5 les dates au plus tôt 100, 100, 50, 40, 20. Enfin, nous affectons ces batch sur les machines par ordre croissant des dates au plus tôt. La figure 4.11 montre la solution finale.

Figure 4.11. Résolution de l’exemple illustratif avec l’algorithme split job

Après avoir trié les tâches à l’étape 1, les batch sont créés avec des tâches consécutives. N étant le nombre de tâches, si chaque tâche est coupée, dans le pire cas, nous avons besoin de 2N itérations pour placer ces tâches dans les batch. Alors, la complexité de la procédure de création de batch est 0(N). La complexité de split job dépend donc de l’étape de tri qui est 0(NlogN).

Théorème 5. Split job est optimal pour le problème :

P | p-batch, rj, pj=p, vj(split), B | Cmax.

Preuve. L’étape 2 de l’algorithme calcule la borne inférieure sur le nombre de

batch. La condition de fermer un batch est que, soit il est 100% plein, soit il n’y a plus de tâche dans la liste L. Cela implique que tous les batch sont pleins sauf, peut être, le dernier batch créé.

Maintenant, comme dans la preuve du théorème 4, considérons une chaîne de batch sans temps mort sur la machine contenant le dernier batch. Alors, la date au plus tôt du premier batch de cette chaîne est nécessairement égale à la date de

disponibilité d’une tâche, disons la tâche k. Puisque le reste des batch sont 100% plein, un nombre minimal de batch est créé après la tâche k. De plus, les batch sont affectés consécutivement sur les machines. Donc, le nombre de batch affectés après la tâche k sur la même machine est aussi minimal. Ainsi d’après le lemme 6, la valeur minimale du temps total d’exécution après la tâche k est

atteinte et donc le Cmax trouvé par split job est optimal. 4

Théorème 6. Split job fournit une borne inférieure pour le problème :

P | p-batch, rj, pj=p, vj, B | Cmax.

Preuve. La borne inférieure expliquée dans le lemme 6 est atteint avec

l’algorithme Split job. Ainsi, la solution trouvée est une borne inférieure. 4

4.4.2 Cas particulier où les tailles des tâches sont « fortement

Dans le document Optimisation du chargement des laveurs dans un service de stérilisation hospitalière : ordonnancement, simulation, couplage (Page 81-84)