IReadWriteLock Interfaz

Definición

Espacio de nombres:

Java.Util.Concurrent.Locks

Ensamblado:

Mono.Android.dll

Un ReadWriteLock mantiene un par de asociados Lock locks, uno para las operaciones de solo lectura y otro para escribir.

[Android.Runtime.Register("java/util/concurrent/locks/ReadWriteLock", "", "Java.Util.Concurrent.Locks.IReadWriteLockInvoker")]
public interface IReadWriteLock : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable

[<Android.Runtime.Register("java/util/concurrent/locks/ReadWriteLock", "", "Java.Util.Concurrent.Locks.IReadWriteLockInvoker")>]
type IReadWriteLock = interface
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

Derivado

Java.Util.Concurrent.Locks.ReentrantReadWriteLock

Atributos

RegisterAttribute

Implementaciones

IJavaObject IJavaPeerable IDisposable

Comentarios

Un ReadWriteLock mantiene un par de asociados Lock locks, uno para las operaciones de solo lectura y otro para escribir. La #readLock bloqueo de lectura se puede mantener simultáneamente mediante varios subprocesos de lector, siempre y cuando no haya escritores. El bloqueo de escritura #writeLock es exclusivo.

Todas las ReadWriteLock implementaciones deben garantizar que los efectos de sincronización de memoria de writeLock las operaciones (tal como se especifica en la Lock interfaz) también contengan con respecto al asociado readLock. Es decir, un subproceso que adquiere correctamente el bloqueo de lectura verá todas las actualizaciones realizadas tras la versión anterior del bloqueo de escritura.

Un bloqueo de lectura y escritura permite un mayor nivel de simultaneidad al acceder a datos compartidos de los permitidos por un bloqueo de exclusión mutua. Aprovecha el hecho de que, aunque solo un único subproceso a la vez (un <subproceso em>writer</em> ) puede modificar los datos compartidos, en muchos casos cualquier número de subprocesos puede leer simultáneamente los datos (por lo tanto <, em>reader</em> threads). En teoría, el aumento de la simultaneidad permitida por el uso de un bloqueo de lectura y escritura dará lugar a mejoras de rendimiento sobre el uso de un bloqueo de exclusión mutua. En la práctica, este aumento de simultaneidad solo se realizará completamente en un procesador múltiple y, a continuación, solo si los patrones de acceso para los datos compartidos son adecuados.

Si un bloqueo de lectura y escritura mejorará el rendimiento sobre el uso de un bloqueo de exclusión mutua depende de la frecuencia con la que se leen los datos en comparación con la modificación, la duración de las operaciones de lectura y escritura y la contención de los datos, es decir, el número de subprocesos que intentarán leer o escribir los datos al mismo tiempo. Por ejemplo, una colección que se rellena inicialmente con datos y, posteriormente, se modifica con poca frecuencia, mientras se busca con frecuencia (como un directorio de algún tipo) es un candidato ideal para el uso de un bloqueo de lectura y escritura. Sin embargo, si las actualizaciones son frecuentes, los datos pasan la mayor parte de su tiempo bloqueados exclusivamente y hay poco, si hay algún aumento en la simultaneidad. Además, si las operaciones de lectura son demasiado cortas, la sobrecarga de la implementación de bloqueo de lectura y escritura (que es intrínsecamente más compleja que un bloqueo de exclusión mutua) puede dominar el costo de ejecución, especialmente cuando muchas implementaciones de bloqueo de lectura y escritura siguen serializando todos los subprocesos a través de una pequeña sección de código. En última instancia, solo la generación de perfiles y la medición establecerán si el uso de un bloqueo de lectura y escritura es adecuado para la aplicación.

Aunque el funcionamiento básico de un bloqueo de lectura y escritura es sencillo, hay muchas decisiones de directiva que debe tomar una implementación, lo que puede afectar a la eficacia del bloqueo de lectura y escritura en una aplicación determinada. Algunos ejemplos de estas directivas son: <ul><li>Determinar si se debe conceder el bloqueo de lectura o el bloqueo de escritura, cuando los lectores y los escritores están esperando, en el momento en que un escritor libera el bloqueo de escritura. La preferencia del escritor es común, ya que se espera que las escrituras sean cortas y poco frecuentes. La preferencia del lector es menos común, ya que puede provocar retrasos prolongados en una escritura si los lectores son frecuentes y de larga duración según lo previsto. Justo, o " orden" También se pueden implementar implementaciones.

<li>Determinar si los lectores que solicitan el bloqueo de lectura mientras un lector está activo y un escritor está esperando, se les concede el bloqueo de lectura. La preferencia del lector puede retrasar el escritor indefinidamente, mientras que la preferencia al escritor puede reducir la posibilidad de simultaneidad.

<li>Determinar si los bloqueos son reentrantes: ¿puede un subproceso con el bloqueo de escritura volver a adquirirlo? ¿Puede adquirir un bloqueo de lectura mientras mantiene el bloqueo de escritura? ¿El bloqueo de lectura es reentrante?

<li>¿Se puede degradar el bloqueo de escritura a un bloqueo de lectura sin permitir un escritor intermedio? ¿Se puede actualizar un bloqueo de lectura a un bloqueo de escritura, en preferencia a otros lectores o escritores en espera?

</ul> Debe tener en cuenta todas estas cosas al evaluar la idoneidad de una implementación determinada para la aplicación.

Agregado en 1.5.

Documentación de Java para java.util.concurrent.locks.ReadWriteLock.

Las partes de esta página son modificaciones basadas en el trabajo creado y compartido por el proyecto de código abierto de Android y se usan según los términos descritos en la licencia de atribución de Creative Commons 2.5.

Propiedades

Handle	Obtiene el valor JNI del objeto Android subyacente. (Heredado de IJavaObject)
JniIdentityHashCode	Devuelve el valor de java.lang.System.identityHashCode() para la instancia ajustada. (Heredado de IJavaPeerable)
JniManagedPeerState	Estado del mismo nivel administrado. (Heredado de IJavaPeerable)
JniPeerMembers	Compatibilidad con la invocación y el acceso de 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 Dispose(); de lo contrario, no hace nada. (Heredado de IJavaPeerable)
Finalized()	Se llama cuando se ha finalizado la instancia. (Heredado de IJavaPeerable)
ReadLock()	Devuelve el bloqueo usado para leer.
SetJniIdentityHashCode(Int32)	Establezca el valor devuelto por JniIdentityHashCode. (Heredado de IJavaPeerable)
SetJniManagedPeerState(JniManagedPeerStates)	Un ReadWriteLock mantiene un par de asociados Lock locks, uno para las operaciones de solo lectura y otro para escribir. (Heredado de IJavaPeerable)
SetPeerReference(JniObjectReference)	Establezca el valor devuelto por PeerReference. (Heredado de IJavaPeerable)
UnregisterFromRuntime()	Anule el registro de esta instancia para que el entorno de ejecución no lo devuelva de invocaciones futuras Java.Interop.JniRuntime+JniValueManager.PeekValue . (Heredado de IJavaPeerable)
WriteLock()	Devuelve el bloqueo usado para escribir.

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)	Un ReadWriteLock mantiene un par de asociados Lock locks, uno para las operaciones de solo lectura y otro para escribir.
GetJniTypeName(IJavaPeerable)	Un ReadWriteLock mantiene un par de asociados Lock locks, uno para las operaciones de solo lectura y otro para escribir.