un vector de classe

14 réponses

PasDeSpam

09/09/2008 à 00:01

bonsoir,

j'ai une classe wrapper tres simple d'un mutex posix.

//h

class POSIXMutex
{

public:

POSIXMutex();
~POSIXMutex();

void lock();
void unlock();
void try_lock();

pthread_t getCurrent() const;
pthread_mutex_t& getMutex();

private:

pthread_mutex_t mutex;
pthread_t tid;

};

//cpp

POSIXMutex::POSIXMutex() {

pthread_mutexattr_t mutex_attr;
memset(&mutex_attr,0,sizeof(mutex_attr));

if (pthread_mutexattr_init(&mutex_attr) != 0)
exit(EXIT_FAILURE);

if(pthread_mutexattr_settype(&mutex_attr,PTHREAD_MUTEX_RECURSIVE) != 0)
return;

pthread_mutex_init(&mutex, &mutex_attr);

};

POSIXMutex::~POSIXMutex() {
pthread_mutex_destroy(&mutex);
};

.../....

maintenant j'aimerai avoir un std::vector<POSIXMutex> gates;

je ne me rappelle plus les conditions necessaires (objet copiable?) pour
un vector.

et dans mon cas que dois je faire?

merci

4 réponses

1 2

Bruno Causse

09/09/2008 à 14:08

"Pascal J. Bourguignon" a écrit dans le message de
news:

Suppose qu'on mette un mutex par tranche de 100.

Fil 1:
table[1000]=table[0]+table[1];

Fil 2:
table[10]=table[1010]+table[1011];

Vérouillage mortel !

Si on en met un par entrée:

Fil 1:
s=table[0]+table[1];

Fil 2:
d=table[1]-table[0];

Vérouillage mortel !

oui bien sur, mais ma table ne s'utile pas comme ca :-)

c'est une table de transposition (une "espece" de memoire des calculs
anterieurs pour ne pas recommencer le meme calcul)

bon j'implemente et je teste.

merci

ps : je suis devant un nouveau choix :

1) je fais une copie de l'entree de la table pour l'utiliser dans un
contexte non "locké"
2) je lock l'entrée tant que j'en ai besoin.

James Kanze

09/09/2008 à 15:00

On Sep 9, 2:02 pm, Michael DOUBEZ wrote:

Pascal J. Bourguignon a écrit :

> "Bruno Causse" writes:
>> 1) un seul mutex : simplicité mais tres penalisant en perf

> D'accord, mais il faut d'abord que ça marche.

>> 2) un mutex par entrée : simplicité mais tres penalisant en
>> resource memoire
>> 3) une table limité de mutex decoupant ma table en tranche
>> : mix des deux solutions precedentes

[snip]
> Il suffit que deux fils accèdent à des tranches dans un ordre
> différent pour finir en vérouillage mortel.

Sauf si l'accès au mutex ne dure que le temps d'avoir la
valeur; cela suppose que les valeurs sont décorrélées (on peut
le supposer vu le nombre apparent d'accès concurrents -
2**11!!!! :) ).

Mais si le verouillage ne dure que le temps d'avoir la valeur,
un seul mutex ne doit pas être bien pénalisant.

> Donc ll faudra soit implémenter un système de transaction
> (avec détection des verrouillages mortels et retour en
> arrière), soit ne mettre qu'un verrou pour toute la table.

Une solution rapide est de déterminer les mutex à acquérir et
le faire dans un certain ordre (ascendant).

Ce qui suppose que tu définisse des transactions, et que tu
puisses savoir dès le début tous les éléments dont la
transaction aura besoin. C'est fragile.

--
James Kanze (GABI Software) email:
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

Michael DOUBEZ

09/09/2008 à 21:36

James Kanze a écrit :

On Sep 9, 2:02 pm, Michael DOUBEZ wrote:
Pascal J. Bourguignon a écrit :

"Bruno Causse" writes:
1) un seul mutex : simplicité mais tres penalisant en perf

D'accord, mais il faut d'abord que ça marche.

2) un mutex par entrée : simplicité mais tres penalisant en
resource memoire
3) une table limité de mutex decoupant ma table en tranche
: mix des deux solutions precedentes

[snip]
Il suffit que deux fils accèdent à des tranches dans un ordre
différent pour finir en vérouillage mortel.

Sauf si l'accès au mutex ne dure que le temps d'avoir la
valeur; cela suppose que les valeurs sont décorrélées (on peut
le supposer vu le nombre apparent d'accès concurrents -
2**11!!!! :) ).

Mais si le verouillage ne dure que le temps d'avoir la valeur,
un seul mutex ne doit pas être bien pénalisant.

Oui. Je suis dans l'hypothèse que ce n'est pas le cas. Dans un cas réel,
ce serait la première politique benchmarkée.

Donc ll faudra soit implémenter un système de transaction
(avec détection des verrouillages mortels et retour en
arrière), soit ne mettre qu'un verrou pour toute la table.

Une solution rapide est de déterminer les mutex à acquérir et
le faire dans un certain ordre (ascendant).

Ce qui suppose que tu définisse des transactions, et que tu
puisses savoir dès le début tous les éléments dont la
transaction aura besoin. C'est fragile.

C'est vrai. Mais dans le cas de mémorisation dans une application
scientifique comme ici, ça pourrait être suffisant: je connais à priori
les données dont j'ai besoin et celles que j'obtiens (données de
criblage ?).

Pour un système plus sûr, je ne vois pas comment se débrouiller sans un
système transactionnel.

--
Michael

James Kanze

10/09/2008 à 09:26

On Sep 9, 9:36 pm, Michael DOUBEZ wrote:

James Kanze a écrit :

[...]

>>> Donc ll faudra soit implémenter un système de transaction
>>> (avec détection des verrouillages mortels et retour en
>>> arrière), soit ne mettre qu'un verrou pour toute la table.

>> Une solution rapide est de déterminer les mutex à acquérir et
>> le faire dans un certain ordre (ascendant).

> Ce qui suppose que tu définisse des transactions, et que tu
> puisses savoir dès le début tous les éléments dont la
> transaction aura besoin. C'est fragile.

C'est vrai. Mais dans le cas de mémorisation dans une
application scientifique comme ici, ça pourrait être
suffisant: je connais à priori les données dont j'ai besoin et
celles que j'obtiens (données de criblage ?).

Pour un système plus sûr, je ne vois pas comment se
débrouiller sans un système transactionnel.

Tout à fait. Le tout, c'est de définir comment on ajoute des
éléments à la transaction, de façon à éviter les deadlocks.
(Typiquement, il faut prévoir le cas où on ne peut pas, et
effectuer un rollback.)

--
James Kanze (GABI Software) email:
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

1 2

un vector de classe

4 réponses

Veuillez sélectionner un problème