2010-06-07 3 views
5

J'ai réalisé que le verrouillage double est défectueux dans Java en raison du modèle de mémoire, mais il est généralement associé au motif singleton et optimise la création du singleton.double vérification du verrouillage - objectif c

Qu'en est-il dans ce cas-c Objectif:

J'ai un drapeau booléen pour déterminer si ma demande est en streaming des données ou non. J'ai 3 méthodes, startStreaming, stopStreaming, streamingDataReceived et je les protégerai de plusieurs threads en utilisant:

- (void) streamingDataReceived:(StreamingData *)streamingData { 
    if (self.isStreaming) { 
     @synchronized(self) { 
      if (self.isStreaming) { 

- (void) stopStreaming { 
    if (self.isStreaming) { 
     @synchronized(self) { 
      if (self.isStreaming) { 

- (void) startStreaming:(NSArray *)watchlistInstrumentData { 
    if (!self.isStreaming) { 
     @synchronized(self) { 
      if (!self.isStreaming) { 

Est-ce double contrôle uneccessary? Le double contrôle a-t-il des problèmes similaires en Objective-C et en Java? Quelles sont les alternatives à ce modèle (anti-pattern).

Merci

Répondre

2

Il est également erroné - vous avez une condition de course

Vous devez entrer dans votre section synchronisée puis vérifiez le drapeau

+0

Pouvez-vous justifier cette réponse? –

+0

Vous pouvez étendre la réponse pour ajouter des suggestions d'alternatives. Par exemple, y at-il un équivalent de "transitoire" ou AtomicInteger/etc dans Objective-C? –

0

Cela ressemble à une optimisation trop tôt pour moi. Quel est le problème avec (par exemple)

- (void) startStreaming:(NSArray *)watchlistInstrumentData { 
     @synchronized(self) { 
      if (!self.isStreaming) { 
... 
+0

J'évitais le coût de l'entrée du bloc synchronisé si ce n'était pas nécessaire. – bandejapaisa

+0

C'est ce que je voulais dire par "optimisation prématurée". Pourquoi vous soucieriez-vous du coût de la saisie du bloc synchronisé à moins que vous ne l'ayez mesuré avec un profileur et que cela prenait beaucoup de temps? – JeremyP