Discussion :

[transgohan]

Bonjour à toutes et à tous,

je travaille actuellement sur différents portage d'application multicoeurs.
L'application se veut de philosophie POSIX pour un portage cohérent.
Cependant, la norme POSIX ne concerne pas la programmation multicoeur et aucune gestion de l'affinité CPU n'est prévue.

Pire encore cette gestion diffère d'un système linux à un autre...
Exemples :

int sched_setaffinity(pid_t pid, unsigned int len, unsigned long *mask);
int sched_setaffinity (pid_t __pid, size_t __cpusetsize, const cpu_set_t *__cpuset);
int sched_setaffinity (pid_t __pid, const cpu_set_t *__mask);

Après quelques recherches je suis tombé sur un projet de l'équipe d'Open-MPI qui développe une librairie pour rendre portable cette gestion de l'affinité : http://www.open-mpi.org/projects/hwloc/
Elle est même portable sur windows.
Mais elle ne gère pas VxWorks, un groupe d'utilisateurs parlaient de le porter mais il semble au vu des derniers messages en date qui remontent que cela soit un projet abandonné. Et vu les échanges c'est une charge de travail très conséquente donc je ne vais pas m'y risquer (j'entends par là que j'ai pas 6 mois devant moi pour ça...).

Auriez-vous entendu parlé d'une autre librairie pouvant répondre à mes besoins ?

En parallèle de mes recherches je réfléchi à une transformation de mes threads unix en task vxworks en impactant le minimum de choses mais ce n'est pas aisé...

[Emmanuel Deloget]

Bonjour à toutes et à tous,

je travaille actuellement sur différents portage d'application multicoeurs.
L'application se veut de philosophie POSIX pour un portage cohérent.
Cependant, la norme POSIX ne concerne pas la programmation multicoeur et aucune gestion de l'affinité CPU n'est prévue.

Pire encore cette gestion diffère d'un système linux à un autre...
Exemples :

Après quelques recherches je suis tombé sur un projet de l'équipe d'Open-MPI qui développe une librairie pour rendre portable cette gestion de l'affinité : http://www.open-mpi.org/projects/hwloc/
Elle est même portable sur windows.
Mais elle ne gère pas VxWorks, un groupe d'utilisateurs parlaient de le porter mais il semble au vu des derniers messages en date qui remontent que cela soit un projet abandonné. Et vu les échanges c'est une charge de travail très conséquente donc je ne vais pas m'y risquer (j'entends par là que j'ai pas 6 mois devant moi pour ça...).

Auriez-vous entendu parlé d'une autre librairie pouvant répondre à mes besoins ?

En parallèle de mes recherches je réfléchi à une transformation de mes threads unix en task vxworks en impactant le minimum de choses mais ce n'est pas aisé...

Ce n'est peut-être pas défini dans POSIX 2001, mais SUSV4 (=POSIX-1.2008)
définit des fonctions dans <sched.h>. Cf. http://pubs.opengroup.org/onlinepubs...s/sched.h.html

[transgohan]

Oui mais malheureusement cette norme n'est suivi que par les linux.
Donc byebye VxWorks.
A l'heure actuelle je n'ai toujours trouvé aucune solution englobant tous les unix.

[Emmanuel Deloget]

Oui mais malheureusement cette norme n'est suivi que par les linux.
Donc byebye VxWorks.
A l'heure actuelle je n'ai toujours trouvé aucune solution englobant tous les unix.

VxWorks n'étant pas un Unix, et les Unix autres que Linux étant sérieusement à la traîne (à part quelques exemples particuliers, comme Solaris, qui est juste un peu à la traine, et les *BSD, qui sont de toute façon vaguement dans les choux (ça n'engage que moi)), je ne m'étonne pas trop.

Le fait que VxWorks n'arrive pas en 2012 à implémenter un standard datant de 2008 ne me choque pas non plus outre mesure. Le site web assure un support complet de IEEE Std. 1003.1 (POSIX) mais sans donner d'information supplémentaire (il faudrait qu'ils supportent IEEE 1003.1-2008, ce qui n'est visiblement pas le cas).

Deux solutions :

1/ taper sur la tête de WindRiver pour qu'ils mettent à jour leur support POSIX
2/ prévoir une couche de compatibilité

Je ne vois pas comment tu peux faire autrement. Il y a 0 chances pour que tu sois à la fois compatible POSIX et compatible non POSIX sans avoir de code spécifique traitant de l'un des deux cas.

Pour rappel, le rajout d'une couche de compatibilité est le scénario privilégié par la plupart des programmes Open Source ayant besoin de supporter de nombreux Unix. C'est même la base de l'idée derrière autocomf/automake : permettre la détection des features d'un système afin d'adapter le logiciel compilé au besoin spécifique de la cible.

[transgohan]

Ah mais on est bien d'accord...
Je n'ai pas demandé une solution POSIX vu que j'ai moi même indiqué qu'il n'y en avait pas et ce dès mon premier message...

La couche de compatibilité j'y pense depuis le début, mais c'est pas facile à organiser.
On fonctionne avec des pthreads, or il n'y a du coup rien permettant de gérer leur affinité. Faut que je teste à coup de taskCpuAffinitySet(0, affinity) mais j'y crois pas trop...
Donc cela voudrai dire un portage total vers des tasks... Et là c'est pas un petit boulot.
Pas eu le temps de faire des tests en raison d'un déménagement de nos locaux, j'attends encore que le laboratoire soit utilisable.

[transgohan]

J'ai lancé quelques tests et il semblerait que taskCpuSetAffinity() puisse agir sur les pthreads.
J'ai encore des tests à faire sur une carte multicoeur car je ne fais que spéculer sur un test monocoeur, en effet sous VxWorks si on ne gère pas l'affinité la tâche n'est pas associée à un CPU en particulier contrairement à un système linux qui associe tous les CPUs. Or mon test me renvoie qu'avant un setaffinity mon pthread n'a aucune affinité, puis après m'indique une affinité avec le CPU 0.