Ingénierie et formations sur les systèmes libres
Le site RTwiki, victime collatérale de l’attaque d’août dernier sur Kernel.org, a longtemps été désactivé. Le voici de retour depuis quelques heures.
Comme d’habitude on y trouve de nombreuses informations sur le projet Linux-rt qui visiblement suit au plus près les évolutions du noyau standard (version 3.2-rc1 en l’occurrence).
Les patches de Thomas Gleixner vont progressivement regagner leur répertoire d’origine, toutefois, les plus récents se trouvent encore sur son site personnel.
Après Dennis Ritchie il y a quelques jours, c’est John McCarthy qui nous a quitté hier.
Il s’agissait d’un pionnier de l’Intelligence Artificielle (dont il a inventé le nom), créateur de nombreux concepts-clés de l’informatique système (garbage collector, temps-partagé, etc.) et l’IA (élagage alpha-béta, etc.).
Lire la suite de cette entrée »
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 ?
Une triste nouvelle, une disparition : Dennis Ritchie s’est éteint le week-end dernier à l’âge de 70 ans.
On lui doit entre autres le langage C et le système Unix.
On trouve diverses photos de lui sur le Web, celles que je préfère sont les deux suivantes, où il se trouve en compagnie de son collègue Ken Thompson (assis) devant un PDP-11 probablement en train de hacker les premières versions d’Unix.
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.
Entre un album de la B.D. The Walking Dead et le dernier roman d’Umberto Ecco (le cimetière de Prague), j’ai relu récemment avec grand plaisir un petit livre très intéressant :
The Practice of Programming de Brian W. Kernighan et Rob Pike.
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.
