[Conception] Un thread charge en fond...

Réponses

• AliGator Membre, Modérateur

  avril 2006 avril 2006 modifié #2

  Mais pourquoi tu ne veux pas utiliser les sections critiques ??
  C'est précisément fait pour ça !!
  
  Je viens de rechercher "Critical Section" dans la doc Apple, et de découvrir l'existence de @synchronized qui semble répondre justement à  ton besoin
• System

  avril 2006 07:57 modifié #3

  Je ne comprends pas le @synchronized(self) { }
  
  Il bloque tous les accès à  self quand deux threads rentrent en même temps dans le @synchronized(self) (nslock normal) (ce qui n'est pas mon cas) ou lorsqu'un thread rentre dans le  @synchronized(self) aucun autre thread ne peux utiliser l'instance self tant que le thread n'est pas sorti du @synchronized() (et la c'est mon cas en effet).
  
  
• System

  avril 2006 avril 2006 modifié #4

  dans 1145007822:

  
  Il bloque tous les accès à  self quand deux threads rentrent en même temps dans le @synchronized(self) (nslock normal) (ce qui n'est pas mon cas) ou lorsqu'un thread rentre dans le  @synchronized(self) aucun autre thread ne peux utiliser l'instance self tant que le thread n'est pas sorti du @synchronized() (et la c'est mon cas en effet).
  

  
  
  

  dans 1145006389:

  
  Je viens de rechercher "Critical Section" dans la doc Apple, et de découvrir l'existence de @synchronized qui semble répondre justement à  ton besoin
  

  
  
  J'ai dis quelque chose de trop ou une j'ai une mauvaise lecture de l'anglais ??
  Je ne comprends pas comment fonctionne exactement le @synchronized(self) ?
• AliGator Membre, Modérateur

  avril 2006 avril 2006 modifié #5

  En fait je ne me suis pas plus penché sur la question, je t'ai juste mis en coup de vent le fruit de mes recherches.
  Chacha pourrait certainement t'en dire plus vu qu'apparament il a déjà  utilisé NSLock, @synchronized et ses confrères (là  et là ).
  
  Mais sinon j'ai pas non plus trop compris l'utilisation de "self" avec @synchronized. Enfin si,j'ai compris, tu te sers de "self" comme d'un mutex, mais je trouve que c'est le meilleur moyen de se gourrer et de faire des confusions...
  Moi j'utiliserai plutôt un objet dédié qui servira de sémaphore (dans ton cas, d'un mutex), comme dans l'exemple mis ici.
  Donc tu te crées un objet (un sémaphore) nommé par ex "mutex" et tu places tes sections critiques dans un @syncronized(mutex), même mutex pour tes 2 threads. Comme ça Cocoa fera en sorte que tes 2 threads ne puissent jamais être dans une section critique ayant le même mutex en même temps (si un des threads est dans un bloc critique, l'autre attendra avant d'y rentrer)
• Eddy58 Membre

  avril 2006 07:57 modifié #6

  Perso, la question que je me pose sur le sujet : Est-ce que @synchronized est une autre façon de faire un NSLock/NSUnlock où ça apporte autre chose, et dans ce cas quoi ? ???
• AliGator Membre, Modérateur

  avril 2006 07:57 modifié #7

  Eh bien disons que je ne sais pas si j'ai la bonne vision, mais pour moi :
  - Un NSLock c'est plutôt pour protéger une ressource
  - Une section critique c'est tout une partie de code qui ne devrait être executée que par un thread à  la fois.
  Mais il se trouve que les sections critiques sont souvent implémentées par des NSLocks.
  
  Donc en fait fondamentalement c'est la même chose que les NSLocks, c'est juste une façon plus propre/simple/...

  In addition to lock classes, the Objective-C language includes the @synchronized directive for locking a block of code. The directive takes a single parameter, which is the object you want to be used as the key for locking the code. The compiler then creates a mutex lock based on that object.

  Si jamais t'as pas encore lu ce doc, ça pourra peut-être t'éclaircir les idées.
  
  En gros utiliser @synchronized ou utiliser des NSLocks au final ça ne doit rien changer, c'est juste que @synchronized semble dédié aux sections critiques.
• Eddy58 Membre

  avril 2006 07:57 modifié #8

  D'aprés ce que j'ai lu, @synchronized n'est effectivement rien de plus qu'une autre manière de faire un lock. Sur CocoaDev, il est dit que cette directive permet une synchronisation plus propre, mais que c'est moins rapide que NSLock, de plus cela demande apparemment l'implémentation d'un gestionnaire d'exceptions pour bien faire les choses :
  

  
  As a precautionary measure, the @synchronized block implicitly adds an exception handler to the protected code. This handler automatically releases the mutex in the event that an exception is thrown. However, this means that you must enable Objective-C exception handling in your code to use this directive. If you do not want the additional overhead caused by the implicit exception handler, you should consider using the lock classes.
  
• System

  avril 2006 07:57 modifié #9

  dans 1145007822:

  
  

  dans 1145006389:

  
  Je viens de rechercher "Critical Section" dans la doc Apple, et de découvrir l'existence de @synchronized qui semble répondre justement à  ton besoin
  

  
  J'ai dis quelque chose de trop ou une j'ai une mauvaise lecture de l'anglais ??
  Je ne comprends pas comment fonctionne exactement le @synchronized(self) ?
  

  
  
  Et oui donc retour au point de départ on sait juste que @synchronized() existe et qu'en gros qu'il n'apporte rien si ce n'est un gros tas de nouilles... Plus propre en quoi ? On ne sait pas ce qu'il fait ?!
  
• Eddy58 Membre

  avril 2006 07:57 modifié #10

  dans 1145299243:

  
  Plus propre en quoi ? On ne sait pas ce qu'il fait ?!
  

  
  C'est aussi une question que je me pose...:P
  Mais comme apparemment ça n'apporte pas d'avantage certain, je suis plus partisan de NSLock.
  
  

  
  Je ne veux toujours pas utiliser les nslock
  

  
  Pourquoi ne veux tu pas utiliser cette classe ? ???