Thread-safe variables statiques objective c

Est-il une manière objective C que je peux définir un static int qui est thread-safe?

par exemple si j'ai de la classe appelée Session:

static unsigned int session_id = 1000;

- (int) generateSessionID{
        return session_id++;
}

Je suis la construction d'objets de session à partir de threads différents, chaque objet session
doit avoir un id unique.

Vous avez besoin d'utiliser une sorte de sémantique de verrouillage. Le problème est que vous voulez l'opération atomique. Mais gardez à l'esprit que "++" n'est pas atomique, c'est un peu d'opérations à la fois.
est possible alors d'entourer mon retour session_id++ avec synchronisée(self){return session_id++}. Cependant, je ne suis pas sûr si cela va de verrouillage de la classe ou de l'objet lui-même.
comme l'a écrit, il serait de verrouillage de l'instance, et non pas la classe (pas ce que vous voulez). Peut-être "@synchronized([self class])"?
Gelhar: non, ne pas synchroniser sur [self class] parce que les instances de sous-classes synchroniser sur différents objets de la classe. Synchroniser sur un explicite de la classe par exemple [MyClass class]

InformationsquelleAutor Unis | 2010-10-28

objective-c thread-safety

5

Si vous parlez de Cacao, le mutex de fonctionnalités fournies par NSLock et NSRecursiveLock.

Afin de bien protéger les non-atomique de ressources, vous avez besoin de ces mutex, de peur que plusieurs threads peuvent essayer de changer les données en même temps (conduisant à la corruption) ou utiliser les données dans un demi-changé d'état (conduisant à des données non valides).

