2008-10-16 13 views
1

Je regardais le code source de la méthode java.uti.concurrent.locks.AbstractQueuedSynchronizer et l'acquisition() ressemble à quelque chose comme ça -Pourquoi AbstractQueuedSynchronizer interruption sur acquring verrouillage

public final void acquire(int arg) { 
    if (!tryAcquire(arg) && 
     acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) 
     Thread.currentThread().interrupt(); 
} 

Pourquoi faut-il interrompre le appel fileté acquérir()? S'il y avait une vérification quelque part dans la méthode run() des threads, alors cela pourrait passer après l'appel de acquire(), ce qui est probablement indésirable et non pensé?

Quelqu'un veut-il faire la lumière sur pourquoi le code ci-dessus le fait?

Répondre

4

Si vous lisez le Javadoc pour , vous remarquerez qu'il renvoie true si le thread a été interrompu en attente. Ainsi, l'appel à selfInterrupt (comme il est appelé dans le code source OpenJDK) est de propager l'interruption au thread appelant, qui serait autrement avalé.