2010-08-24 5 views
3

Je travaille sur du code multithread. L'accès aux données est verrouillé dans plusieurs sections via des objets "NSLock". Je veux m'assurer que certaines méthodes qui sont appelées dans ces sections vérifient si leur verrou approprié a été acquis.Existe-t-il un moyen de vérifier si un NSLock a été acquis?

Quelque chose comme:

assert([myLock isSet] == YES); 

Je ne peux pas trouver quelque chose comme "isSet" dans NSLock. Des idées sur la façon d'assurer un verrouillage sont définies?

Merci!

Répondre

9

Comment acquérez-vous la serrure? Si vous appelez lock, alors le fait que vous courez même après devrait garantir que vous l'avez acquis. Si vous appelez lockBeforeDate, la valeur de retour vous indique.

Si vous voulez tester d'ailleurs, vous pourriez faire

if ([myLock tryLock]) 
{ 
    // oops, lock was not previously acquired! 
    ... 
    [myLock unlock]; 
} 
else 
{ 
    // yep, lock was already acquired 
} 

Cependant, en général, cela semble être une chose douteuse à vouloir faire. Vous devriez faire le verrouillage là où c'est nécessaire et faire confiance au travail plutôt que d'essayer de le surveiller de l'extérieur.

+0

Merci. tryLock est exactement ce que je veux. Je peux faire: assert (! [MyLock tryLock]); Je comprends que cela me dit que l'objet est "verrouillé". Cela ne me dit pas si le bon fil a le verrou. En outre, je suis d'accord avec vous que c'est une chose discutable à faire. Mais j'essaie désespérément de trouver un bug (je ne pense pas que le bug soit lié au verrouillage, mais je ne trouve rien de mal dans l'autre code non plus - donc je dois vérifier le verrouillage). –

+4

Lars Schneider: 'tryLock' fait exactement ce qu'il dit: Il essaie de verrouiller le verrou. Si cela réussit, cela ne signifie pas simplement qu'il n'était pas verrouillé avant, cela signifie également que * il est maintenant verrouillé *. C'est pourquoi vous devez le déverrouiller s'il réussit: Sinon, vous tenez le verrou quand vous ne le souhaitez pas. –

+1

+1 Pour répondre à la question avant de l'interroger. –

5

n °

Parce que, vous voyez, tout résultat que vous obtenez est inutile, car il peut (will) se tromper au moment où vous vous déplacer à l'aide réellement. Un exemple:

  1. Vous constatez que le verrou est verrouillé.
  2. Le fil qui maintenait le verrou le déverrouille.
  3. Vous signalez que le verrou est verrouillé.

Il échoue dans l'autre sens aussi:

  1. Vous trouvez que le verrou est pas verrouillé.
  2. Un autre thread verrouille le verrou.
  3. Vous signalez que le verrou est déverrouillé.

Des problèmes comme celui-ci sont exactement pourquoi le débogage des blocages et des conditions de course est si difficile.

Je pense que vous devriez poser une autre question sur votre problème actuel.

+1

Surtout vrai, mais il y a un cas de coin.Si l'acquisition et le test de verrouillage se produisent dans un bloc @ synchronisé, vous devriez pouvoir compter sur l'état du verrou qui ne change pas. –

Questions connexes