gpt4 book ai didi

objective-c - NSBlockOperation 的粒度状态

转载 作者:搜寻专家 更新时间:2023-10-30 19:49:27 26 4
gpt4 key购买 nike

我扩展了 NSOperationQueue 以允许添加带有特定 NSString 作为标识符的 NSBlockOperation

标识符值保存在用作注册表的 NSMutableArray 中。这就是我实现注册表的方式。

-(void)addOperation:(NSOperation *)operation withID:(NSString*)operationID 
{
@synchronized(self.queueReference)
{
[self.queueReference addObject:operationID]; // <-- just a mutable array
}

[operation setCompletionBlock:^(){
@synchronized(self.queueReference) {
[self.queueReference removeObject:operationID];
}
}];

[self addOperation:operation];
}

基本上我添加了一个完成 block ,它在特定操作完成时清理注册表。

但是,虽然这可行,但我需要向队列添加更多粒度。

我只使用带有 block 操作的队列,在 block 执行期间,我可能会根据执行情况向监听器发送不同的 NSNotification

我想要达到的目标:

调用者尝试将带有标识符的特定 NSBlockOperation 添加到队列中。如果队列已经有这样的标识符就不要添加 block ,调用类将自己设置为监听器。

缺少什么?检查标识符是不够的,可能会出现 NSBlockOperation 已经调度 NSNotification 但尚未调用完成 block 的情况。

所以调用者类询问队列,这表明标识符存在于注册表中,并且调用者错误地将自己设置为监听一个永远不会到达的通知,因为它已经被发送了。

场景将改为:调用者询问队列,它说“标识符在注册表中”但发送了 NSNotification。调用者将 NSBlockOperation 放入队列。

注册表的检查是通过一种简单的方法进行的:

-(BOOL)hasOperationWithID:(NSString*)operationID 
{
@synchronized(self.queueReference)
{
return [self.queueReference containsObject:operationID];
}
}

但此时我对如何扩展这种方法还不太了解。我正在编写的代码有点“学术”,它没有任何特定目的,只是我在尝试实验。因此我在代码中有很大的灵 active 。但这对我来说是一个全新的主题,所以请尽可能具体地说明建议实现的任何缺点。

最佳答案

看起来您当前的系统具有三个基本事件:

  • 操作被添加到队列中
  • 操作在执行时发送通知
  • 调用操作完成 block

除非队列本身显式监听任何可能由 block 发送的NSNotifications,否则它无法知道它们是否已经发生。 但是即使它确实在监听,NSNotifications 的观察者被调用的顺序也是不确定的。换句话说,即使队列监听通知并将其回调与入队/出队操作互锁,对于另一个客户端开始监听该 NSNotification 来说,它可能(并且最终会)仍然为时已晚,并且您会错误地拒绝操作。

考虑这个替代方案:不使用完成 block 来管理标识符列表,而是使用通知本身——让队列句柄发送通知。换句话说,让我们摆脱第三个事件,让通知发送为标识符列表维护承担双重职责。我想到的最简单的方法如下:

标题:

//
// SONotifyingOperationQueue.h
// NotifyingOpQueue
//

typedef void (^SOSendNotificationBlock)(NSDictionary* userInfo);
typedef void (^SONotifyingBlock)(SOSendNotificationBlock sendNotificationBlock);

@interface SONotifyingOperationQueue : NSOperationQueue

- (BOOL)addOperationForBlock:(SONotifyingBlock)block withNotificationName:(NSString*)notificationName;

@end

实现

//
// SONotifyingOperationQueue.m
// NotifyingOpQueue
//

#import "SONotifyingOperationQueue.h"

@implementation SONotifyingOperationQueue
{
NSMutableSet* _names;
}

- (BOOL)addOperationForBlock: (SONotifyingBlock)block withNotificationName: (NSString*)notificationName
{
notificationName = [[notificationName copy] autorelease];

BOOL shouldAdd = NO;
@synchronized(self)
{
_names = _names ? : [[NSMutableSet alloc] init];

if (![_names containsObject: notificationName])
{
[_names addObject: notificationName];
shouldAdd = YES;
}
}

if (shouldAdd)
{
NSBlockOperation* blockOp = [[[NSBlockOperation alloc] init] autorelease];

__block SONotifyingOperationQueue* blockSelf = self;

SOSendNotificationBlock notificationBlock = ^(NSDictionary* userInfo){
@synchronized(blockSelf)
{
[blockSelf->_names removeObject: notificationName];
// Sending the notification from inside the @synchronized makes it atomic
// with respect to enqueue operations, meaning there can never be a missed
// notification that could have been received.
[[NSNotificationCenter defaultCenter] postNotificationName: notificationName object: blockSelf userInfo: userInfo];
}
};

dispatch_block_t executionBlock = ^{
block(notificationBlock);
};

[blockOp addExecutionBlock: executionBlock];
[self addOperation: blockOp];
}

return shouldAdd;
}

- (void)dealloc
{
[_names release];
[super dealloc];
}

@end

此方法对您的原始方法进行了多项更改。首先,这里的 API 添加 block 而不是 NSOperations。您可以对 NSOperation 子类执行相同的操作,但代码会更多,并且不会改变整体模式。它还合并了标识符和通知名称的概念。如果一个操作可以发送多个不同的 NSNotifications,如果不进行修改,这将无法工作,但同样,整体模式将是相同的。这种模式的重要特征是你的 id/name 检查现在与通知发送本身互锁,提供了强有力的保证,如果有人去添加一个新的 block /操作到队列,以及另一个具有相同 id/name 的操作还没有触发它的通知,新的操作不会被添加,但是如果通知已经被触发,那么它将被添加,即使前面的 block 尚未完成。

如果 NSOperation 对象在这里很重要,您也可以让这里的方法返回它为提供的 block 创建的操作。

HTH.

关于objective-c - NSBlockOperation 的粒度状态,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13950349/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com