2010-06-07 6 views
5

Я понял, что двойная проверенная блокировка испорчена в java из-за модели памяти, но это обычно связано с одноэлементным рисунком и оптимизацией создания синглтона.Двойная проверка блокировки - объектив c

А что при этом в Objective-C:

У меня есть булева флаг, чтобы определить, является ли мое приложение потоковой передачи данных или нет. У меня есть 3 метода, startStreaming, stopStreaming, streamingDataReceived и я защитить их от нескольких потоков с помощью:

- (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) { 

Это двойная проверка uneccessary? Имеет ли двойная проверка аналогичные проблемы в объекте-c, как в java? Каковы альтернативы этому шаблону (анти-шаблон).

Благодаря

ответ

2

Это в равной степени недостатков - у вас есть состояние гонки

Вы должны ввести свой синхронизированный раздел, а затем проверить флаг

+0

Можете ли вы обосновать этот ответ? –

+0

Вы можете продлить ответ, чтобы добавить предложения для альтернатив. Например, существует ли эквивалент «переходный» или AtomicInteger/etc в Objective-C? –

0

Это выглядит как преждевременная оптимизация для меня. Что случилось с (например)

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

Я избегал затрат на ввод синхронизированного блока, если это не было необходимо. – bandejapaisa

+0

Вот что я имел в виду под «преждевременной оптимизацией». Почему вы заботитесь о стоимости входа в синхронизированный блок, если вы не измерили его с помощью профилировщика, и это заняло значительное количество времени? – JeremyP