[gull] Python et semaphores

[Daniel Cordey]

On Thu, 12 Aug 2010 18:09:16 +0200 - Philippe Strauss
<philou at philou.ch> wrote:

> J'ai un questionnement similaire avec ocaml, et j'ai fini par faire
> ces parties sensibles (sur mon projet) au niveau perf (et soft real
> time) en C pure et simple.

Oui, c'est aussi ce que je fais pour les parties de calculs intensifs
en 'double'. Mais j'evite aussi de creer des modules C car il faut
toujours les compiler pour la bonen version de python/gcc... La
logistique devient vite plus lourde avec le temps (release heterogenes,
etc.)

> A voire si le côté confidentiel du module SYSV en python correspond
> pas au fait que ce genre de prog. système relativement bas niveau ne
> match pas bien au niveau de python (les pointeurs dans les SHM p.ex,
> comment les représenter en python?)

Ce n'est pas un trop gros probleme car il existe tout les outils pour
faire ce que tu veux. Soit tu fait des objets Python en C, et il te
faut gerer les "reference_count", soit tu stokes un index en Python,
correspondant a un elements d'un tableau de pointeur en C, que tu
passes a chaque fois que tu appelles une fonction dans ton module C.
L'echange Python <-> C est relativement aise... a condition de ne pas
manipuler plusieurs niveaux de structures avec des pointeurs alloues
dynamiquement... Dans ce cas, il faut s'assoir et reflechir
treeeeeeeeeeees calmement... j'ai passe par la :-)

Apres une petite campagne de tests et d'analyse de performances de
differentes methodologies et fonctions, j'en suis arrive a relativiser
grandement cette notion de performance extreme avec des semaphores SYSV
ou POSIX... L'exercice etant quand meme un peu lourd, j'ai aussi
envisage d'utiliser des 'locks' sur des fichiers plutot qu'avec des
semaphores classiques. L'inconvenient ds semaphores SYSV est lie a
toutes les phases transitoires par lesquelles passent un semaphore et
les process y accedant. La partie delicate estla creation du/des
semaphores et le "nettoyage" des valeurs des semaphores apres la
terminaison d'un process de maniere "abrupte". Franchement, j'ai
toujours trouve ca un peu "penible". Le probleme etait exactement le
meme avec les shared-memory ! Pour eviter ceci, j'ai passe a
l'utilisation des memory-mapped-files... en conjonction avec
fcntl.lockf()... Ca simplifie grandement la vie car la gestion des
'locks' bloques est geree lors de la disparition d'un process bloquant;
puisque le file-system s'en occupe ! En plus, je viens de me rendre
compte qu'un lockf() ne me prend que ~800 nanoseconds sur ma machine
avec un processeur a 2.9 GHz (core i3)... 

EN conclusion, je ne vais pas m'enquiquiner a developper un module
semaphores SYSV, mais plutot utiliser betement des lockf() comme
semaphores, puisque les performances ne sont pas si couteuses que ca :-)

Merci a Francois et toi pour vos conseils.

dc

>