hello,
 
Question multi threading.
 
Comment puis-je faire pour limiter le r/w d'une variable à une seul thread ?
 
je connais juste la technique pour locker un bout de code :
 
lock()
...//code
unlock()
 
mais comment faire pour qu'une variable d'une classe utilisée dans une fonction ne puisse pas être utilisée en même temps dans une autre fonction de la classe.
 
par exemple :
 
lock()
void f1(){
...//var1...
}
unlock()
 
lock()
void f2(){
...//var1=...
}
unlock()
 
=> Un Thread accède à f1 et un autre à f2, potentiellement
var1 peut être r/w en même temps à deux endroits différents, donc problème
 
 
 
Merci!

Pour l'instant, tu ne trouveras rien de standard en C++ pour répondre à ta demande.
 
Maintenant, tu peux te documenter sur les mutex et regarder l'api de ton OS, ou alors jeter un oeil à ce que propose boost sur le sujet.

boost::mutex et boost::semaphore
Et lire un Tanenbaum

boost::mutex ça sait faire ça ? locké un membre donnée d'une classe ?

C'est stable comme bilbi ? ça évolue pas toutes les 2 semains genre ?

... t'en as d'autres du genre ...  
faudra commencer à comrpendre que Bosot c'ets pas 3 ados boutonneux qui s'en occupent mais des professionels

t'es marrant toi, mais on voit partout que la lib fait des modifs tous les 36 du mois

les bug fixes ca te dit rien evidemment ...
 
l'interface est stable, les seuls changement sont les correctifs de bug et les nouvelles bibliothèques ...

oui oui à part que par exemple pour boost:mutex, des parties entière de la librairie sont finalement jetés

Ca date de bien 4 versions le changement d'API de mutex et vu que le précédent était incomplet et peu extensible ca se comprend.
Mias bon je te laisse te chier dessus avec les mutex posix tu verras c'ets super  

comment faire  pour réussir à avoir dans un objet des fonctions lock/unlock pour bloquer l'accés à cet objet à un seul thread ?

Myobjet o;
o.lock()

on n'est pas en C#
 
En C++, c'est une association logique que tu feras, du style :
 

 
avec la classe Lock qui verrouille le mutex pendant sa durée de vie. Bref, lis la doc de boost, c'est probablement très bien fait.
 
Un petit coup d'oeil m'indique que le lock dont je parle a l'air d'être appelé scoped_lock dans boost, quelqu'un pourra éventuellement confirmer

oui mais là c'est pas le pbm que je cherche à éviter. ça c'est bon c'est compris, ce que je cherche à faire c'est un peu différent..Je voudrais finalement pouvoir locker un objet pas suelement un bout de code...

pour qu'un à moment donné, un membre donées, utilisées dans plusieurs fonctions membres justment, ne puisse pas être utilisé pas deux thread simultanément..

Bah y'a pas vraiment de solution.
Tu sécurise les primitives qui seront utilisées, y'a pas trop d'autres solutions.
 
Sinon oui theshockwave, scoped_lock est effectivement l'approche dont tu parles.

visiblement ce cowboy y est parvenu http://the-lazy-programmer.com/blog/?p=39

je peux peut être adapté pour mon cas

Et bien oui tu pourrais encapsuler le tout via une class template qui fait le lock sur les opérations de base. (mais ça pourrait faire un mutex par variable, enfin à voir).
 
Enfin les mutex sur les objets, ça peut etre moyen, enfin à voir, c'est plus dans le flot général de traitement qu'il faut les placer.

locker des objets c'est juste la plus mauvaise façon de faire, on est pas en JAVA quoi
Les lock doivent etre le plus atomiques possibles et sont fondamentalement des operations qui ont un sens sur le flot de controle pas sur les données.

la macro LOCK ne doit rien faire d'autre que ouvrir un scope, locker un mutex en RAII et fermer son scope.

je vois ça me parait pas déconnant ce que tu dis.

Dans mon cas, je suis précisemment exposé à ce problème :

Une classe log
- une méthode write => accède à un membre donnée de type std::ostringstream
- un thread lancé dans le constructeur de log , qui check si le buffer std::ostringstream est suffisamment rempli est fait un flush

Une autre classe qui a Log en membre donnée.
si cette dernière appel la méthode write de son membre donnée de type Log pendant que le thread de ma classe de Log fait un flush, je peux avoir un undefined behavior, dû à l'accés simultanée de mon buffer std::ostringstream, comment puis-je éviter ça ?

Là le pbm c'est pas que deux thread accèdes au même code simultanément, c'est bien que des threads accèdent à la même variable en même temps..

il faudrait que dans write je puisse stoppé temporairement le thread qui flush? c'est la seule façon de faire ?

bah ilf aut rendre ta methode write 'synchronized' comme en JAVA.
En gros, à l'entrée de la méthode tu lock un mutex associé à ton objet log et tu le delock en sortie. Idem pr la méthode de flush.

mais oui voilà, si j'ai un mutex en membre donnée , que je le lock dans write, flush doit attendre... tout simplement!

je vosi pas comment tu peut faire autrement hein
goto lire Tanenbaum

la vérité j'avais pas pris conscience qu'un un lock dans une méthode en plus de locker le bout de code, empêche un autre lock de locker le même mutex... et c'est pil poil ça qu'il me fallait

tu lock jamais de code, tu lock le mutex.
le mutex c'est le videur de boite de nuit, quand il tu rentres pas, tu rentres pas

 
bin c'est un peu la définition du mutex/sémaphore

ça va on a compris

dézolay faut pas se vexer