ILock Interfaz
Definición
Importante
Parte de la información hace referencia a la versión preliminar del producto, que puede haberse modificado sustancialmente antes de lanzar la versión definitiva. Microsoft no otorga ninguna garantía, explícita o implícita, con respecto a la información proporcionada aquí.
Lock las implementaciones proporcionan operaciones de bloqueo más amplias de las que se pueden obtener mediante synchronized métodos e instrucciones.
[Android.Runtime.Register("java/util/concurrent/locks/Lock", "", "Java.Util.Concurrent.Locks.ILockInvoker")]
public interface ILock : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable[<Android.Runtime.Register("java/util/concurrent/locks/Lock", "", "Java.Util.Concurrent.Locks.ILockInvoker")>]
type ILock = interface
interface IJavaObject
interface IDisposable
interface IJavaPeerable- Derivado
- Atributos
- Implementaciones
Comentarios
Lock las implementaciones proporcionan operaciones de bloqueo más amplias de las que se pueden obtener mediante synchronized métodos e instrucciones. Permiten estructurar más flexible, puede tener propiedades bastante diferentes y pueden admitir varios objetos asociados Condition .
Un bloqueo es una herramienta para controlar el acceso a un recurso compartido mediante varios subprocesos. Normalmente, un bloqueo proporciona acceso exclusivo a un recurso compartido: solo un subproceso a la vez puede adquirir el bloqueo y todo el acceso al recurso compartido requiere que el bloqueo se adquiera primero. Sin embargo, algunos bloqueos pueden permitir el acceso simultáneo a un recurso compartido, como el bloqueo de lectura de un ReadWriteLock.
El uso de synchronized métodos o instrucciones proporciona acceso al bloqueo de monitor implícito asociado a cada objeto, pero obliga a que todas las adquisiciones y liberación de bloqueo se produzcan de forma estructurada en bloque: cuando se adquieren varios bloqueos, deben liberarse en el orden opuesto, y todos los bloqueos deben liberarse en el mismo ámbito léxico en el que se adquirieron.
Aunque el mecanismo de ámbito para synchronized métodos e instrucciones facilita mucho el programa con bloqueos de monitor y ayuda a evitar muchos errores de programación comunes que implican bloqueos, hay ocasiones en las que es necesario trabajar con bloqueos de una manera más flexible. Por ejemplo, algunos algoritmos para recorrer las estructuras de datos a las que se accede simultáneamente requieren el uso de " manualmente&comillas; o " chain locking": adquiere el bloqueo del nodo A, luego el nodo B, luego libera A y adquiere C, luego libera B y adquiere D, etc. Las implementaciones de la Lock interfaz permiten el uso de estas técnicas al permitir que se adquiera y libere un bloqueo en distintos ámbitos, y permitir que se adquieran y liberen varios bloqueos en cualquier orden.
Con esta mayor flexibilidad es responsabilidad adicional. La ausencia de bloqueo estructurado en bloques elimina la liberación automática de bloqueos que se produce con synchronized métodos e instrucciones. En la mayoría de los casos, se debe usar la siguiente expresión:
{@code
Lock l = ...;
l.lock();
try {
// access the resource protected by this lock
} finally {
l.unlock();
}}
Al bloquear y desbloquearse se producen en distintos ámbitos, se debe tener cuidado para asegurarse de que todo el código que se ejecuta mientras se mantiene el bloqueo está protegido por try-finally o try-catch para asegurarse de que el bloqueo se libere cuando sea necesario.
Lock las implementaciones proporcionan funcionalidad adicional sobre el uso de synchronized métodos e instrucciones proporcionando un intento de no bloqueo para adquirir un bloqueo (#tryLock()), un intento de adquirir el bloqueo que se puede interrumpir (#lockInterruptiblyy un intento de adquirir el bloqueo que puede expirar (#tryLock(long, TimeUnit)).
Una Lock clase también puede proporcionar comportamiento y semántica que es bastante diferente de la del bloqueo de monitor implícito, como la ordenación garantizada, el uso no reentrante o la detección de interbloqueos. Si una implementación proporciona una semántica especializada, la implementación debe documentar esa semántica.
Tenga en cuenta que Lock las instancias son simplemente objetos normales y se pueden usar como destino en una synchronized instrucción . La adquisición del bloqueo de monitor de una Lock instancia no tiene ninguna relación especificada con la invocación de ninguno de los #lock métodos de esa instancia. Se recomienda evitar confusiones que nunca use Lock instancias de esta manera, excepto dentro de su propia implementación.
Excepto cuando se indique, si se pasa un null valor para cualquier parámetro, se producirá una NullPointerException excepción .
<h2>Memory Synchronization</h2>
Todas las Lock implementaciones <em>deben< aplicar> la misma semántica de sincronización de memoria proporcionada por el bloqueo de monitor integrado, como se describe en el capítulo 17 de cita>La especificación< del <lenguaje Java/cita>: <ul><li>Una operación correcta lock tiene los mismos efectos de sincronización de memoria que una acción correcta <de bloqueo/><em>. <li>Una operación correcta unlock tiene los mismos efectos de sincronización de memoria que una acción de desbloqueo</em> correcta<>. </ul>
Las operaciones de bloqueo y desbloqueo incorrectos, y las operaciones de bloqueo y desbloqueo reentrantes, no requieren ningún efecto de sincronización de memoria.
<h2>Consideraciones< de implementación/h2>
Las tres formas de adquisición de bloqueos (interrumpibles, no interrumpibles y con tiempo de expiración) pueden diferir en sus características de rendimiento, garantías de ordenación u otras cualidades de implementación. Además, la capacidad de interrumpir la <>adquisición en curso</em> de un bloqueo puede no estar disponible en una clase determinadaLock. Por consiguiente, no se requiere una implementación para definir exactamente las mismas garantías o semánticas para las tres formas de adquisición de bloqueos, ni es necesario admitir la interrupción de una adquisición de bloqueo en curso. Se requiere una implementación para documentar claramente la semántica y las garantías proporcionadas por cada uno de los métodos de bloqueo. También debe obedecer la semántica de interrupción tal como se define en esta interfaz, en la medida en que se admita la interrupción de la adquisición de bloqueos: que es totalmente o solo en la entrada del método.
Como la interrupción generalmente implica la cancelación, y las comprobaciones de interrupción suelen ser poco frecuentes, una implementación puede favorecer la respuesta a una interrupción en el retorno del método normal. Esto es cierto incluso si se puede mostrar que la interrupción se produjo después de otra acción puede haber desbloqueado el subproceso. Una implementación debe documentar este comportamiento.
Agregado en 1.5.
Documentación de Java para java.util.concurrent.locks.Lock.
Las partes de esta página son modificaciones basadas en el trabajo creado y compartido por el proyecto de código y se usan según los términos descritos en la creative Commons 2.5.
Propiedades
| Handle |
Obtiene el valor JNI del objeto Android subyacente. (Heredado de IJavaObject) |
| JniIdentityHashCode |
Devuelve el valor de |
| JniManagedPeerState |
Estado del mismo nivel administrado. (Heredado de IJavaPeerable) |
| JniPeerMembers |
Compatibilidad con la invocación y el acceso a miembros. (Heredado de IJavaPeerable) |
| PeerReference |
Devuelve una JniObjectReference de la instancia de objeto java ajustada. (Heredado de IJavaPeerable) |
Métodos
| Disposed() |
Se llama cuando se ha eliminado la instancia. (Heredado de IJavaPeerable) |
| DisposeUnlessReferenced() |
Si no hay referencias pendientes a esta instancia, llama a |
| Finalized() |
Se llama cuando se ha finalizado la instancia. (Heredado de IJavaPeerable) |
| Lock() |
Adquiere el bloqueo. |
| LockInterruptibly() |
Adquiere el bloqueo a menos que se interrumpa el subproceso actual. |
| NewCondition() |
Devuelve una nueva |
| SetJniIdentityHashCode(Int32) |
Establezca el valor devuelto por |
| SetJniManagedPeerState(JniManagedPeerStates) |
|
| SetPeerReference(JniObjectReference) |
Establezca el valor devuelto por |
| TryLock() |
Adquiere el bloqueo solo si es libre en el momento de la invocación. |
| TryLock(Int64, TimeUnit) |
Adquiere el bloqueo si está libre en el tiempo de espera especificado y el subproceso actual no se ha interrumpido la interrupción de Thread#. |
| Unlock() |
Libera el bloqueo. |
| UnregisterFromRuntime() |
Anule el registro de esta instancia para que el entorno de ejecución no lo devuelva de Java.Interop.JniRuntime+JniValueManager.PeekValue futuras invocaciones. (Heredado de IJavaPeerable) |
Métodos de extensión
| JavaCast<TResult>(IJavaObject) |
Realiza una conversión de tipos comprobados en tiempo de ejecución de Android. |
| JavaCast<TResult>(IJavaObject) |
|
| GetJniTypeName(IJavaPeerable) |
|