NSLock "controller" class

Question

J'écris une application multithread pour iPhone, et j'utilise NSLock's pour m'assurer que certaines opérations (comme charger des sons à partir d'un fichier) se comporteront comme des atomes. Pour simplifier l'acquisition de verrous à partir de différentes parties de mon application, j'ai écrit la classe suivante, qui me permet de verrouiller et de débloquer des verrous simplement en passant NSString avec le nom. Si un tel verrou n'existe pas, il le crée et l'enregistre pour l'avenir. Je l'ai testé et il semble fonctionner correctement (car il donne juste accès aux objets NSLock et ne modifie pas leur comportement).

Ma question est la suivante: est-il acceptable d'avoir et d'utiliser une telle classe, ou ai-je un malentendu dans le concept de serrures?

Locker.h 

#import <Foundation/Foundation.h> 

@interface Locker : NSObject { } 

+ (void) purgeLocks; 
+ (NSLock*) lockWithName: (NSString*) name; 
+ (void) lock: (NSString*) name; 
+ (void) unlock: (NSString*) name; 
+ (BOOL) tryLock: (NSString*) name; 

@end 



Locker.m 

#import "Locker.h" 

static NSMutableDictionary* locks = nil; 

@implementation Locker 

+ (void) initialize { 
    locks = [[NSMutableDictionary dictionary] retain]; 
} 

+ (void) purgeLocks { 
    [locks release]; 
    [Locker initialize]; 
} 

+ (NSLock*) lockWithName: (NSString*) name { 
    NSLock* lock = nil; 
    @synchronized([Locker class]) { 
     lock = [locks objectForKey: name]; 
     if(!lock) { 
      lock = [[[NSLock alloc] init] autorelease]; 
      [lock setName: name]; 
      [locks setObject: lock forKey: name]; 
     } 
    } 
    return lock; 
} 

+ (void) lock: (NSString*) name { 
    [[Locker lockWithName: name] lock]; 
} 

+ (void) unlock: (NSString*) name { 
    [[Locker lockWithName: name] unlock]; 
} 

+ (BOOL) tryLock: (NSString*) name { 
    return [[Locker lockWithName: name] tryLock]; 
} 

@end 

Answer 1

Cela me semble assez lourd. Êtes-vous sûr de ne pas pouvoir simplifier la conception? (GCD vient à l'esprit.) Presque chaque application iOS est multithread, et à mon humble avis, il est rare de voir de tels assistants de verrouillage que vous avez écrit. S'il y a un endroit où le KISS principle brille, je suis sûr que c'est multithreading.

Answer 2

@synchronized is slow, évitez-le. Attribuez un verrou au + initialize et utilisez-le à la place. Mais j'irais pour un singleton au lieu d'utiliser des méthodes de classe, mais c'est plus ou moins une question de goût.

L'inconvénient majeur de votre approche est que vous devez verrouiller un verrou pour obtenir un autre verrou. Dans une application fortement multi-threadée, ce méta-verrou (votre @synchronized actuel) peut devenir un goulot d'étranglement des performances même si les threads veulent tous accéder à des verrous différents.