authoriser / interdire l'acces aux methodes d'une classe

je nage...

j'ai plusieurs endroits dans mon programme qui appele une meme ressource. Habituellement, on gere cela par un semaphore qui empeche les autres d'acceder a une ressource quand elle est occupée par qqn.

Je ne veux pas de ce modele, car je considere que mes endusers vont se planter en manipulant les semaphores...

je veux donc faire une classe tampon entre mon driver et le code du programme. Cet objet n'a qu'un role, donner l'acces au dernier thread qui demande l'acces et interdire tous les autres. Ce qui est contraire au principe du partage de ressource-semaphore-mutex.

--- les reponses se croisent

disons que le probleme est que j'ai un thread par exemple qui affiche le % d'utilisation du peripherique. C'est un thread qui doit donc acceder au driver directement entre deux requetes et dont l'appel ne gene en rien

J'ai d'autres thread qui ont une action plus violente
arret du peripherique
initialisation des commandes a effectuer
lancement des commandes


jai englobe tous les envoies d'ordre au pheripherique par un // enter critical et end critical (mutex)

par contre
je voudrais que si un thread demande la main sur le perihperique, qu'une exception remonte jusqu'au thread en train de manipuler le periph

Citation:

---

--- les reponses se croisent

---

En effet...:D

Citation:

---

je voudrais que si un thread demande la main sur le perihperique, qu'une exception remonte jusqu'au thread en train de manipuler le periph

---

Ca d'accord je comprends.

Citation:

---

jai englbe tous les envoies d'ordre au pheripherique par un // enter critical et end critical (mutex)

---

De quelle façon? Ne serait-ce pas à cette endroit que tu peux savoir quelle ressource doit recevoir un une exception?N'est-ce pas le role de drivermanager?

Citation:

---

jai englobe tous les envoies d'ordre au pheripherique par un // enter critical et end critical (mutex)

---

OK, tu gères l'accès aux ressources avec "enter critical et end critical (mutex)".

Est-ce que c'est toi qui a codé "enter critical et end critical". Dans ce cas là pourquoi ne pas les "spécialiser" et leur donner la possibilité de se souvenir qui posséde quelle ressource. Ainsi tu pourra lancer une exception au thread qui possède la ressource, lorsque justement un nouveau thread voudra s'accaparer une ressource?

hum yes...

je peux ecrire :

Code:

---

1 2 3 4 5 6 7 8 9

fnt_du_driver 1 enter critical (WaitForSingleObject sous windows) if ( key != key_owner) { end critical (release) throw "tu as perdu les droits" } truc() end critical (release)

---

donc a ce niveau pas de driver manager, gestion des semaphores dans le driver et aussi de la clef

pour chaque fonction je dois copier.coller ce morceau...

le but du driver manager aurait été qu'il agisse comme un filtre
ou je n'ai pas à dupliquer toutes les fonctions du driver

mais j'ai peur de ne pas arriver a coder cela

J'ai bien compris ton problème ouioui.

Pour l'instant je ne vois pas d'autres solutions (mais je cherche...).

Et en renvoyant des proxy qui eux sauront à tout moment qui dispose vraiment des droits ?

1- c'est quoi un proxy ?

2- j'ai ouvert mon bouquin de design pattern sur l'etagere plein de poussiere... j'ai vu le pattern ETAT qui correspond pas mal a ce que je veux. En fait une classe qui peut se mettre dans 2 etats differents suivant ses decisions internes (par exemple la connexion internet : ouvert ou refus).

Pour cela il passe par une classe abstraite qui declare l'interface commune et les sous classes implementent les comportements specifiques

je crois donc que je suis quitte pour dupliquer ma classe... tant pis, c'est le charme de l'objet

1- proxy == intermédiaire qui cache certains détails, typiquement l'accès aux données de l'objet réel.

3- à la va-vite.... et assez bourrin
(penser à séparer délcarations et implémentation)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

