2

私は iPhone 用のマルチスレッド アプリケーションを作成しており、NSLock を使用して、一部の操作 (ファイルからサウンドをロードするなど) がアトミックに動作するようにしています。アプリケーションのさまざまな部分から簡単にロックを取得するために、次のクラスを作成しました。これにより、名前を指定して NSString を渡すだけでロックをロックおよびロック解除できます。そのようなロックが存在しない場合は、それを作成して将来のために保存します。私はそれをテストしましたが、うまく動作しているようです (NSLock オブジェクトへのアクセスを提供するだけで、その動作を変更しないため)。

私の質問は、そのようなクラスを持って使用しても大丈夫ですか、それともロックの概念に誤解がありますか?

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
4

2 に答える 2

1

@synchronized遅いので避けてください。ロックインを割り当てて、+ initialize代わりにそれを使用します。しかし、私はクラス メソッドを使用する代わりにシングルトンを使用しますが、それは多かれ少なかれ好みの問題です。

このアプローチの主な欠点は、別のロックを取得するためにロックをロックする必要があることです。@synchronized非常にマルチスレッドなアプリでは、スレッドがすべて異なるロックにアクセスしたい場合でも、このメタロック (現在の) がパフォーマンスのボトルネックになる可能性があります。

于 2011-09-15T07:06:48.807 に答える
0

これは私にはかなり重く見えます。設計を単純化できないと確信していますか? (GCD が頭に浮かびます。) ほとんどすべての iOS アプリケーションはマルチスレッド化されたアプリケーションであり、私見では、あなたが書いたようなロック ヘルパーを目にすることはめったにありません。KISS の原理が光る場所があるとすれば、それはマルチスレッドであることは間違いありません。

于 2011-09-15T07:16:19.963 に答える