Quelqu'un at-il essayé la mémoire transactionnelle pour C ++?

Question

Je vérifiais la solution "whatif" d'Intel. site et leur compilateur Transactional Memory (chaque thread doit effectuer des commits atomiques ou restaurer la mémoire du système, comme le ferait une base de données).

Cela semble être une manière prometteuse de remplacer les serrures et les mutex, mais je ne trouve pas beaucoup de témoignages. Est-ce que quelqu'un ici a des idées?

Answer 1

Je n’ai pas utilisé le compilateur d’Intel, cependant, Herb Sutter a fait quelques commentaires intéressants à ce sujet ...

De Sutter parle: L’avenir de la concurrence

Voyez-vous beaucoup d'intérêt et d'utilisation de la mémoire transactionnelle, ou le concept est-il trop difficile à comprendre pour la plupart des développeurs?

Il n’est pas encore possible de préciser qui l’utilise car il n’a pas encore été mis sur le marché. Intel possède un prototype de logiciel de compilateur de mémoire transactionnelle. Mais si la question est "Est-il trop difficile à utiliser pour les développeurs?" la réponse est que j'espère bien que non. Le problème est que c'est beaucoup plus facile que les serrures. C'est la seule chose importante à l'horizon de la recherche qui laisse espérer une réduction considérable de notre utilisation des serrures. Cela ne remplacera jamais complètement les serrures, mais c’est notre seul grand espoir de les remplacer partiellement.

Il y a quelques limitations. En particulier, certaines E / S sont intrinsèquement non transactionnelles - vous ne pouvez pas prendre un bloc atomique qui invite l'utilisateur à entrer son nom et le lire dans la console, puis simplement annuler et réessayer le bloc s'il entre en conflit avec une autre transaction; l'utilisateur peut faire la différence si vous le lui demandez deux fois. La mémoire transactionnelle est idéale pour les choses qui ne touchent que la mémoire, cependant.

Tous les principaux fournisseurs de matériel et de logiciels que je connais possèdent plusieurs outils de mémoire transactionnelle dans R & D. Il existe des conférences et des travaux académiques sur les réponses théoriques à des questions fondamentales. Nous ne sommes pas encore au stade de la Model T où nous pouvons l'expédier. Vous verrez probablement très tôt des prototypes limités pour lesquels vous ne pouvez pas utiliser de mémoire transactionnelle illimitée, où vous ne pouvez lire et écrire que, par exemple, 100 emplacements de mémoire. Cela reste néanmoins très utile pour activer davantage d’algorithmes sans verrouillage.

Answer 2

Dr. L'année dernière, Dobb avait publié un article sur ce concept: Programmation transactionnelle de Calum Grant - http: //www.ddj .com / cpp / 202802978

Il comprend des exemples, des comparaisons et des conclusions utilisant son exemple de bibliothèque.

Answer 3

J'ai construit la bibliothèque combinatoire STM en plus de certaines idées de programmation fonctionnelles. Il ne nécessite aucun support du compilateur (sauf qu'il utilise C ++ 17), n'apporte pas de nouvelle syntaxe. En général, il adopte l'interface de la bibliothèque STM de Haskell.

Ma bibliothèque a donc plusieurs propriétés intéressantes:

• Monadiquement combinatoire. Chaque transaction est un calcul dans la monade personnalisée nommée STML . Vous pouvez combiner des transactions monadiques en plusieurs grandes transactions monadiques.
• Les transactions sont séparées du modèle de données. Vous construisez votre modèle de données simultané avec des variables transactionnelles ( TVars ) et exécutez des transactions dessus.
• Il existe un combinateur réessayer . Cela vous permet de relancer la transaction. Très utile pour construire des transactions courtes et compréhensibles.
• Il existe différents combinateurs monadiques pour exprimer rapidement les calculs.
• Il y a Context . Chaque calcul doit être exécuté dans un contexte donné, pas dans le runtime global. Vous pouvez donc avoir de nombreux contextes différents si vous avez besoin de plusieurs clusters STM indépendants.
• La mise en œuvre est assez simple sur le plan conceptuel. Au moins, l'implémentation de référence dans Haskell l'est, mais j'ai dû réinventer plusieurs approches pour C ++. mise en œuvre en raison de l’absence d’un bon support de la programmation fonctionnelle.

La bibliothèque présente une très bonne stabilité et robustesse, même si nous la considérons comme expérimentale. De plus, mon approche ouvre de nombreuses possibilités pour améliorer la bibliothèque en termes de performances, fonctionnalités, exhaustivité, etc.

Pour illustrer son travail, j'ai résolu la tâche Dining Philosophers . Vous pouvez trouver le code dans les liens ci-dessous. Exemple de transaction:

STML<bool> takeFork(const TVar<Fork>& tFork)
{
    STML<bool> alreadyTaken = withTVar(tFork, isForkTaken);
    STML<Unit> takenByUs    = modifyTVar(tFork, setForkTaken);
    STML<bool> success      = sequence(takenByUs, pure(true));
    STML<bool> fail         = pure(false);
    STML<bool> result       = ifThenElse(alreadyTaken, fail, success);
    return result;
};

MISE À JOUR J'ai écrit un didacticiel, vous pouvez le trouver ici .

• tâche Restauration des philosophes
• Ma bibliothèque C ++ STM

Answer 4

Sun Microsystems a annoncé la sortie d’un nouveau processeur l’année prochaine, nommé Rock, qui prend en charge le matériel pour la mémoire transactionnelle. Cela aura quelques limites, mais c’est une bonne première étape qui devrait permettre aux programmeurs de remplacer plus facilement les verrous / mutex par des transactions et , qui en attendent de bonnes performances.

Pour une conversation intéressante sur le sujet, donnée par Mark Moir, l'un des chercheurs de Sun travaillant sur Rock Transactional and Rock, consultez cette page link .

La entrée wikipedia obligatoire:

Enfin, ce lien , à l'Université de Wisconsin-Madison contient une bibliographie de la plupart des recherches qui ont été et sont effectuées sur la mémoire transactionnelle, qu’il soit lié au matériel ou au logiciel.

Answer 5

Dans certains cas, cela peut être utile et même nécessaire.

Toutefois, même si le processeur dispose d'instructions spéciales facilitant ce processus, le temps système qui y est consacré est considérable, comparé à un mutex ou à un sémaphore. Selon son implémentation, cela peut également avoir un impact sur les performances en temps réel (il faut soit arrêter les interruptions, soit les empêcher d'écrire dans vos zones partagées).

Je pense que si cela était implémenté, il ne serait toutefois nécessaire que pour des parties d'un espace mémoire donné, de sorte que l'impact pourrait être limité.

-Adam