Un sincère merci à Alex Boulanger, chic étudiant en session 4 d'informatique de gestion au Collège Lionel-Groulx lors de la session H-2007, pour avoir le premier fait remarquer que ce qui suit manquait à mes notes de cours.
Cet article est un bref complément d'information pour d'autres articles vers lesquels vous trouverez des liens plus bas. Notre regard se posera sur les outils de synchronisation, mais vous comprendrez que le problème soulevé y est beaucoup plus vaste...
Bien que nous ne l'ayons pas explicitement indiqué dans la présentation sur une représentation OO des mutex, il nous faut examiner, au moins en surface, la question de la copie des outils de synchronisation (car la discussion touche aussi les sections critiques, sémaphores, événements et autres variantes sur le même thème).
Imaginons qu'une instance de Mutex soit passée par valeur à une fonction :
Le problème demeure si le Mutex n'est pas copié mais si un objet contenant un attribut de type Mutex l'est. Utiliser un pointeur de Mutex plutôt qu'un Mutex peut régler le problème mais au prix d'une écriture prudente de code permettant de partager le Mutex en question.
On rencontre donc un problème de fond : les outils de synchronisation dont la vie est prise en charge par une approche RAII ne se prêtent pas à la copie.
Devant ce constat, deux options s'offrent à nous :
Personnellement, je tends à préconiser la deuxième option, qui constitue un idiome plus simple à implémenter et qui tend à convenir à des programmes où on rencontre des situations de partage d'objets, donc où les accès indirects sont la norme.
Créer un objet partageable est subtil; créer un objet incopiable est simple.
