débloquage sécurisé de mutex en C++

Serge Paccalin

21/09/2004 à 17:30

Le mardi 21 septembre 2004 à 14:47, Eric Bart a écrit dans
fr.comp.lang.c++ :

Je comprends le principe du RAII mais j'ai du mal dans le détail.

class RAII_Mutex
{
public:
RAII_Mutex (Mutex& mutex_) : mutex (mutex_)
{ pthread_mutex_lock (&mutex); }

je ne comprends pas: " : mutex (mutex_)"
La classe RAII_Mutex descend-elle d'une autre classe ?

Non, cette notation sert aussi pour initialiser des membres, pas
seulement les classes dont on hérite. Elle est parfois inutile, parfois
utile, et parfois obligatoire comme ici, parce que le membre à
initialiser est une référence. Un autre exemple, loin des mutex :

class Employe
{
public:
Employe(const string &sNom,double rSalaire);

private:
string m_sNom;
double m_rSalaire;
};

// Écriture 1
Employe::Employe(const string &sNom,double rSalaire)
: m_sNom(sNom)
, m_rSalaire(rSalaire)
{
}
// m_sNom est construit avec string::string(const string &)
// et c'est tout.

// Écriture 2
Employe::Employe(const string &sNom,double rSalaire)
{
m_sNom = sNom;
m_rSalaire = rSalaire;
}
// m_sNom est construit avec string::string()
// puis modifié par string::operator=(const string &).
// c'est plus lent.

Pour le double, il n'y a pas de différence pratique.

Pour un membre qui n'aurait pas de constructeur par défaut, l'écriture 1
est la seule qui compile...

~RAII_Mutex()
{ pthread_mutex_unlock (&mutex); }
private:
Mutex& mutex;
};

Et ton code devient :

{
RAII_Mulex lock(mutex);

Je suppose que lock() vient de la classe parente

Non, c'était le nom de la variable ainsi créée. J'aurais peut-être dû
mettre un nom plus parlant comme :

RAII_Mutex MonVerrou(mutex);

// Section critique
}

Note les accolades, qui permettent de contrôler la durée de vie de
l'objet RAII_Mutex.

Je ne connais pas cette utilisation des accolades. Exite-t-elle dans la
glib ?

Elle existe dans tout code C++, et même C. Une variable déclarée à
l'intérieur d'un bloc n'existe qu'à l'intérieur de ce bloc et est
détruite à la sortie du bloc. Ce qui n'avait d'effet que purement
syntaxique, ou presque, en C prend une toute autre dimension en C++ avec
l'existence d'un destructeur à appeler.

void MaFonction()
{
{ //1
RAII_Mutex MonVerrou(mutex);

// Le code qui suit est
// protégé par MonVerrou
// jusqu'à l'accolade
} //1

// Ici, on n'est plus protégé
// par MonVerrou

}

Le destructeur de la variable MonVerrou (et donc, la libération du
mutex) a été appelé quand on a quitté le bloc //1.

--
___________ 2004-09-21 17:11:58
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763

Le mardi 21 septembre 2004 à 14:47, Eric Bart a écrit dans
fr.comp.lang.c++ :

Je comprends le principe du RAII mais j'ai du mal dans le détail.

class RAII_Mutex
{
public:
RAII_Mutex (Mutex& mutex_) : mutex (mutex_)
{ pthread_mutex_lock (&mutex); }

je ne comprends pas: " : mutex (mutex_)"
La classe RAII_Mutex descend-elle d'une autre classe ?

Non, cette notation sert aussi pour initialiser des membres, pas
seulement les classes dont on hérite. Elle est parfois inutile, parfois
utile, et parfois obligatoire comme ici, parce que le membre à
initialiser est une référence. Un autre exemple, loin des mutex :

class Employe
{
public:
Employe(const string &sNom,double rSalaire);

private:
string m_sNom;
double m_rSalaire;
};

// Écriture 1
Employe::Employe(const string &sNom,double rSalaire)
: m_sNom(sNom)
, m_rSalaire(rSalaire)
{
}
// m_sNom est construit avec string::string(const string &)
// et c'est tout.

// Écriture 2
Employe::Employe(const string &sNom,double rSalaire)
{
m_sNom = sNom;
m_rSalaire = rSalaire;
}
// m_sNom est construit avec string::string()
// puis modifié par string::operator=(const string &).
// c'est plus lent.

Pour le double, il n'y a pas de différence pratique.

Pour un membre qui n'aurait pas de constructeur par défaut, l'écriture 1
est la seule qui compile...

~RAII_Mutex()
{ pthread_mutex_unlock (&mutex); }
private:
Mutex& mutex;
};

Et ton code devient :

{
RAII_Mulex lock(mutex);

Je suppose que lock() vient de la classe parente

Non, c'était le nom de la variable ainsi créée. J'aurais peut-être dû
mettre un nom plus parlant comme :

RAII_Mutex MonVerrou(mutex);

// Section critique
}

Note les accolades, qui permettent de contrôler la durée de vie de
l'objet RAII_Mutex.

