Discussion :

[buzzz]

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

J'ai une classe gestionnaire de periph appelée par les
differentes threads : DM

Un thread demande l'acces au driver et recoit une clef
qui l'identifie comme propriétaire

en cours de route la clef peut etre invalidée pcq un process
prioritaire a pris la main sur le driver

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 ---

Mon probleme est le suivant, en cas d'export du code
et d'utilisation par une tierce personne pressée

il suffit d'ecrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int key     = DM::GetKey();
DM::Driver(key)->Truc()
DM::Driver(key)->Bidule()

ou la si la fonction a perdu la main entre truc et bidule
DM peut lancer une exception

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

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


[Balises CODE rajoutées par Loulou24, merci d'y penser à l'avenir]

[porcher]

C'est pas clair ta présentation.

j'ai donc une fonction

Driver * DM(int key);

Tu l'utilise ou cette fonction DM dans ton code??
Pas la en tout cas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Driver * t = DM::Driver(key)

[moldavi]

Je crois que cet article peut t'intéresser:

http://christophej.developpez.com/tu...n/multithread/

Il n'est pas en C++, mais le concept reste identique et permet de comprendre la difficulté de la chose.

[buzzz]

ok pour le pattern singleton

mais ca ne me donne pas des droits d'acces "propres" aux methodes d'une classe

[moldavi]

ok pour le pattern singleton

mais ca ne me donne pas des droits d'acces "propres" aux methodes d'une classe

Qu'est-ce que tu entends par "accès propre"?

[mat.M]

Je n'arrive pas à comprendre le problème : les membres privées d'une classe d'objet c'est le BA - BA du C++ ; ce sont les bases j'ai l'impression qu'il ya confusion ....
Sinon il faudrait donner plus de détails : est-ce que TOUS les composants et classes sont développés par soi-même ou bien est-ce que par exemple le driver en question provient d'une société tierce dont on n'a le code source .???
Dans le cas contraire il suffit de créer des classes d'objets avec des membres private point à la ligne

Je crois que cet article peut t'intéresser:

http://christophej.developpez.com/tu...n/multithread/

Il n'est pas en C++, mais le concept reste identique et permet de comprendre la difficulté de la chose.

Je doute qu'on puisse adapter ce qui est développé en Java vers C++ ; ce sont des méchanismes radicalement différents.

[moldavi]

Je doute qu'on puisse adapter ce qui est développé en Java vers C++ ; ce sont des méchanismes radicalement différents.

As-tu lu l'article? Je n'ai jamais parlé d'adaptation mais de concept. Cet article permet de voir quels types de problèmes on peut rencontrer dans un environnement multithread.

[Laurent Gomila]

Moi ce que je ne saisis pas c'est que tu donnes un accès direct au driver (via DM:river(key)) alors que ce que tu shouaites c'est justement qu'on ne puisse pas l'utiliser directement (mais via DM:river(key)) :

[buzzz]

tout d'abord merci pour votre participation

ensuite, je n'ai jamais dit que mon probleme etait bien posé


le contexte, je developpe entierement l'ensemble de l'application
neanmoins (un jour) elle sera mise en diffusion afin que d'autre
personnes (par tres informaticiennes) l'utilise pour developper
des applis autours de ce peripherique. Donc disons que je m'occupe
de l'ecriture du coeur de l'appli - gestion MDI - option de base
driver -- quelques fenetres MDI qui utilise le driver en guise d'exemple

