Ingénierie et formations sur les systèmes libres
(Version originale en français)
Linus Torvalds released the Linux 3.2 kernel two days ago. As usual, it contains many additions and improvements. One of them caught my attention and I wanted to see how it works, it is the controller for the CFS CPU scheduler.
J’ai voulu comparer certains résultats obtenus avec Xenomai sur une carte Pandaboard avec ceux d’un PC classique. J’ai choisi un poste de travail (type bureautique) fonctionnant avec une distribution Ubuntu récente, afin de disposer d’une configuration la plus courante possible.
On m’a souvent demandé durant des sessions de formations des bibliographies ou des conseils de lecture sur certains sujets. J’ai décidé de mentionner ici quelques ouvrages qui me semblent particulièrement judicieux pour étudier ou approfondir des domaines liés à la programmation, aux systèmes Unix et Linux, ou aux environnements temps-réel et embarqués.
Cette bibliographie est incomplète. Je ne me suis occupé que de la première étagère de ma bibliothèque. Je la complèterai prochainement…
Cet article est extrait de la version préparatoire de mon livre à venir « Solutions temps-réel sous Linux« . Le sujet m’en a été inspiré par des expériences réalisées lors d’une récente session de formation (merci entre autres à Alejandro, Manuel et Sebastien pour m’avoir encouragé et aidé à explorer ce sujet).
Lorsqu’une application multi-tâches utilise des ressources partagées, il est généralement nécessaire d’utiliser des mécanismes de synchronisation afin d’éviter les problèmes de concurrence d’accès. Dans le cas d’un programme multi-threads on utilisera des mutex Posix. Une question peut se poser quand plusieurs threads sont en attente pour tenter de prendre un mutex alors que ce dernier est verrouillé : qui va l’obtenir lorsqu’il sera libéré par son actuel détenteur ?
La méthode de communication entre processus la plus performante lorsqu’on doit transférer des données volumineuses est l’emploi de zones de mémoires partagées. Standardisé par Posix, il s’agit d’un mécanisme extrémement efficace. Toutefois, il faut penser à synchroniser les accès, afin d’éviter les modifications concurrentes des données partagées ou la modification d’une zone pendant sa consultation par un autre processus.
Lire la suite de cette entrée »
Tout est dans le titre… Le site kernel.org, victime d’une attaque fin août, était inaccessible depuis près d’un mois.
Il est à nouveau actif partiellement, même si un certain nombre de fonctionnalités sensibles (accès SSH par exemple) ont été désactivées pour un moment encore. De même les archives des noyaux (même les liens proposés en première page) ne sont pas disponibles pour l’instant.
N’oublions pas que d’autres projets (Linux-RT par exemple) sont centralisés aussi sur ce serveur, et que nous sommes nombreux à espérer son retour prochain.
Nous avions examiné dans l’article précédent de cette série un premier mécanisme de communication entre processus : les files de messages Posix. Nous avions observé qu’il était facile de transmettre un message de quelques kilo-octets entre deux processus, en un temps allant de 8 microsecondes si le processeur était déjà actif à 15 microsecondes si les messages étaient suffisament espacés pour laisser au processeur le temps de s’endormir et de prendre un temps de réveil non négligeable.
Nous allons à présent observer les possibilités liées aux signaux temps-réel Posix.1b.
Un client m’a demandé récemment de le conseiller sur le choix d’un mécanisme de communication entre processus pour transférer rapidement des données entre deux applications. Il existe plusieurs systèmes d’IPC (Inter Process Communication), chacun avec ses avantages et inconvénients, et j’ai eu envie de les comparer pour déterminer le plus rapide, en fonction du type de données à transférer. Ce premier article est consacré aux message queues, les files de messages.
