ios scrivere su disco su sfondo filo

Question

Attualmente sto scrivendo alcuni file su disco in thread in background semplicemente chiamando

dispatch_async(my_queue,^{ 
    [self writeToRoot:filename data:data]; 
}; 

- (BOOL)writeToRoot:(NSString *)path data:(NSData *)content 
{ 
    NSString *fullPath = [[self rootPath] stringByAppendingPathComponent:path]; 

    NSString *pathWithoutFile = [fullPath stringByDeletingLastPathComponent]; 

    BOOL directoryExists = [[NSFileManager defaultManager] fileExistsAtPath:pathWithoutFile]; 

    if (!directoryExists) { 
     NSError *error = nil; 
     [[NSFileManager defaultManager] createDirectoryAtPath:pathWithoutFile 
            withIntermediateDirectories:YES 
                attributes:nil error:&error]; 
     NSParameterAssert(error == nil); 
    } 

    return [content writeToFile:fullPath atomically:NO]; 
} 

Sto facendo questo in modo da non sarebbe bloccare il thread principale. La mia domanda è come garantire la sicurezza dei thread. mentre l'operazione di sfondo è in corso, cosa succede quando provo a leggere dal disco del file chiamando:

[NSData dataWithContentsOfFile:fullPath]; 

si accontenterà corrompere? OPPURE l'operazione di scrittura blocca il file e l'operazione di lettura attenderà che la scrittura sia completata?

Answer 1

sarei propenso a dispatch_sync vostra operazione di lettura al my_queue per garantire la sicurezza dei thread (ammesso che si tratta di una coda di serie). È anche possibile utilizzare uno qualsiasi dei vari synchronization tools (come i blocchi o la direttiva @synchronized), ma dato che hai già impostato la coda per l'interazione tra file, l'utilizzo di tale coda seriale è probabilmente più semplice.

Questa tecnica, di usare una coda per coordinare l'interazione con una risorsa condivisa è discusso nella sezione Eliminating Lock-Based Code della Guida concorrenza di programmazione.

---

A proposito, se si sta salvando in una coda di sfondo (il che significa che l'operazione di salvataggio è sufficiente a giustificare farlo sullo sfondo presumibilmente lento) potrebbe essere prudente per assicurarsi che si richiede un po 'di tempo per completare l'operazione nel caso in cui l'app stessa venga interrotta (cioè l'utente tocchi il pulsante fisico di casa, arriva una chiamata, ecc.) mentre è in corso l'operazione di salvataggio. A tale scopo, chiamando beginBackgroundTaskWithExpirationHandler prima di spedizione l'operazione di salvataggio, e chiamare endBackgroundTask quando è fatto:

UIApplication *application = [UIApplication sharedApplication]; 

// get background task identifier before you dispatch the save operation to the background 

UIBackgroundTaskIdentifier __block task = [application beginBackgroundTaskWithExpirationHandler:^{ 
    if (task != UIBackgroundTaskInvalid) { 
     [application endBackgroundTask:task]; 
     task = UIBackgroundTaskInvalid; 
    } 
}]; 

// now dispatch the save operation 

dispatch_async(my_queue, ^{ 

    // do the save operation here 

    // now tell the OS that you're done 

    if (task != UIBackgroundTaskInvalid) { 
     [application endBackgroundTask:task]; 
     task = UIBackgroundTaskInvalid; 
    } 
}); 

Questo farà in modo che la vostra operazione di salvataggio ha una possibilità di combattere per completare con successo, anche se l'applicazione viene interrotta.

E, come sottolinea Jsdodgers, probabilmente si desidera eseguire anche una scrittura atomica.

Answer 2

Dato che il codice è adesso, sì, ci sarà un problema. Ciò è dovuto al fatto che si sta configurando a non trasferire atomicamente:

return [content writeToFile:fullPath atomically:NO]; 

Cosa significa atomicamente è che invece di eliminare il file quindi di iniziare la scrittura, scrive il file in una temporanea, luogo separato, di file. Una volta che il file è stato scritto completamente, cancella la vecchia versione del file (se esistente) e rinomina il nuovo file con il nome corretto. Se il trasferimento non è completato, non accadrà nulla e il file temporaneo dovrebbe essere cancellato.

Quindi se si cambia atomicamente in tale riga su YES, la chiamata a tali dati restituirà i vecchi dati fino al completamento del salvataggio, e in qualsiasi momento in seguito si otterranno i nuovi dati.

Quindi, per fare questo, si vorrebbe:

return [content writeToFile:fullPath atomically:YES];