voila le probleme : je n'ai qu'une instance de driver, donc singleton (ok)
(disons pour simplifier un peripherique qui fait de l'acquisition de mesure).

Chaque fenetre mdi propose differents scenario et quand j'appuie sur le boutton go => la fenetre declenche les operations sur le peripheriques a partir d'un thread.

Il peut y avoir plusieurs fenetres ouvertes. Mais une fiche ne prend les droits sur le peripherique que lorsque l'experience est lancée, pas lorsque l'on rentre les modalités de l'experience.

MON PROBLEME

Pour les futurs developpeurs amateurs j'aurais aimé qu'ils aient acces au driver par un driver manager qui leur masque le probleme de semaphore (qui n'entre pas dans les choses dont ils voudront se preoccuper - si dans leur code il oublie de rendre le semaphore - l'appli est morte).

Ainsi :

Un thread prend la main et se sert du device manager pour faire cela
et il rend la main quand il a fini. Mais l'utilisateur peut oublier de progammer la gestion de la liberation du peripherique (car il faut aussi l'integrer dans les diverses plantages et gestion d'exception ce qu'il ne fera pas). Lorsqu'un autre thread demande la main, l'interet serait d'avoir une messagebox demandant a l'utilisateur s'il authorise le nouveau thread a prendre la main. (donc meme si le programme est mal foutu, le semaphore sera relachée et on aura encore acces au periph - c'est mieux que de fermer/reouvrir l'appli)

Si l'utilisateur dit oui - le dernier demandeur prend la main et l'ancien utilisateur perd la main.

Conclusion j'ai toujours deux threads qui vont acceder a la meme ressource (le driver) dont un qui n'a plus le droit de le faire

