Journal
Ce journal contient 7 entrées.
Brixo - Building Blocks Meet Electricity and IoT
Encore un kickstarter intéressant dans le contexte de l'Internet des Objets : des sortes de légos connectés, embarquant des capteurs, des interfaces de communication ou simplement des connecteurs.

China just blocked thousands of websites | GreatFire.org - Liens en vrac de sebsauvage
Eh oui, il ne faut pas oublier que le cloud est avant tout un système décentralisé à très grande échelle, conçu pour être élastique et résilient. Seuls la gestion et l'accès sont centralisés et c'est le plus souvent cette idée d'accès centralisé qui est critiquée car sujette à la censure/surveillance de la part de l'opérateur de cloud.
La Chine a fait ici un choix étrange, consistant à censurer l'opérateur entier, alors que celui-ci est en principe soumis aux lois du pays (et donc à une censure au cas par cas).
La Chine a fait ici un choix étrange, consistant à censurer l'opérateur entier, alors que celui-ci est en principe soumis aux lois du pays (et donc à une censure au cas par cas).
An Introduction to Lock-Free Programming
Encore un article qui revient sur des concepts de programmation concurrente sans verrou (lock-free programming).
Histoire de compléter ceux que j'ai déjà mentionné :)
http://benjaminbillet.fr/news/index.php?keywords=lock

Histoire de compléter ceux que j'ai déjà mentionné :)
http://benjaminbillet.fr/news/index.php?keywords=lock
Why Johnny Can’t Write Multithreaded Programs
Je n'aime pas le ton de l'article, et encore moins la phrase "If you used a lock, you probably did something wrong" qui est tout simplement idiote, mais par contre je rejoins l'auteur sur les points suivants :
- utilisez les abstractions fournies par les langages pour gérer la concurrence (pools, queues, workers, etc.).
- utilisez la programmation asynchrone si cela peut éviter d'utiliser des threads.
- efforcez vous de maintenir des threads parfaitement indépendants, qui ne communiquent qu'au travers de queues synchronisées (voir aussi le problème du producteur/consommateur et sa résolution à base de sémaphores http://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem).
- ne créez pas d'états globaux, sauf si cela est absolument nécessaire.
- faîtes appel à des librairies puissantes pour gérer la concurrence simplement (ex : OpenMP).

- utilisez les abstractions fournies par les langages pour gérer la concurrence (pools, queues, workers, etc.).
- utilisez la programmation asynchrone si cela peut éviter d'utiliser des threads.
- efforcez vous de maintenir des threads parfaitement indépendants, qui ne communiquent qu'au travers de queues synchronisées (voir aussi le problème du producteur/consommateur et sa résolution à base de sémaphores http://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem).
- ne créez pas d'états globaux, sauf si cela est absolument nécessaire.
- faîtes appel à des librairies puissantes pour gérer la concurrence simplement (ex : OpenMP).
High Level Concurrency Objects
En référence à http://benjaminbillet.fr/news/index.php?link=d5gw5, il semble aussi que les nouvelles API de programmation concurrente soient en général méconnue des développeurs Java formés il y a quelques années.
Java a introduit, toujours depuis Java 5, des structures pour simplifier la gestion de la concurrence dans une application.
La documentation d'Oracle est très claire sur le sujet :
- Les pools automatiques : http://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html
- Le framework Fork/Join : http://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html
- Les collections concurrentes : http://docs.oracle.com/javase/tutorial/essential/concurrency/collections.html
- Et de véritables verrous : http://docs.oracle.com/javase/tutorial/essential/concurrency/newlocks.html
Java a introduit, toujours depuis Java 5, des structures pour simplifier la gestion de la concurrence dans une application.
La documentation d'Oracle est très claire sur le sujet :
- Les pools automatiques : http://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html
- Le framework Fork/Join : http://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html
- Les collections concurrentes : http://docs.oracle.com/javase/tutorial/essential/concurrency/collections.html
- Et de véritables verrous : http://docs.oracle.com/javase/tutorial/essential/concurrency/newlocks.html
The Balancing Act of Choosing Nonblocking Features - ACM Queue
Je vous ai déjà rapidement parlé de l'avantage des algorithmes sans verrous (lock-free) : http://benjaminbillet.fr/news/index.php?link=d5gw1q
Cet article revient en détails sur les différentes techniques et sur la difficulté de choisir des algorithmes et des structures de données lock-free pour un contexte donné.
Une sauvegarde de l'article en PDF ici :
http://benjaminbillet.fr/media/balancing-act-choosing-nonblocking-features.pdf

Cet article revient en détails sur les différentes techniques et sur la difficulté de choisir des algorithmes et des structures de données lock-free pour un contexte donné.
Une sauvegarde de l'article en PDF ici :
http://benjaminbillet.fr/media/balancing-act-choosing-nonblocking-features.pdf
Lockfree Algorithms
En général, limiter le nombre de verrous dans un programme multithread est une bonne pratique, pour deux raisons :
1. cela réduit le nombre d'erreurs imprévues (interblocage, verrous inutiles, etc.).
2. cela augmente la cohérence du programme (grosso modo, pourquoi faire des threads si c'est pour ensuite mettre des verrous partout).
Aussi, rien de mieux que les algorithmes sans synchronisation.
1. cela réduit le nombre d'erreurs imprévues (interblocage, verrous inutiles, etc.).
2. cela augmente la cohérence du programme (grosso modo, pourquoi faire des threads si c'est pour ensuite mettre des verrous partout).
Aussi, rien de mieux que les algorithmes sans synchronisation.
Ce journal est basé sur Ginger, un gestionnaire de lien minimaliste développé dans le cadre d'un stage de perfectionnement. Pour plus d'informations, consulter le wiki consacré à mes projets personnels.