J'y connais pas grand chose, mais peut-être est-ce livré pour être utilisé dans des cadres contrôlés, hors navigateur "pur" donc, quand l'utilisation du HTML est "cachée" par un client spécifique. (Exemple: le client Steam, il me semble)
En gros tu fait de la mémoire transactionnel sur une variable.
Ce qui existe déjà depuis des décennies et est conceptuellement mille fois plus simple (et plus propre à mon humble avis) que de la mémoire transactionnelle sur tout un pan de code.
Dont on parle aujourd'hui.
Bon exemple en effet. Présenté comme ça, ce n'est pas très engageant.
Et plus généralement, même si je suis prêt à admettre que la MT a de grands avantages dans certains cas que je ne connais pas, je n'aime pas trop la philosophie derrière : "C'est bon vous pouvez tout partager maintenant, on se charge du reste".
Je préfère un esprit fonctionnel ("On ne partage rien. Chaque thread a ses ressources. Le peu qui est partagé est protégé.") que j'essaie d'appliquer le plus rigoureusement possible.
Dans l'exemple bancaire de l'article, je dirais qu'un seul thread doit être responsable de la mise à jour de la valeur et que les deux threads mentionnés ne font que produire un delta à appliquer qu'ils lui communiquent au moyen d'une structure atomique (fifo).
Il y a des notions de property bindings dans EFL ?
M'intéressant depuis un moment à la librarie Adam dans les ASL, j'avais découvert cet aspect de QML avec un certain intérêt.
[^] # Re: Please fill out this field
Posté par Ivan Le Lann . En réponse à la dépêche Appel pour le web ouvert !. Évalué à -1.
J'y connais pas grand chose, mais peut-être est-ce livré pour être utilisé dans des cadres contrôlés, hors navigateur "pur" donc, quand l'utilisation du HTML est "cachée" par un client spécifique. (Exemple: le client Steam, il me semble)
# Harman Kardon HD970
Posté par Ivan Le Lann . En réponse au sondage Quel est votre lecteur audio ?. Évalué à -2.
Et oui !
[^] # Re: Et si un thread se fait toujours voler l'accès mémoire ?
Posté par Ivan Le Lann . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à -1.
Ce qui existe déjà depuis des décennies et est conceptuellement mille fois plus simple (et plus propre à mon humble avis) que de la mémoire transactionnelle sur tout un pan de code.
Dont on parle aujourd'hui.
[^] # Re: Recouvrement
Posté par Ivan Le Lann . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à 3.
"*val -= debit" est du sucre syntaxique pour "*val = *val - debit"
Donc si, on lit la variable.
[^] # Re: Et si un thread se fait toujours voler l'accès mémoire ?
Posté par Ivan Le Lann . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à 1.
Un exemple : http://tim.klingt.org/boost_lockfree/
Un autre : concurrent_queue chez Intel TBB.
Pas de mutex ou autres trucs bloquants, uniquement des instructions atomiques genre CAS.
Donc non, je ne pense pas "déplacer" pas le problème.
NB:
Je ne dis pas non plus qu'il faut mettre des instructions atomiques partout.
Comme dit avant, moins on partage, mieux on se porte.
[^] # Re: Et si un thread se fait toujours voler l'accès mémoire ?
Posté par Ivan Le Lann . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à 2.
Bon exemple en effet. Présenté comme ça, ce n'est pas très engageant.
Et plus généralement, même si je suis prêt à admettre que la MT a de grands avantages dans certains cas que je ne connais pas, je n'aime pas trop la philosophie derrière : "C'est bon vous pouvez tout partager maintenant, on se charge du reste".
Je préfère un esprit fonctionnel ("On ne partage rien. Chaque thread a ses ressources. Le peu qui est partagé est protégé.") que j'essaie d'appliquer le plus rigoureusement possible.
Dans l'exemple bancaire de l'article, je dirais qu'un seul thread doit être responsable de la mise à jour de la valeur et que les deux threads mentionnés ne font que produire un delta à appliquer qu'ils lui communiquent au moyen d'une structure atomique (fifo).
# Et premake ???
Posté par Ivan Le Lann . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 3.
Je tiens à citer premake que je trouve d'une grande simplicité.
[^] # Re: des possibilités graphiques hors du commun.
Posté par Ivan Le Lann . En réponse à la dépêche Conférence Parinux : les Enlightenment Foundation Libraries (EFL). Évalué à 2.
Il y a des notions de property bindings dans EFL ?
M'intéressant depuis un moment à la librarie Adam dans les ASL, j'avais découvert cet aspect de QML avec un certain intérêt.
[^] # Re: C++0x?
Posté par Ivan Le Lann . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 2.
Boost.Log a été accepté, mais n'est pas encore intégré. Ca fait un an déjà ... Faut juste le récupérer à part et bidouiller un peu pour le builder.
[^] # Re: Boost vs Qt
Posté par Ivan Le Lann . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 1.
Boost.Signals2 plutôt. Je pense que la précision n'est pas trop, car les deux versions cohabitent dans Boost.