Fonctionnalit´es des syst`emes TM

Si les cat´egories pr´esent´ees au-dessus d´efinissent la politique principale d’un syst`eme

donn´e, elles ne pr´ecisent pas les fonctionnalit´es support´ees ou non par les syst`emes, ou

encore certaines sp´ecificit´es de conception visant la simplification ou l’optimisation du

syst`eme. Nous pr´esentons dans cette section les particularit´es ou fonctionnalit´es majeures

des syst`emes HTM.

5.4.1 Transactions born´ees et non-born´ees

Si les syst`emes classiques supportent en g´en´eral les transactions qui d´ebordent du cache,

voire qui acc`edent un tr`es grand nombre d’emplacements m´emoire, ils ne supportent pas

les transactions dites non-born´ees. Cette terminologie, un peu ambig ¨ue, vient du fait que

les syst`emes HTMs sont en g´en´eral conc¸us pour les CMPs. Dans ce cadre, il est de mise

que le syst`eme d’exploitation d´ecide de changer le thread qui s’ex´ecute sur un cœur, ou

d´ecide encore de d´eplacer une page contenant des donn´ees transactionnelles en m´emoire

(swap). Ainsi, ce terme d´enote le fait qu’une transaction dans un syst`eme puisse supporter

un changement de contexte ou le fait d’ˆetre d´eplac´e sur le disque dur. Pour pouvoir

sup-porter cela, les transactions requi`erent entre autres d’ˆetre virtualis´ees afin que leur ´etat

puisse ˆetre sauvegard´e en m´emoire.

Ainsi, une distinction est faite entre les syst`emes qui supportent la virtualisation des

transactions et les autres.

5.4.2 Utilisation de signatures

Souvent, les syst`emes TM sont oblig´es de faire une approximation des emplacements

m´emoire acc´ed´es durant une transaction quand ces derni`eres d´ebordent du cache. Une

tech-nique utilis´ee consiste ainsi `a utiliser un bit de d´ebordement par cache et `a signaler un

con-flit d`es qu’une transaction s’ex´ecutant sur le processeur correspondant rec¸oit une requˆete

de coh´erence. Cela r´esulte en de nombreux cas de faux conflits. Pour ´eviter ce probl`eme

et mieux g´erer les grandes transactions, [CTTC06] a introduit l’id´ee d’utiliser des signatures

mat´erielles pour repr´esenter les ensembles d’adresses lues et ´ecrites. Les signatures donnent

une sur-approximation de ces ensembles, qui peuvent mener `a des faux positifs, mais pas

`a des faux n´egatifs – c’est-`a-dire qu’il est possible qu’une transaction aborte inutilement,

mais pas l’inverse. N´eanmoins, pour les petites transactions ne d´ebordant pas du caches,

les risques de faux positifs sont tr`es faibles, et pour les grandes transactions, ils sont moins

´elev´es qu’avec une autre strat´egie si les signatures sont bien choisies, et leur taille

suffisam-ment grande.

Le cout de cette solution est qu’elle n´ecessite l’implantation mat´erielle du calcul des

signatures, ainsi que de plusieurs op´erations pour l’insertion, la recherche d’un ´el´ement

ou l’intersection de deux signatures. Une fac¸on de proc´eder est d’utiliser des filtres de

5.4 Fonctionnalit´es des syst`emes TM

Enfin, la compatibilit´e de cette solution est meilleure avec une d´etection des conflits

pr´ecoce, car la coupler avec une solution paresseuse n´ecessite de diffuser les signatures de

la transaction qui commite `a tous les processeurs.

5.4.3 Entrelacement de transactions

Un des principaux avantages des m´emoires transactionnelles est qu’elles apportent un

mod`ele de programmation modulaire. Cela n’est pas le cas avec des verrous : afin de garantir

l’absence d’´etreintes mortelles, les programmeurs ont souvent besoin de savoir quels sont les

verrous acc´ed´es par les fonctions appel´ees et les fonctions appelant le module. Ce probl`eme

ne se pose pas avec les transactions, mais il en r´esulte que plusieurs transactions peuvent

ˆetre entrelac´ees. Ainsi se pose le probl`eme de la s´emantique de l’entrelacement.

begin transaction() ;

begin transaction() ;

x = x + 1 ;

end transaction() ;

...

begin transaction() ;

a = x + a ;

b = b + 1 ;

end transaction() ;

end transaction() ;

FIG. 5.1 – Exemple d’entrelacement de plusieurs transactions

La figure5.1illustre ce point sur un exemple : que se passe-t-il si la deuxi`eme transaction

interne entre en conflit et doit aborter, alors que n´ecessairement la premi`ere transaction

in-terne a d´ej`a termin´e sa phase de commit ? Trois s´emantiques existent pour r´epondre `a cette

question : la s´emantique `a plat, la s´emantique ferm´ee et la s´emantique ouverte [MBM+

06b].

5.4.3.1 La s´emantique `a plat