// public struct IDriverA { virtual void f() = 0; };   // caché ; penser aux dépendances cycliques -> FAQ struct DriverAimpl : IDriverA { ..... implémentation des fonctions du driver A et ....   auto_lock a_le_droit(const proxyDriverA * p) const { auto_lock al(mutex_); if (p.getId() == last_id_) return al; else return auto_lock(0); }   DriverAimpl() : last_id_(-1) {}   ProxyDriverA requestDriver() { scoped_lock sl(mutex_); return ProxyDriver(this, ++last_id_); }   private: type_mutex mutex_; int last_id_; };   // public struct ProxyDriverA : IDriverA { /*virtual*/ voif f() { scoped_lock l(DAimpl-> a_le_droit(this)); if (l) { implDA_ -> f(); } }   ProxyDriverA( DriverAimpl * impl, int id ) : DAimpl_(impl), id_(id) {} int getId() const { return id_;} // seulement pour DriverAimpl   private: DriverAimpl * implDA_; // def à inclure seulement dans le .cpp // une decl en avant suffit sinon   int id_; };   // Le singleton exposé struct DA_manager : boost::noncopyable { static DA_manager & instance();   ProxyDriverA requestDriver() { return DA_.requestDriver(); }   private: DA_manager() {}; DriverAimpl DA_; }

---

auto_lock et scoped_lock sont des lock RAII (sans ça le code est dessuite plus pénible à écrire et maintenir). Le premier a une sémantique de déplacement (voir std::auto_ptr<>), le second une sémantique de non-copyable et d'auto-détruit en fin de bloc (voir boost::scoped_ptr, boost::scoped_lock, ...)
D'ailleurs les habitués de boost.threads pourront très certainement corriger et améliorer ce brouillon.

Reste aussi en exo la mise la factorisation du code via polymorphisme paramétrique (et non d'héritage/inclusion/...) afin de gérer d'autres types de drivers.

EDIT: le résultat est que

Code:

---

1 2 3 4 5 6

ProxyDriverA da1 = DA_manager::instance().requestDriver(); da1.f(); // marche   ProxyDriverA da2 = DA_manager::instance().requestDriver(); da1.f(); // marche plus da2.f(); // marche

---

da1 et da2 n'étant pas obligés d'être dans le même thread, tout ça.
Et si j'ai bien compris, c'était la question initiale.

la vache, ca fait mal

bon ca fait une heure que je relis et relis... c'est clair je suis pas au niveau (rassure moi tu fais du c++/objet avancé tous les jours ?). Cependant j'ai compris le principe.

Je fais donc une version plus simple et tu me diras si c'est a peu pret cela, l'astuce (enfin l'idee) consiste non pas a renvoyer un pointeur bourrin sur le driver mais un objet contenant la clef courante et le driver. Ainsi j'ai plusieurs instance de mon driver mais un seul detient la bonne clef.

la RAII c'est du stroustrup ?

y a des bouquins qui parlent de ces techniques ? moi je me suis arrete a stroutrup 3ed / stl et intro aux design pattern...

L'idiome Ressource Acquisition is Initialization porte globalement mal son nom. Surtout que c'est un effet de bord de cet idiome qui en fait toute son importance.

Le principe simplifié à retenir est qu'une ressource ne doit jamais se ballader seule dans la nature et doit systématiquement être enveloppée par un objet automatique qui la libèrera à la sortie de son (l'objet) bloc. Un objet automatique étant un objet qui vit dans la pile, ce qui signifie que son destructeur sera appellé (automatiquement) à la sortie du bloc dans lequel l'objet vit. Le destructeur se chargera de réaliser les libérations de ressources (delete, ou delete[], ou unlock, ou XMLReleaseString, ou close, ou ... suivant le type de ressource enveloppée).
C'est un peu le pendant (d'un point de vue besoin: libération déterministe de ressources) du dispose-pattern des langages comme le Java.

Les sous-bibliothèques sus-cités de boost proposent déjà divers types d'enveloppeurs de ressources à la sauce RAII. Les blogs d'Herb Sutter en parlent pas mal -- en profiter sur GOTW pour voir la sémantique de déplacement des std::auto_ptr<>. Le chapitre 4 sur les techniques du C++ de C++ in Action (consultable en ligne) présente lentement cela, mais avec une autre appelation. Un article ("Big Two machin chose") très succint et efficace sur artima en parle. Dans la même famille, Andrei Alexandrescu a écrit un article sur la gestion des exceptions, article dispo dans le forum expert du CUJ et référencé depuis son site (moderncppdesign).