Alors j'avais pensé que la classe device manager pourrait donner le droit d'acces au driver (et a ses methodes) et que les appels du thread invalidé genereraient (par l'intermediaire du device manager) une leve d'exception. Pour que le thread s'arrete.

(mon idée n'est peut etre pas la meilleure ... )

comment faire cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class Driver
{
  friend driver Manager
  private :
      static driver * GetInstance();
      void FaitCa();
   public : 
}
 
class Driver Manager
{
   private : int key;
   public  :
   int  RequestKey() { key++; return key; }
   void FaitCa(int KK) {
     if ( key != KK) throw TU_NES_PLUS_PROPRIETAIRE;
     sinon Driver::GetInstance->FaitCa();
}

Probleme C EST PAS GENERIQUE
cad que pour chaque evolution de mon driver
va falloir que je duplique la modif dans driver manager (beurk)
c'est pas du tout reutilisable sur une autre version de driver directement.

J'aurais voulu une classe driver manager qui me permette l'acces a n'importe qu'elle classe (ainsi qu'aux methodes...)

[moldavi]

Alors j'avais pensé que la classe device manager pourrait donner le droit d'acces au driver (et a ses methodes) et que les appels du thread invalidé genereraient (par l'intermediaire du device manager) une leve d'exception. Pour que le thread s'arrete.

(mon idée n'est peut etre pas la meilleure ... )

Je ne vois pas de meilleure idée.

Probleme C EST PAS GENERIQUE
cad que pour chaque evolution de mon driver
va falloir que je duplique la modif dans driver manager (beurk)
c'est pas du tout reutilisable sur une autre version de driver directement.

Là faut que tu m'expliques, je ne vois pas ou est le problème.

Si ton driver est modifié cela doit rester transparent à la classe "driver manager". Au pire si tu dois modifier cette classe, cela devrait aussi rester transparent pour les classes "driver" que d'autres personnes vont programmer.

[buzzz]

l'implementation presentée ci-apres garantit tout ce que je demande, cependant je duplique toutes les fonctions de driver dans driver manager et c'est pour cela que je dis que c'est pas reuse.

class Driver
{
friend driver Manager
private :
static driver * GetInstance();
void FaitCa();
public :
}

class Driver Manager
{
private : int key;
public :
int RequestKey() { key++; return key; }
void FaitCa(int KK) {
if ( key != KK) throw TU_NES_PLUS_PROPRIETAIRE;
sinon Driver::GetInstance->FaitCa();
}

[moldavi]

Heu........

Tu connais l'héritage et le polymorphisme?

[buzzz]

euh oui

peux tu remasteriser le code de l'exemple ci dessus ?

[moldavi]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
template <class T>
 
class CDriverManager{
 
  public:
 
    static T& GetInstance() { if(!Inst) Inst = new T; return *Inst; }
 
    static void Destroy() { delete Inst; Inst = NULL; }
 
    bool RequestDriver() {
 
           if(!Libre)
             return false;
           else{
             Libre = false
             return true;
         }
 
    virtual FaitCa() = 0;
 
 
  protected:
 
    CDriverManager();
    ~CDriverManager();
 
    int key;
 
  private:
 
    static T* Inst;
 
    bool Libre;
 
    CSingleton(CSingleton&);
 
    void operator =(CSingleton&);
};
 
class Driver : public CDriverManager<Driver>{
 
  friend class CDriverManager<Driver>;
 
  private:
 
    void FaitCa();
 
    void Request() { if(CDriverManager::GetInstance()->RequestDriver())
                       FaitCa();
                   }
};

Ce code est largement inspiré de la classe CSingleton du tutorial de Loulou24. (qu'est-ce qu'on dit : merci loulou24).

Ce code comporte sûrement plein d'erreur, désolé mais j'espère que des gens le corrigeront, merci à eux.

C'est surtout pour te donner un point de départ je l'espère...

L'idée général:

tu déclares virtual la fonction FaitCa(); dans la classe manager. Ainsi chaque classe Driver pourra la redéfinir.
Avant de faire quoique ce soit, les classes Driver demande si la ressource est libre, sinon elles atendent et retentent plus tard.

Je n'ai pas implémenter le fait qu'il puisse y avoir plusieurs ressources. A ce moment là à toi de passer en paramètre la-dite ressource et de gérer ça.

Il n'y a pas non plus les fonctions gestion des ressources (mutex), par exemple si une classe driver demande la ressource je stoppe le thread qui le détient, et je donne la ressource tout de suite. On peut imaginer un mécanisme de message avec temporisateur et un mécanisme de priorité.

Mais je vais pas te faire tout le bouleau et je suis même en train de me demander si j'en suis capable...

[moldavi]

A la limite la classe CDriverManager se comporte comme le ferait un système d'exploitation qui gère ses ressources et le multitâche. (Ben là bonne chance).

Il y a parfois des classes dédiées à la gestion des mutex et des sémaphores.
Pourquoi pas ne pas en faire hériter CDriverManager. Tu auras moins besoin de te casser la tête.

Par contre je ne peux rien te dire de plus, je n'ai jamais implémenté...

[buzzz]

je lis et relis ton exemple (merci bien au fait)
il me semble qu'il est assez proche du mien (tout en etant different)

En fait la question sur la reutilisabilité etait :

j'ai un driver A

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
class driver A
{
   func1()
   func2()
   func3()
};
 
class driver B
{ 
  func5()
  func6()
};

si je passe par un template(ta methode) ou polymorphisme
je suis coincé car les drivers ne sont pas sensés avoir les
memes fonctions (bien au contraire !!!)
Par contre le driver manager n'en a qu'une

une autre maniere de gerer le probleme (cote semaphore ca va je suis a jour j'y ai passé le dimanche dessus !!!)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
template<class T>
TManager
{
  T * thedriver;   
  int key;
 
  public :
  static Accede(int key)
  {
     if ( access != key ) throw "t'as perdu les droits kiki"
     else return thedriver;
  }  
  int static GetKey() { return key++; }
};

ainsi dans le programme j'accede
au driver part :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
TManager<driverA> TT;
 
fnt()
{
   int k = TT::GetKey();
   TT.Accede(Key)->func1();   
   TT.Accede(Key)->func2();   
   TT.Accede(Key)->func3();   
}

si un autre thread choppe une autre clef entre temps, fnt recevra une exception au prochain acces au driver sur func2 ou func3

cette methode marche tres bien
le probleme est que j'ai peur qu'un user tappe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
fnt()
{
   int k = TT::GetKey();
   driverA * d = TT.Accede(Key);   
   d->func1();
   d->func2();
   d->func3();
}

et la plus aucune verification des droits

(pour preciser mon statut, je suis informaticien de profession, mais etant chercheur d'activité, je ne pratique plus... sauf pour les projets, le probleme par exemple est que la j'effectue un mois de codage serieux et c''est mon premier depuis un an... et je sens que j'ai perdu... l'informatique étant ma passion, cela m'effraie et donc je rebosse a mort pour relever le niveau que j'estime "juste" arrive a maintenir a flot


[Balises CODE rajoutées par Loulou24, merci d'y penser à l'avenir]

[moldavi]

arf, on ne voit pas les choses de la même façon...

Ce n'est pas un reproche mais j'ai l'impression que tu ne comprends pas la notion de polymorphisme.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class driverA{
 
  func1();
  func2();
  func3();
  FaitCa(){  func1(); func2(); func3(); }
};
 
class driverB{
 
  func5();
  func6();
  FaitCa(){ func5(); func6(); }
};

En gros bien sur!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[buzzz]

bon on reprend

si normalement je suis a jour cote polymorphisme enfin je crois mais bon tout est possible

alors...

pourquoi tout mettre dans FaitCa, a la base mon "premier" driver dispose de 10 fonctions diverses et variées, je ne peux jamais dire dans quel ordre elles sont appelees, donc impossible d'ecrire ce que tu dis dans le message ci dessus

les drivers sont sensés etre completement differents donc pas de polymorphisme

par contre j'aurais aimé ecrire une seule classe, driver manager<Template driver> qui recoit la gestion de la prise de main du peripherique par les threads et ca je n'y arrive pas

[moldavi]

les drivers sont sensés etre completement differents donc pas de polymorphisme

C'est ça l'histoire. Avec FaitCa() drivermanager pas besoin de connaître la façon dont les classes driver implémente cette fonction. En améliorant même le code que j'ai mis tu pourrais t'assurer que les classes driver n'accèdent pas en même temps à la même ressource.

par contre j'aurais aimé ecrire une seule classe, driver manager<Template driver> qui recoit la gestion de la prise de main du peripherique par les threads et ca je n'y arrive pas

Je ne vois pas ce qui ne marche pas, précises.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
TManager<driverA> TT;
 
fnt(){
 
  int k = TT::GetKey();
  TT.Accede(Key)->func1(); 
  TT.Accede(Key)->func2();
  TT.Accede(Key)->func3();
};

Tu veux absolument que ce soit manager qui appelle tes fonctions. C'est l'inverse que tu dois faire.

Tes classes exécuteront tes fonctions depuis leur classe si elles en ont l'autorisation. Regardes bien mon code. A ce moment drivermanager ne fait bien qu'uniquement gérer les accès ressources.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
fnt()
{
int k = TT::GetKey();
driverA * d = TT.Accede(Key);
d->func1();
d->func2();
d->func3();
}

La classe drivermanager est un singleton, c'est justement pour éviter ce genre de chose.

PS: ce sujet que je pense ne pas bien maîtriser, m'intéresse parce que bientôt je vais devoir implémenter les threads dans mon programme.

[moldavi]

Bon c'est difficile de bien se comprendre et de bien s'expliquer.

En effet je crois que je me suis égaré avec le polymorphisme. Je n'avais pas bien en tête la conception générale.

L'idée c'est peut-être ça:

Lorsque tu utilises une fonction qui accède à une ressource, on va dire que c'est un cas critique.

Dès que tu entres dans une de tes fonctions func1(); func2();, etc...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
func1(){
 
  CDriverManager::GetInstance()->entercriticalsection();
 
  ... // ton code
 
  CDriverManager::GetInstance()->leavecriticalsection();
}

L'idée c'est que de cette manière, ton code ne sera exécuté que lorsque drivermanager te donneras la ressource.

Après à toi de décider comment sont distribuer les ressources.