›

property nonatomic et iPhone OS

GreensourceGreensource Membre
07:08 modifié dans API UIKit #1
Bonjour, je me posais une question en lisant la doc d'Apple. Par défaut une property est atomic pour éviter les accès concurrent dans un environnement Multi-Thread, bien.
A propos de l'iPhone OS maintenant, ce système n'est pas multi-Thread il me semble? Donc il ne peut y avoir d'accès concurrent.
Est-ce pour ça que souvent j'en voit mettre ce mot clé lors des définitions des property? C'est par souci de performance? Puisque sinon c'est juste une sécurité en plus pourquoi ne pas laissé l'atomicité des accesseurs?

Voilà , je crois avoir fait le tour de mon questionnement,
Pierre

Réponses

  • AliGatorAliGator Membre, Modérateur
    07:08 modifié #2
    Rien n'empêche de faire multi-thread en iPhoneOS. C'est tout à  fait possible.
    Je pense que tu confond avec l'impossibilité sur iPhone d'avoir plusieurs process lancés en même temps.
    Mais au sein d'un même process, tu peux tout à  fait avoir plusieurs threads, ça pas de soucis.

    D'ailleurs la classe NSThread est présente dans le SDK iPhone, ce qui te permettre par exemple (entre autres) de lancer un traitement qui peut être long en "tâche de fond" (ne pas confondre avec "process de fond" ou "background task" en anglais aussi appelé "daemon"), tout en continuant d'effectuer d'autres opérations.

    ---

    Par exemple, c'est ce qui se passe implicitement quand tu effectue une requête asynchrone genre requête HTTP : la requête HTTP est envoyée, mais ton programme continue (tu peux par exemple continuer à  "cliquer" ou bouger dans ton interface etc...) et pendant ce temps ta requête tourne toujours et reçoit les données au fur et à  mesure qu'elles arrivent, jusqu'à  te signaler à  la fin que toutes tes données sont arrivées. Si c'était synchrone et qu'il n'y avait pas de thread derrière, ton appli serait totalement bloquée le temps que toutes les données soient reçues (par exemple que toute la page web soit chargée si c'est une requête HTTP d'une page web) !
  • GreensourceGreensource Membre
    07:08 modifié #3
    Mais dans ce cas il n'y a aucun risque de d'appel simultanée à  une méthode, puisqu'il n'y a pas de vrai traitement parallèle?
  • AliGatorAliGator Membre, Modérateur
    07:08 modifié #4
    Si si il y a un traitement parallèle quand même, c'est du multi-thread, comme ça existe sous OSX.

    Une méthode d'un thread peut tout à  fait être interrompue en plein milieu par un autre thread qui exécute son propre code, puis reprendre après, d'où le risque d'accès concurrentiel.
    D'où la nécessité dans ces cas de protéger tes variables avec des Mutex, des @synchronized ou du genre, ou en définissant les @property en atomic (enfin en ne définissant pas l'attribut nonatomic quoi) pour que lorsqu'il @synthetize les accesseurs à  ces variables, qu'il rajoute les @synchronize tout seul dans le code généré.

    Bref, si ton appli iPhone est multithreadée, il faut, comme dans tout programme multi-threadé (iPhone ou pas), protéger tes variables qui pourraient être accédées de façon concurrentielle par de multiple threads à  la fois.

    Aucune différence sur ce point entre iPhone et OSX ou toute autre plateforme gérant le multihreading.
  • GreensourceGreensource Membre
    07:08 modifié #5
    Ah bas oui en effet. J'avais un peu zappé le fait que quand un Thread stoppais un autre pouvais entré dans le même code.  :)
    Merci pour ces précisions.
  • BaardeBaarde Membre
    07:08 modifié #6
    dans 1236445003:

    Rien n'empêche de faire multi-thread en iPhoneOS. C'est tout à  fait possible.
    Je pense que tu confond avec l'impossibilité sur iPhone d'avoir plusieurs process lancés en même temps.
    Mais au sein d'un même process, tu peux tout à  fait avoir plusieurs threads, ça pas de soucis.

    Je dirais plutôt l'impossibilité d'avoir plusieurs applications lancées en même temps (et de créer de nouveaux process en utilisant les API publiques).
Connectez-vous ou Inscrivez-vous pour répondre.