Désolé, je ne connais pas les liens par coeur, mais google tes les donnera rapidement à partir des points d'entrées que j'ai laissés.


Sinon oui. En passant par des proxies ton problème peut avoir une solution.
Côté bouquins, on parle des proxys dans le GoF, mais aussi dans More Exceptional C++ de Scott Meyer -- Addisson-Wesley est globalement ma crèmerie préférée.

thx :) c'est tres clair, merci

je n'ai pas trouve le bouquin dont tu parles j'ai :

effective c++ scott meyer addison
more effective c++ scott meyer addison

et

More Exceptional C++ by Herb Sutter

Bigre les gens, j'ai l'impression que vous tentez de mettre un cataplasme sur une jambe de bois... C'est une bête question de design, et le singleton n'est pas la réponse, je pense !!

Citation:

---

Envoyé par buzzz

J'ai un driver de peripherique stocké dans une classe : Driver

---

Bon, et ce driver est unique, c'est une ressource

Citation:

---

Envoyé par buzzz

[...]

j'ai donc une fonction
Driver * DM(int key);
si la clef est valide le device manager renvoie le pointeur sur le driver
sinon il lance une exception

--- il me semble que ce systeme est correct en tout cas si vous avez meilleure idée !! je suis preneur ---

---

Moi ça me semble tout bon, si tu est sûr qu'on ne peut pas préempter pendant l'excution de Truc() ou Machin()...

Citation:

---

Envoyé par buzzz

il suffit d'ecrire :

Code:

---

1 2 3 4

int key = DM::GetKey(); Driver * t = DM::Driver(key) t->Truc() t->Bidule()

---

alors qu'en sauvegardant l'acces dans une variable
ce n'est pas verifié et le peripherique va peter

---

Et bien il suffit que celà soit impossible.

Code:

---

1 2 3 4 5 6 7

class DM { ... static void Truc(int key); static void Bidule(int key); ... };

---

Les fonction s'occupe de vérifier la validité de la clé, et exécute la fonction voulue si OK.

Citation:

---

Envoyé par buzzz