Je ne connais pas cette utilisation des accolades. Exite-t-elle dans la
glib ?

Elle existe dans tout code C++, et même C. Une variable déclarée à
l'intérieur d'un bloc n'existe qu'à l'intérieur de ce bloc et est
détruite à la sortie du bloc. Ce qui n'avait d'effet que purement
syntaxique, ou presque, en C prend une toute autre dimension en C++ avec
l'existence d'un destructeur à appeler.

void MaFonction()
{
{ //1
RAII_Mutex MonVerrou(mutex);

// Le code qui suit est
// protégé par MonVerrou
// jusqu'à l'accolade
} //1

// Ici, on n'est plus protégé
// par MonVerrou

}

Le destructeur de la variable MonVerrou (et donc, la libération du
mutex) a été appelé quand on a quitté le bloc //1.

--
___________ 2004-09-21 17:11:58
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763

Vous avez filtré cet utilisateur ! Consultez son message

Le mardi 21 septembre 2004 à 14:47, Eric Bart a écrit dans
fr.comp.lang.c++ :

Je comprends le principe du RAII mais j'ai du mal dans le détail.

class RAII_Mutex
{
public:
RAII_Mutex (Mutex& mutex_) : mutex (mutex_)
{ pthread_mutex_lock (&mutex); }

je ne comprends pas: " : mutex (mutex_)"
La classe RAII_Mutex descend-elle d'une autre classe ?

Non, cette notation sert aussi pour initialiser des membres, pas
seulement les classes dont on hérite. Elle est parfois inutile, parfois
utile, et parfois obligatoire comme ici, parce que le membre à
initialiser est une référence. Un autre exemple, loin des mutex :

class Employe
{
public:
Employe(const string &sNom,double rSalaire);

private:
string m_sNom;
double m_rSalaire;
};

// Écriture 1
Employe::Employe(const string &sNom,double rSalaire)
: m_sNom(sNom)
, m_rSalaire(rSalaire)
{
}
// m_sNom est construit avec string::string(const string &)
// et c'est tout.

// Écriture 2
Employe::Employe(const string &sNom,double rSalaire)
{
m_sNom = sNom;
m_rSalaire = rSalaire;
}
// m_sNom est construit avec string::string()
// puis modifié par string::operator=(const string &).
// c'est plus lent.

Pour le double, il n'y a pas de différence pratique.

Pour un membre qui n'aurait pas de constructeur par défaut, l'écriture 1
est la seule qui compile...

~RAII_Mutex()
{ pthread_mutex_unlock (&mutex); }
private:
Mutex& mutex;
};

Et ton code devient :

{
RAII_Mulex lock(mutex);

Je suppose que lock() vient de la classe parente

Non, c'était le nom de la variable ainsi créée. J'aurais peut-être dû
mettre un nom plus parlant comme :

RAII_Mutex MonVerrou(mutex);

// Section critique
}

Note les accolades, qui permettent de contrôler la durée de vie de
l'objet RAII_Mutex.

Je ne connais pas cette utilisation des accolades. Exite-t-elle dans la
glib ?

Elle existe dans tout code C++, et même C. Une variable déclarée à
l'intérieur d'un bloc n'existe qu'à l'intérieur de ce bloc et est
détruite à la sortie du bloc. Ce qui n'avait d'effet que purement
syntaxique, ou presque, en C prend une toute autre dimension en C++ avec
l'existence d'un destructeur à appeler.

void MaFonction()
{
{ //1
RAII_Mutex MonVerrou(mutex);

// Le code qui suit est
// protégé par MonVerrou
// jusqu'à l'accolade
} //1

// Ici, on n'est plus protégé
// par MonVerrou

}

Le destructeur de la variable MonVerrou (et donc, la libération du
mutex) a été appelé quand on a quitté le bloc //1.

--
___________ 2004-09-21 17:11:58
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763

Fabien LE LEZ

21/09/2004 à 19:15

On 21 Sep 2004 14:56:12 GMT, Marc Boyer
:

Je n'ai rien trouvé dans mes bouquins C/C++ Delanoy (1998) sur
les accolades qui déterminent une zone locale. Passons...

Ce qui tendrais à prouver que ce bouquin n'est pas bon ;-)

Si j'ai tout bien suivi, y'a pas besoin de ça pour le prouver...

--
;-)

kanze

22/09/2004 à 09:03

"Eric Bart" wrote in message
news:<41504018$0$17705$...

"Richard Delorme" wrote in message
news:4150270b$0$15753 "Arnaud Meurgues"
wrote in message news:415027a2$0

PS : achète toi un bon livre sur le C++. Les « détails » sur
lesquels tu butes sont quand même les bases du langage C++ actuel.

Je n'ai rien trouvé dans mes bouquins C/C++ Delanoy (1998) sur les
accolades qui déterminent une zone locale.

C'est un aspect fondamental du langage (hérité d'ailleurs du C), mais
c'est vrai qu'on ne sert pas des accolades gratuites très souvent -- on
préfère des fonctions bien petites, où ce n'est pas nécessaire.

