EXC_BAD_ACCESS lors de l'utilisation SQLite (FMDB) et les discussions sur iOS 4.0

Question

J'utilise FMDB pour traiter ma base de données qui fonctionne très bien. L'application utilise un thread d'arrière-plan qui effectue un travail et doit accéder à la base de données. En même temps, le thread principal doit exécuter certaines requêtes sur la même base de données. FMDB lui-même a un petit système de verrouillage, cependant, j'en ai ajouté un autre à mes cours.

Chaque requête est effectuée uniquement si ma classe indique que la base de données n'est pas utilisé. Après avoir effectué les actions, la base de données est déverrouillée. Cela fonctionne comme prévu tant que la charge n'est pas trop élevée. Lorsque j'accède à beaucoup de données avec le thread s'exécutant sur le thread principal, une erreur EXC_BAD_ACCESS se produit.

Voici la recherche:

- (BOOL)isDatabaseLocked { 
    return isDatabaseLocked; 
} 

- (Pile *)lockDatabase { 
    isDatabaseLocked = YES; 
    return self;   
} 

- (FMDatabase *)lockedDatabase { 
    @synchronized(self) { 
     while ([self isDatabaseLocked]) { 
      usleep(20); 
      //NSLog(@"Waiting until database gets unlocked..."); 
     } 
     isDatabaseLocked = YES; 
     return self.database;  
    } 
} 

- (Pile *)unlockDatabase { 
    isDatabaseLocked = NO; 
    return self;    
} 

Le débogueur dit que l'erreur se produit à [FMResultSet next] à la ligne

rc = sqlite3_step(statement.statement); 

Je double vérifié tous les conserver compte et tous les objets existent à ce moment. Encore une fois, cela ne se produit que lorsque le thread principal démarre beaucoup de requêtes pendant que le thread d'arrière-plan est en cours d'exécution (qui lui-même produit toujours une charge importante). L'erreur est toujours produite par le thread principal, jamais par le thread d'arrière-plan.

Ma dernière idée serait que les deux fils courent lockedDatabase en même temps afin qu'ils puissent obtenir un objet de base de données. C'est pourquoi j'ai ajouté le verrouillage mutex via "@synchronized (self)". Cependant, cela n'a pas aidé.

Quelqu'un at-il une idée?

Answer 1

Vous devez ajouter l'encapsuleur synchronisé autour de vos fonctions unlockDatabase et lockDatabase, ainsi que isDatabaseLocked - il n'est pas toujours garanti qu'un stockage ou une récupération d'une variable est atomique. Bien sûr, si vous le faites, vous voudrez déplacer votre sommeil hors du bloc synchronisé, sinon vous serez bloqué. C'est essentiellement un verrou de spin - ce n'est pas la méthode la plus efficace.

- (FMDatabase *)lockedDatabase { 
    do 
    { 
     @synchronized(self) { 
      if (![self isDatabaseLocked]) { 
       isDatabaseLocked = YES; 
       return self.database; 
      } 
     } 
     usleep(20);  
    }while(true); // continue until we get a lock 
} 

vous assurez-vous que vous n'utilisez pas l'objet FMDatabase après avoir appelé unlockDatabase? Vous pouvez envisager un modèle de poignée - créer un objet qui enveloppe l'objet FMDatabase et, tant qu'il existe, détient un verrou sur la base de données. Dans init vous revendiquez le verrou, et dans dealloc, vous pouvez libérer ce verrou. Ensuite, votre code client n'a pas à s'inquiéter de l'appel des différentes fonctions de verrouillage/déverrouillage, et vous ne risquez pas de bousiller accidentellement. Essayez d'utiliser NSMutex au lieu des blocs @synchronized, voir http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html#//apple_ref/doc/uid/10000057i-CH8-SW16

Answer 2

Vous pouvez également essayer FMDatabaseQueue - Je l'ai créé spécifiquement pour des situations comme celle-ci. Je ne l'ai pas essayé, mais je suis assez sûr que ça va fonctionner pour iOS 4.

Answer 3

SQLite offre une sérialisation beaucoup plus simple. En réglant simplement l'option sqlite_config() SQLITE_CONFIG_SERIALIZED vous probablement éviter la plupart de ces types de maux de tête. J'ai découvert cela à la dure après avoir lutté avec des problèmes de threading pendant longtemps.

Voilà comment vous l'utilisez, vous pouvez le mettre dans la méthode init de FMDatabase ...

if (sqlite3_config(SQLITE_CONFIG_SERIALIZED) == SQLITE_ERROR) { 
     NSLog(@"couldn't set serialized mode"); 
    } 

Voir les docs sur SQLite threadsafety et serialized mode pour plus d'informations.

Answer 4

J'avais ce problème et a pu éliminer le problème simplement en activant la mise en cache des déclarations préparées.

FMDatabase *myDatabase = [FMDatabase databaseWithPath: pathToDatabase]; 
myDatabase.shouldCacheStatements = YES;