l'ideal serait que seul le device manager puisse activer la fonction
de maniere indirecte (il suffirait qu'il soit friend de Driver) mais je ne vois pas comment faire

---

Oui, si c'est une classe de confience, un protected friend qui à accès à la méthode qui retourne un Driver*

Fais gaffe aux interblocages !

Citation:

---

Les fonction s'occupe de vérifier la validité de la clé, et exécute la fonction voulue si OK.

---

oui cela marche
mais il n'y pas de reutilisatibilité pour l'ecriture d'un autre driver ou ressource, la version du candidat precedent parait plus lourde mais l'idee est plus avancée.

En effet dans ton cas je dedouble toutes les fonctions (dans driver et DM)
dans son exemple aussi (pas le code juste la declaration).

Dans mon idée actuelle, il suffit de prendre un singleton Driver manager qui contient la clef valide et de repliquer des instances de driver avec des clefs differentes. Ainsi UNE seule classe driver a ecrire et CA ME PLAIT,

C++ In Action (Premier résultat sous google)
GoF -> Gang of Four -> les auteurs du bouquin de référence sur les design patterns.

Sinon, je suis assez d'accord que ces choix de fonctionnement me paraissent assez compliqués.
Après que l'on utilise un singleton ou fonctions membre statiques ne change pas grand chose.

Pour ce qui est des sémaphores-mutex-... ils se doivent d'être gérés de façon transparente dans le code appelé et non délégués aux utilisateurs finaux.

EDIT: en surchargeant operator->() et operator*(), il n'y a rien à écrire en double -- mais on ne dérive plus de IDriverA non plus alors.

Citation:

---

effective c++ scott meyer addison
more effective c++ scott meyer addison
et
More Exceptional C++ by Herb Sutter

---

la question n'etait pas sur GoF, mais la question etait toi tu me parlais de : More Exceptional C++ de scott, de quel bouquin s'agit il parmi les references citees ?

Citation:

---

operator->() et operator*(),

---

hum, ca va un peu vite, mais je vois

bon j'arrive a ma version :) (1 seule classe... DM+Driver fondu)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class Driver { private : static int key; int mykey;   public : Driver() { mutex; mykey = key++; release mutex; } fnt1(...) { mutex; if ( mykey != key ) { release mutex; throw boum; } peripherique->commande(); release mutex; } };

---

bon court / clair / propre (?)
le mutex protege le peripherique et la clef... que du bonheur...
l'objet est automatique

apres 3 jours de reflexion
je crois que je vais prendre cette solution !!!!!!

:oops: J'avais pas vu les pages suivantes...

Effectivement un peu à coté de la plaque je suis.

Enfin pas complètement, la réponse à ta question de départ reste : ne renvoie pas de Driver* aux utilisateurs finaux (qui sont parfois peu finauds, tu as raison de te méfier !)

pour l'instant le end user c'est plutot moi
mais je mefie de moi meme :D
autant que de mes utilisateurs finaux

La gestion du mutex ne va pas (il doit être accessible partout depuis l'objet), et l'incrément sur la clef n'est pas bon -- faire une pré-incrémentation au lieu d'une post (Sinon le statique est toujours décalé d'un).

Note au passage, je n'aurais pas exposé la donnée statique pour à la place la cacher dans l'unité de traduction (.cpp)

Le problème avec ta dernière classe est que tu dupliques les drivers. Genre si le driver toto a un état qui peut être modifié et observé depuis plusieurs threads différents, avec cette approche, les états sont tous disjoints. Côté implémentation tu vas revenir à centraliser ces états dans un unique objet qui est connu (en interne) de tous les objets exposés aux utilisateurs. Bref retour à la solution avec proxy.
D'ailleurs, question peut-on observer (comme dans le DP) sans lever le jeton d'accès ?


Sinon, pour les bouquins, je me suis effectivement emmelé les pincaux. Les MEC++ est le More Effective C++, tandis que le MXC++ est le More Exceptional C++. De toutes façons, ce sont 4 (et plus) bons bouquins.

tiens pas encore couché... ca se voit qu'on a la meme profession :P

Citation:

---

La gestion du mutex ne va pas (il doit être accessible partout depuis l'objet),

---

le mutex est commun a la classe.. variable statique donc
pour proteger aussi la clef :)

Citation:

---

et l'incrément sur la clef n'est pas bon -- faire une pré-incrémentation au lieu d'une post (Sinon le statique est toujours décalé d'un).

---

oui vu

Citation:

---

Note au passage, je n'aurais pas exposé la donnée statique pour à la place la cacher dans l'unité de traduction (.cpp)

---

une fausse statique donc...

Citation:

---

Le problème avec ta dernière classe est que tu dupliques les drivers. Genre si le driver toto a un état qui peut être modifié et observé depuis plusieurs threads différents, avec cette approche, les états sont tous disjoints. Côté implémentation tu vas revenir à centraliser ces états dans un unique objet qui est connu (en interne) de tous les objets exposés aux utilisateurs. Bref retour à la solution avec proxy.

---

jour de chance !! il n'en a aucun :) (pour une fois !!!)
et de toute facon comme dans mon modele le dernier
objet driver créé prend la main :) il reset automatiquement
le periph, donc les variables d'etat sont les siennes car tous
les autres instances derriere ont pris une exception une a une

Citation:

---

D'ailleurs, question peut-on observer (comme dans le DP) sans lever le jeton d'accès ?

---

je dirais que non... le peripherique (branchée sur l'usb et commandé par un controle activeX (beurk)) a de forte humeur. Ainsi meme si on lui donne une commande, il ne l'a fait pas forcement, le seule moyen de connaitre son etat est de lui demander, donc acces au periph=> mutex

Citation:

---

Sinon, pour les bouquins, je me suis effectivement emmelé les pincaux. Les MEC++ est le More Effective C++, tandis que le MXC++ est le More Exceptional C++. De toutes façons, ce sont 4 (et plus) bons bouquins.

---

ok je vais faire rentrer cela