Passons...

Pareil pour l'initialisation. Ainsi :

RAII_Mutex (pthread_mutex_t & mutex_) : mutex (mutex_)
{ pthread_mutex_lock (&mutex); }

est équivalent à :

RAII_Mutex (pthread_mutex_t & mutex_)
{
mutex = mutex_;
pthread_mutex_lock (&mutex);
}

Je suppose que la première forme permet de guarantir l'initialisation.

Il y a plusieurs différences, et en général (mais il y a des
exceptions), c'est la première forme qu'on préfère.

Dans mon bouquin Delanoy, je ne trouve pas cette forme
d'initialisation.

Alors que c'est un des aspects fondamentaux de C++, dont on se sert
constamment ? Là, tu m'inquiètes -- un livre qui ne présente pas cette
forme d'initialisation, et assez tôt, prèsqu'au même moment des
constructeurs, est réelement défecteux, et bon à jeter.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Fabien LE LEZ

22/09/2004 à 09:06

On 22 Sep 2004 00:03:55 -0700, :

et bon à jeter.

Si je ne m'abuse, il ne se passe pas deux mois sans qu'on dise du mal
de ce bouquin sur fclc++. Malheureusement, ça ne l'empêche pas de se
vendre...

--
;-)

Arnaud Meurgues

22/09/2004 à 11:13

Fabien LE LEZ wrote:

Je n'ai rien trouvé dans mes bouquins C/C++ Delanoy (1998) sur
les accolades qui déterminent une zone locale. Passons...
Ce qui tendrais à prouver que ce bouquin n'est pas bon ;-)

Si j'ai tout bien suivi, y'a pas besoin de ça pour le prouver...

Non. Les livres de Delanoy sont à fuire comme la peste.

--
Arnaud
(Supprimez les geneurs pour me répondre)

Mickael Pointier

22/09/2004 à 18:51

et bon à jeter.

Si je ne m'abuse, il ne se passe pas deux mois sans qu'on dise du mal
de ce bouquin sur fclc++. Malheureusement, ça ne l'empêche pas de se
vendre...

A sa décharge, j'ai ce livre, (5ème édition), et dans le chapitre 7:
"Construction, destruction et initialisation des objets", on trouve la
section 6 "Initialisation de membres dans l'en-tête d'un constructeur", page
137, qui parle exactement de ce que l'on débatait dans cette enfilade:

========== La syntaxe que nous avons décrite au paragraphe 5.2 pour transmettre des
arguments à un constructeur d'un objet membre peut en fait s'appliquer à
n'importe quel membre, même s'il ne s'agit pas d'un objet. Par exemple:

class point
{
int x,y;
public:
point (int abs=0,int ord=0): x(abs),y(ord) {}
...
};

L'appel du constructeur /point/ provoquera l'initialisation des membres x et
y avec respectivement les valeurs abs et ord. Son corps est vide ici,
puisqu'il n'y a rien de plus à faire pour remplacer notre constructeur
classique:

point (int abs=0,int ord=0) { x«s; y=ord; }
==========
(ca continue en disant que cette syntaxe est indispensable pour
l'initialisation des références et autres membres const)

Le Delannoy n'est peut-être pas ce qui se fait de mieux dans la catégorie,
mais entre mon Stroustrup version Française et le Delannoy, lorsque je me
pose une question sur un point à la con, je ne met pas longtemps à choisir.
D'ailleur un de ces jours je vais mettre le BS à la poubelle, ca me fera de
la place dans mes étagères :-)

Mike

Arnaud Meurgues

23/09/2004 à 09:55

Mickael Pointier wrote:

et bon à jeter.
A sa décharge,

Tu choisis tes mots... ;-)

Le Delannoy n'est peut-être pas ce qui se fait de mieux dans la catégorie,
mais entre mon Stroustrup version Française et le Delannoy, lorsque je me
pose une question sur un point à la con, je ne met pas longtemps à choisir.
D'ailleur un de ces jours je vais mettre le BS à la poubelle, ca me fera de
la place dans mes étagères :-)

Je veux bien faire la poubelle... ;-)

--
Arnaud
(Supprimez les geneurs pour me répondre)

Fabien LE LEZ

23/09/2004 à 09:58

On Wed, 22 Sep 2004 18:51:13 +0200, "Mickael Pointier"
:

Le Delannoy n'est peut-être pas ce qui se fait de mieux dans la catégorie,
mais entre mon Stroustrup version Française et le Delannoy, lorsque je me
pose une question sur un point à la con, je ne met pas longtemps à choisir.

Mais en lisant la réponse dans le Delannoy, quelle assurance as-tu
qu'elle soit la bonne ?
[Bon, OK, c'est vrai que les "vieilles" VF du Stroustrup étaient aussi
mauvaises que la majorité des traductions]

Généralement, ma référence est plutôt le Eckel, nettement plus simple
à lire que le Stroustrup.

--
;-)

débloquage sécurisé de mutex en C++

8 réponses

Veuillez sélectionner un problème