La s´emantique `a plat consiste `a ne consid´erer que la transaction la plus externe, et `a

ignorer les transactions internes. D’un point de vue r´ealisation, cette solution est de loin la

plus simple, car un registre suffit pour garder le compte du niveau d’entrelacement. Ainsi,

dans le cas de l’exemple donn´e, un abort ayant lieu dans la deuxi`eme transaction la plus

interne aura pour cons´equence de faire recommencer la transaction la plus externe.

L’inconv´enient de cette solution est qu’elle peut mener `a un gˆachis de travail. En effet,

si une transaction interne courte entre en conflit et doit aborter, alors que ce conflit ne porte

que sur les variables propres `a cette transaction, la transaction la plus externe –

possible-ment longue – va aborter et recommencer alors qu’il suffirait de faire recommencer cette

transaction interne.

5.4.3.2 La s´emantique ferm´ee

La s´emantique ferm´ee vise `a corriger le probl`eme pos´e par la s´emantique `a plat. Pour

chaque transaction sont enregistr´ees les emplacements m´emoire lus et ´ecrits. Il est ainsi

possible lors d’un abort d’aborter la transaction conflictuelle la plus interne : il faut pour

Chapitre 5 ´Etat de l’art sur les m´emoires transactionnelles

cela partir de la transaction ayant lev´e le conflit et remonter la hi´erarchie des transactions

en v´erifiant `a chaque ´etape si la transaction actuelle est toujours en conflit. Dans le cas de

l’exemple, si la deuxi`eme transaction interne a un conflit sur la variableb(et que cette

vari-able n’est pas acc´ed´ee en dehors de cette transaction particuli`ere), seule cette transaction va

aborter et recommencer.

La contrepartie de cette solution est qu’il faut r´epliquer tous les m´ecanismes de d´etection

des conflits pour chacun des niveaux hi´erarchiques, ce qui a un cout mat´eriel ´elev´e. En

pratique, il faut fixer une profondeur maximale de transaction au-del`a de laquelle on a une

s´emantique `a plat.

5.4.3.3 La s´emantique ouverte

Dans les deux s´emantiques pr´esent´ees, un commit interne n’est pas un vrai commit dans

le sens o `u il peut ˆetre d´efait. Dans la s´emantique ouverte, un commit interne est un vrai

commit dans le sens o `u ses modifications sont visibles des autres threads. Cette solution est

assez compliqu´ee et implique entre autres de d´efinir pour chaque transaction des op´erations

d’annulation `a effectuer en cas d’abort. Pour plus de pr´ecision, le lecteur peut se r´ef´erer

`a [MBM⁺06b]

5.4.4 Autres particularit´es/fonctionnalit´es des syst`emes TM

5.4.4.1 Op´erations d’entr´ees/sorties

Du fait de leur nature, les transactions ne sont pas tr`es compatibles avec les op´erations

d’entr´ees/sorties et les appels syst`emes. En effet, les op´erations d’entr´ees/sorties effectuent

souvent des actions irr´eversibles, qui ne peuvent pas ˆetre d´efaites dans le cas d’un abort (par

exemple, la lecture ou l’´ecriture d’un fichier). Beaucoup de syst`emes TM ne prennent pas en

compte ce probl`eme et consid`erent que les op´erations d’entr´ees/sorties ne sont pas `a utiliser

au sein des transactions. Mˆeme les syst`emes qui apportent une r´eponse `a ce probl`eme

n’ap-portent jamais une r´eponse enti`erement satisfaisante, ce qui constitue un l´eger frein `a

l’ex-pansion du mod`ele.

On pourra se r´ef´erer `a [BZ07] pour un survol du probl`eme. [BLM06] et [LZL+

08]

abor-dent aussi cette question.

5.4.4.2 Interaction avec les verrous

Pour palier le probl`eme ´evoqu´e au-dessus, on pourrait penser utiliser des verrous au

milieu des transactions. Malheureusement, cela pose d’autres probl`emes. Les acc`es aux

verrous sont en g´en´eral non cach´es, donc court-circuitent le syst`eme TM. Cette approche

ne marche pas car une prise de verrou suivie d’un abort m`enerait syst´ematiquement `a une

´etreinte mortelle. Cependant, mˆeme en instaurant un m´ecanisme pour cacher les acc`es aux

verrous, de nombreuses pathologies se mettent en place [HVS08]. L’utilisation conjointe de

transactions et de verrous est donc `a ´eviter d’une mani`ere g´en´erale.

5.4.4.3 Interaction avec les donn´ees non-transactionnelles

Les syst`emes transactionnels doivent enfin faire face au probl`eme d’un acc`es non

trans-actionnel sur une donn´ee qui est par ailleurs dans une transaction. Deux approches existent :

l’isolation faible permet alors `a cet acc`es d’observer l’´etat interm´ediaire de la donn´ee, alors

que l’isolation forte ne le permet pas. Si la plupart des syst`emes STM ne fournissent qu’une

Dans le document Étude de deux solutions pour le support matériel de la programmation parallèle dans les multiprocesseurs intégrés : vol de travail et mémoires transactionnelles (Page 79-82)