Changes between Version 2 and Version 3 of SoftWare/SignalCheckpoint/OAR


Ignore:
Timestamp:
Oct 15, 2012, 11:09:55 AM (12 years ago)
Author:
g7moreau
Comment:

Asynchrone case

Legend:

Unmodified
Added
Removed
Modified
  • SoftWare/SignalCheckpoint/OAR

    v2 v3  
    2929A lui de les gérer.
    3030
     31On remarque donc sur cet exemple que le script de soumission
     32n'a donc pas à gérer les signaux.
     33L'optimisation via {{{exec}}} permet en plus de récupérer un peu de mémoire vive pour le code !
     34
    3135{{{
    3236#!/bin/bash
     
    4953exec ./mycode
    5054}}}
     55
     56
     57== Cas asynchrone - avec post-traitement ==
     58
     59Il y a de nombreux cas ou le script de soumission doit reprendre la main après l'exécution du code de calcul.
     60Cependant, il faut savoir que le shell ne gère les signaux qu'entre deux instructions,
     61ou lors d'instruction bloquante interne au shell (par exemple {{{wait}}}).
     62
     63L'exemple suivant par exemple ne fonctionne pas
     64car le script exécutera le code dans {{{trap}}} qu'une fois le code {{{mycode}}} finit,
     65donc en pratique jamais car le code dure plus de 24h.
     66Au final, au bout de 24, {{{OAR}}} fera un {{{kill}}} violent du code...
     67{{{
     68#!/bin/bash
     69
     70#OAR -n MYCODE
     71#OAR -t idempotent
     72#OAR --checkpoint 600
     73#OAR -l /core=1,walltime=24:00:00
     74
     75# Signal child retransmit
     76trap 'kill -USR2 $(jobs -p)' USR2
     77
     78
     79# Load environment
     80. /etc/profile
     81
     82module load intel/2011.7
     83
     84
     85# Pretreatment possible here
     86
     87
     88# Start / give the hand to the code
     89./mycode
     90
     91
     92# Post-treatment possible here
     93
     94}}}
     95
     96Une solution est de lancer le code en asynchrone
     97afin que le script de soumission reprenne le plus vite possible la main.
     98Cependant, il doit quand même attendre la fin du code avant de faire l'étape de post-traitement.
     99Voici une solution fonctionnelle à ces impératifs
     100
     101{{{
     102#!/bin/bash
     103
     104#OAR -n MYCODE
     105#OAR -t idempotent
     106#OAR --checkpoint 600
     107#OAR -l /core=1,walltime=24:00:00
     108
     109# Signal child retransmit
     110trap 'kill -USR2 $(jobs -p)' USR2
     111
     112
     113# Load environment
     114. /etc/profile
     115
     116module load intel/2011.7
     117
     118
     119# Pretreatment possible here
     120
     121
     122# Launch the code and take back the hand (asynchrone)
     123./mycode &
     124
     125# Wait for the end of the code
     126while [ $(jobs -p | wc -l) -gt 0 ]
     127do
     128   wait
     129done
     130
     131# Post-treatment possible here
     132
     133}}}
     134
     135La boucle while est très importante
     136car le code peux finir suite à la réception d'un signal
     137mais aussi naturellement lorsqu'il a enfin finit son traitement global.
     138Les deux cas doivent être géré.
     139Or la commande interne '''{{{wait}}}''' attends la '''fin du calcul'''
     140ou la '''réception d'un signal'''.
     141
     142Une fois le signal reçu, la commande {{{trap}}} retransmet le signal au code,
     143et le script de soumission repars dans la boucle {{{while}}}
     144afin d'attendre la fin réelle du code.
     145Sans cette boucle,
     146il passerait de suite sur la phase de post-traitement
     147et se terminerait en laissant {{{OAR}}} tuer sauvagement le code dans sa phase terminale...