Votre code devrait ressembler à quelque chose comme ceci:
```
static NSLock session_id_lock;
static unsigned int session_id = 1000;

- (int) generateSessionID{
    int new_id;
    [myLock lock];
    new_id = session_id++;
    [myLock unlock];
    return new_id;
}
```
Si vous n'êtes pas à l'aide de Cacao (ou de ce que peu de Cacao en programmation je me souviens de mon bref intermède avec un iMac est donc le vague souvenir que c'est quasi inutile), il suffit d'utiliser le concept, de le traduire en quelque langue que ce soit cadre ou vous avez:
- verrouiller le mutex avant d'utiliser ou de la modification d'une ressource protégée.
- d'utiliser ou de modifier la ressource.
- déverrouille le mutex.
- bonus de conseils 1: verrouiller le mutex plus tard possible et déverrouillez-la dès que possible.
- bonus conseils 2: verrouiller uniquement ce dont vous avez besoin, de manière à éviter les retards inutiles.
Expliquant que le dernier point de plus: si vous synchroniser sur self pour deux totalement sans rapport avec les choses (disons un ID de session et un ID d'utilisateur), ils vont bloquer les uns les autres malgré le fait qu'il n'est pas nécessaire de le faire. Je préfère deux mutex pour garder la granularité faible.

Bien sûr, si vous avez seulement un mutex sur l'ID de session seul (mais voir ci-dessous pour la mise en garde), n'hésitez pas à utiliser synchronized(self) mais je préfère le faire à ma façon, je ne voudrais pas attraper de l'ajout d'une autre ressource protégée plus tard.

En tout cas (c'est l'inconvénient mentionné), vous trouverez probablement que la synchronisation sur self ne serait pas protéger adéquatement une variable statique, ce qui serait partagé entre plusieurs objets. Le mutex doit appartenir à la données plutôt que tout ce qui est de l'utiliser.
- Je viens de monde Java, où vous pouvez faire: static synchronized int generateID(){return id de session++}. est-ce compatible si je n' -(int) generateSessionID{synchronized(self){return session_id++;}}?
- Je pense à ce qui serait ok si un verrou sur soi (l'objet) est probablement plus large que je le ferais. Au lieu de cela, je préfère un mutex spécifique de manière à éviter les mutex les retards qui ont été inutiles (voir mon bonus, conseils).
- À proximité, mais vous ne voulez pas synchroniser sur self pour une méthode d'instance qui est de l'accès à une variable statique; peut-être la fonction de synchronisation de [self class], ou sur un objet qui est directement associée à la valeur en cours de modification (par exemple, envelopper les int dans un NSNumber et de synchronisation sur le NSNumber).
- Ah, bon point, j'ai oublié qu'il était statique qui pourrait être utilisé par plusieurs objets - je vais ajuster la réponse.
- David, je vois votre point de vue et j'ai pensé que de l'habillage ou la déclaration de l'un NSNumber au lieu de int, mais où/quand vous relâchez le NSNumber comme il le sera (peut être) accessible en construisant d'autres objets pour générer leurs papiers d'identité.
- Je ne pense pas que vous auriez besoin de vous soucier de le relâcher. Vous pouvez créer il & initialiser à 0 dans un +initialize method (voir stackoverflow.com/questions/992070/...); mais une fois créé, il ne va pas loin.
- Pensez à utiliser le PGCD de dispatch_semaphore_create au lieu de NSLock. Ces peut être verrouillé ou déverrouillé à partir de n'importe quel thread, contrairement à NSLock qui doit être utilisé sur le même thread toujours.
- selon @JeremyP dans un commentaire sur la question, vous devez synchroniser sur [MyClass class], pas [self class]. Il semble @JeremyP dit [self class] sera de retour un objet différent à chaque fois, pas un singleton.
- ce JeremyP est en train de dire n'est pas que [self class] retourne un objet différent à chaque fois. Il dit que si vous avez une sous-classe MySubclass qui hérite de Maclasse, [self class] sera de retour [MySubclass class] lorsqu'il est appelé à partir d'une instance de MySubclass. C'est un argument valable.
InformationsquelleAutor paxdiablo
9

Je pense que vous feriez mieux de les utiliser les opérations atomiques de modifier session_id. Un question précédente parle atomique incrémenter/décrémenter les opérations pour OS X, et cette page parle de la OSAtomic fichier d'en-tête. Les opérations atomiques sur des entiers, quelque chose qui est facilement le matériel pris en charge, sera probablement sensiblement plus rapide que d'utiliser le verrouillage de constructions.
- D'accord. Si tout ce que vous avez à faire est de garder autour d'un statique pour les fins de l'obtention d'un mondial de l'incrémentation de la valeur, de l'utilisation OSAtomicIncrement32, qui sera à l'abri et ne pas avoir tous les frais généraux de Cacao ou POSIX primitives de synchronisation.
- developer.apple.com/library/mac/#DOCUMENTATION/Cocoa/Conceptual/...
InformationsquelleAutor Wyatt Anderson
2

Une réponse 4 ans plus tard, actuellement en iOS8. :o)
Le mieux pour moi est d'utiliser une classe singleton comme suit :

(monfichier.h)
```
#import <Foundation/Foundation.h>

@interface singletonSessionId : NSObject

+ (singletonMsgNbr*)sharedSingleton;

- (void)generateSessionId;

@property NSInteger value;

@end
```
=====================================================
(monfichier.m)
```
#import "singletonSessionId.h"

@implementation singletonSessionId
@synthesize value = _value;

+ (singletonMsgNbr*)sharedSingleton {

    static singletonSessionId *instance = nil;

    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        instance = [[singletonSessionId alloc]init];
        instance.value = 1000;
    });

    return instance;
}

- (void)generateSessionId {
    _value += 1;
}

@end
```
Vous avez juste besoin d'appeler la méthode 'generateSessionId" pour chaque nouvelle valeur de l'Id.
À l'aide de cette classe pour créer votre Id de session doit être assez loin je pense.

Espère que ça aidera les lecteurs de ce post. :o)

MODIFIER

Comme indiqué par certains lecteurs, la NSInteger "valeur" n'est pas thread-safe suivant ce chemin, seul le singleton est.

Pour obtenir un "thread-safe "valeur" variable d'instance juste changer sa NSInteger type dans NSNumber (pour être converti en int avec des méthodes appropriées) qui est complètement thread-safe selon la documentation d'Apple.

Ce peut être le plus simple et le plus rapide pour obtenir ce qui est désiré.
- en effet, et c'est exactement ce qu'il doit faire => " Vous avez juste besoin d'appeler la méthode 'generateSessionId" pour chaque nouvelle valeur de l'Id'.
- Désolé pour la réponse tardive, il fonctionne comme un charme, j'ai fait une erreur seulement.
- Est-ce "thread-safe"? Supposons que thread1 appels generateSessionID, puis thread2 appels generateSessionID avant thread1 a eu la chance de récupérer la valeur? N'auraient-ils pas à la fois être en utilisant le même identifiant? Et si elles font toutes deux appel à la méthode dans le même temps, n'est-ce pas là le potentiel pour corruption de la mémoire car aucun outil de synchronisation est utilisé?
- dispatch_once va bloquer tous les appels jusqu'à ce que l'un d'entre eux réussit. Les docs disent "Si on l'appelle simultanément à partir de plusieurs threads, cette fonction attend en mode synchrone jusqu'à ce que le bloc est terminé." En fait, la méthode a été spécialement conçu pour ce cas d'utilisation: "Cette fonction est utile pour l'initialisation des données globales (singletons) dans une application. Toujours appeler cette fonction avant de l'utiliser ou tester les variables sont initialisées par le bloc."
- Ce n'est pas thread-safe exactement pour la raison que @jk7 unis. Le dispatch_once n'a rien à voir avec lui, car il n'est pas appelé lors de l'appel de generateSessionId
- est droit. À l'époque, je pensais en avoir une parfaite thread-safe singleton a été suffisant pour générer et d'incrémenter une variable dans un thread de façon sécuritaire. Ce n'est certainement pas le cas. À mon avis, la meilleure façon de lire et d'écrire une variable d'instance, sans condition de course est d'utiliser le "dispatch_barriers' fonctionnalité fournie par Grand Central Dispatch. Quelques choses à être mis en œuvre, mais un résultat qui sera sûr à 100%.
InformationsquelleAutor XLE_22
1

Il existe de nombreuses options, y compris (de haut niveau de plus bas niveau) le @synchronized Objective-C de la directive, NSLock, pthread_mutex_lock, et des opérations atomiques.

Lire la "Synchronisation" de la Filetage Guide De Programmation pour plus de détails.

InformationsquelleAutor David Gelhar

Vous devez vous connecter pour publier un commentaire.