ios creating a write lock based on a key

Question

I know about using dispatch_barrier_async to lock a given resource, but in my case it isn't a good candidate because I am not modifying a shared data structure, rather a resource on disk and don't want to block the whole queue, rather just a given key as the action could take a long time. I'm not certain how the file system works pertaining to accessing the same file (by name) from several threads simultaneously and couldn't find a clear answer in the documentation, just best practices. I think I would like to lock by "file name" - and am missing a method "tryLock(key)"

Something like:

-(void)readFileAtPath:(NSString *)path completion:(void(^)(NSData *fileData))completion
{
   dispatch_async(self.concurrentQueue,^{
       // acquire the lock for a given key and block until can acquire
       trylock(path);
       NSData *fileData = [self dataAtPath:path];
       unlock(path);
       completion(fileData);
   });
}

-(void)writeData:(NSData *)data toPath:(NSString *)path completion:(void(^)())completion
{
    dispatch_async(self.concurrentQueue,^{
        // if someone is reading the data at 'path' then this should wait - otherwise should write
        trylock(path);
        [data writeToFile:path atomically:YES];
        unlock(path);
        completion();
    });
}

EDIT:

Does @synchronized do this? Is this a proper use case?

Answer 1

If you want to create "scoped queues", just do it. Create a serial queue for each file, and have them target your concurrent queue. It might look like this:

@interface Foo : NSObject
@property (readonly) dispatch_queue_t concurrentQueue;
@end

@implementation Foo
{
    NSMutableDictionary* _fileQueues;
    dispatch_queue_t _dictGuard;
}

@synthesize concurrentQueue = _concurrentQueue;

- (instancetype)init
{
    if (self = [super init])
    {
        _concurrentQueue = dispatch_queue_create(NULL, DISPATCH_QUEUE_CONCURRENT);
        _dictGuard = dispatch_queue_create(NULL, DISPATCH_QUEUE_SERIAL);
        _fileQueues = [[NSMutableDictionary alloc] init];
    }
    return self;
}

- (dispatch_queue_t)queueForFile: (NSString*)path
{
    __block dispatch_queue_t retVal = NULL;
    dispatch_sync(_dictGuard, ^{
        retVal = _fileQueues[path];
        if (!retVal)
        {
            retVal = dispatch_queue_create(path.UTF8String, DISPATCH_QUEUE_SERIAL);
            dispatch_set_target_queue(retVal, self.concurrentQueue);
            _fileQueues[path] = retVal;
        }
    });
    return retVal;
}

- (void)doStuff: (id)stuff withFile: (NSString*)path
{
    dispatch_queue_t fileQueue = [self queueForFile: path];
    dispatch_async(fileQueue, ^{
        DoStuff(stuff, path);
    });
}

@end

That said, this queue-per-file thing has a little bit of a "code smell" to it, especially if it's intended to improve I/O performance. Just off the top of my head, for max performance, it feels like it would be better to have a queue per physical device than a queue per file. It's not generally the case that you as the developer know better than the OS/system frameworks how to coordinate file system access, so you will definitely want to measure before vs. after to make sure that this approach is actually improving your performance. Sure, there will be times when you know something that the OS doesn't know, but you might want to look for a way to give the OS that information rather than re-invent the wheel. In terms of performance of reads and writes, if you were to use dispatch_io channels to read and write the files, you would be giving GCD the information it needed to best coordinate your file access.

It also occurs to me that you also might be trying to 'protect the application from itself.' Like, if you were using the disk as a cache, where multiple tasks could be accessing the file at the same time, you might need to protect a reader from another writer. If this is the case, you might want to look for some existing framework that might address the need better than rolling your own. Also, in this use case, you might want to consider managing your scope in-application, and just mmaping one large file, but the cost/benefit of this approach would depend on the granule size of your files.

It would be hard to say more without more context about the application.

To your follow-on question: @synchronized could be used to achieve this, but not without much the same mechanics required as posted above for the GCD way. The reason for this is that @synchronized(foo) synchronizes on foo by identity (pointer equality) and not value equality (i.e. -isEqual:), so NSString and NSURL (the two most obvious objects used to refer to files) having value semantics, makes them poor candidates. An implementation using @synchronized might look like this:

@interface Bar : NSObject
@property (readonly) dispatch_queue_t concurrentQueue;
@end

@implementation Bar
{
    NSMutableDictionary* _lockObjects;
    dispatch_queue_t _dictGuard;
}

- (instancetype)init
{
    if (self = [super init])
    {
        _concurrentQueue = dispatch_queue_create(NULL, DISPATCH_QUEUE_CONCURRENT);
        _dictGuard = dispatch_queue_create(NULL, DISPATCH_QUEUE_SERIAL);
        _lockObjects = [[NSMutableDictionary alloc] init];
    }
    return self;
}

@synthesize concurrentQueue = _concurrentQueue;

- (id)lockForFile: (NSString*)path
{
    __block id retVal = NULL;
    dispatch_sync(_dictGuard, ^{
        retVal = _lockObjects[path];
        if (!retVal)
        {
            retVal = [[NSObject alloc] init];
            _lockObjects[path] = retVal;
        }
    });
    return retVal;
}

- (void)syncDoStuff: (id)stuff withFile: (NSString*)path
{
    id fileLock = [self lockForFile: path];
    @synchronized(fileLock)
    {
        DoStuff(stuff, path);
    }
}

- (void)asyncDoStuff: (id)stuff withFile: (NSString*)path
{
    id fileLock = [self lockForFile: path];
    dispatch_async(self.concurrentQueue, ^{
        @synchronized(fileLock)
        {
            DoStuff(stuff, path);
        }
    });
}

@end

You'll see that I made two methods to do stuff, one synchronous and the other asynchronous. @synchronized provides a mutual exclusion mechanism, but is not an asynchronous dispatch mechanism, so if you want parallelism, you still have to get that from GCD (or something else.) The long and short of it is that while you can use @synchronized to do this, it's not a good option these days. It's measurably slower than equivalent GCD mechanisms. About the only time @synchronized is useful these days is as a syntactic shortcut to achieve recursive locking. That said, many smart folks believe that recursive locking is an anti-pattern. (For more details on why, check out this link.) The long and short of it is that @synchronized is not the best way to solve this problem.