Et quand je vais parcourir mon tableau pour le mettre à jour, pas de problème pour A mais B va être mis à jour avec les éléments de C et C ne sera pas mis à jour...
L'idée serait de créer un NSDictionary avec une clé pour identifier chaque update et du coup quand on parcours le tableau on utilise cette clé pour faire correspondre les bons updates. Cependant ça ne résoud pas le problème du fait que B ne sera mis à jour qu'à la prochaine mise à jour...
Le fait que l'update ne doit surtout pas être faite s'il y a eu une modification est ce qu'il y a de plus problématique... L'algorithme ne garantit pas ça car il peut arriver par extrême malchance que juste derrière le "if([NSThread currentThread]==self.lastThread)", un nouveau thread fasse "self.lastThread = [NSThread currentThread];" auquel cas, les 2 threads verront leurs calculs validés (dans mon cas c'était pas trop grave... les indications n'étaient juste pas en phase pendant le temps de calcul du nouveau thread).
Je ne sais pas si c'est résoluble sans utiliser @synchronize du coup...
* Un "add" empêche tout "update" en mettant "lastThread" à nil * Un update ne se fait que s'il provient vraiment du lastThread du moment où on fait l'update * Seul le thread principal touche à "lastThread", donc il ne risque pas de changer pendant les exécutions de "add" ou "update"
Ok super, merci pour le temps que tu as consacré à mon problème !
J'avoue avoir un peu de mal à tout comprendre, faut que je me forme sur la manipulation des threads via cocoa... J'ai lu la Doc Apple plutôt bien faite mais je n'ai pas encore saisi toutes les subtilités.
En fait j'ai simplifié le problème : - tout ajout effectué entre la construction de l'URL et la mise à jour est suffisamment à jour pour ne pas nécessiter la relance de la dernière mise à jour. - par contre il faut que cette dernière ne prenne pas en compte les éléments fraà®chement ajoutés.
Réponses
Petit exemple :
J'ai un tableau [A, C], je construit une URL avec les éléments de maj pour A et C. Entre temps ce vicieux d'utilisateur fait ça [A, B, C]...
Quand les updates vont arriver, ils seront de la forme (NSString *):
@A.champ1, ..., A.champN; C.champ1, ..., C.champN;
Et quand je vais parcourir mon tableau pour le mettre à jour, pas de problème pour A mais B va être mis à jour avec les éléments de C et C ne sera pas mis à jour...
L'idée serait de créer un NSDictionary avec une clé pour identifier chaque update et du coup quand on parcours le tableau on utilise cette clé pour faire correspondre les bons updates. Cependant ça ne résoud pas le problème du fait que B ne sera mis à jour qu'à la prochaine mise à jour...
L'algorithme ne garantit pas ça car il peut arriver par extrême malchance que juste derrière le "if([NSThread currentThread]==self.lastThread)", un nouveau thread fasse "self.lastThread = [NSThread currentThread];" auquel cas, les 2 threads verront leurs calculs validés (dans mon cas c'était pas trop grave... les indications n'étaient juste pas en phase pendant le temps de calcul du nouveau thread).
Je ne sais pas si c'est résoluble sans utiliser @synchronize du coup...
* Un "add" empêche tout "update" en mettant "lastThread" à nil
* Un update ne se fait que s'il provient vraiment du lastThread du moment où on fait l'update
* Seul le thread principal touche à "lastThread", donc il ne risque pas de changer pendant les exécutions de "add" ou "update"
J'avoue avoir un peu de mal à tout comprendre, faut que je me forme sur la manipulation des threads via cocoa... J'ai lu la Doc Apple plutôt bien faite mais je n'ai pas encore saisi toutes les subtilités.
En fait j'ai simplifié le problème :
- tout ajout effectué entre la construction de l'URL et la mise à jour est suffisamment à jour pour ne pas nécessiter la relance de la dernière mise à jour.
- par contre il faut que cette dernière ne prenne pas en compte les éléments fraà®chement ajoutés.