IReadWriteLock Интерфейс

Ссылка

Определение

Пространство имен:: Java.Util.Concurrent.Locks

Сборка:: Mono.Android.dll

Важно!

Некоторые сведения относятся к предварительной версии продукта, в которую до выпуска могут быть внесены существенные изменения. Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, относительно приведенных здесь сведений.

A ReadWriteLock поддерживает пару связанных Lock locksопераций , один для операций только для чтения и один для записи.

[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

Производный: Java.Util.Concurrent.Locks.ReentrantReadWriteLock

Атрибуты: RegisterAttribute

Реализации: IJavaObject IJavaPeerable IDisposable

A ReadWriteLock поддерживает пару связанных Lock locksопераций , один для операций только для чтения и один для записи. Блокировка чтения #readLock может храниться одновременно несколькими потоками чтения, пока отсутствуют записи. Блокировка записи #writeLock является эксклюзивной.

Все ReadWriteLock реализации должны гарантировать, что эффекты writeLock синхронизации памяти операций (как указано в интерфейсе Lock ) также хранятся в отношении связанных readLock. То есть поток успешно получает блокировку чтения, увидит все обновления, внесенные при предыдущем выпуске блокировки записи.

Блокировка чтения и записи обеспечивает более высокую степень параллелизма в доступе к общим данным, чем это разрешено взаимной блокировкой исключения. Он использует тот факт, что в то время как только один поток за раз (<><поток записи em или> em) может изменять общие данные, во многих случаях любое количество потоков может одновременно считывать данные (следовательно<, потоки em reader</em>>). В теории увеличение параллелизма, разрешенного при использовании блокировки чтения и записи, приведет к улучшению производительности при использовании блокировки взаимного исключения. На практике это увеличение параллелизма будет полностью реализовано на нескольких процессорах, а затем только в том случае, если шаблоны доступа для общих данных подходят.

Независимо от того, будет ли блокировка чтения и записи повысить производительность при использовании взаимной блокировки исключения, зависит от частоты, которую данные считываются по сравнению с изменением, длительностью операций чтения и записи, а также конфликтов для данных , т. е. количества потоков, которые будут пытаться считывать или записывать данные одновременно. Например, коллекция, которая изначально заполняется данными и впоследствии редко изменяется, при этом часто выполняется поиск (например, каталог определенного вида) является идеальным кандидатом на использование блокировки чтения и записи. Однако если обновления становятся частыми, то данные тратят большую часть времени исключительно на блокировку и мало, если любое увеличение параллелизма. Кроме того, если операции чтения слишком коротки накладные расходы на реализацию блокировки чтения и записи (которая, по сути, сложнее, чем взаимная блокировка исключения), могут доминировать затраты на выполнение, особенно так как многие реализации блокировки чтения и записи по-прежнему сериализуют все потоки через небольшой раздел кода. В конечном счете, только профилирование и измерение определяют, подходит ли для приложения использование блокировки чтения и записи.

Хотя базовая операция блокировки чтения и записи прямо вперед, существует множество решений политики, которые необходимо принять, что может повлиять на эффективность блокировки чтения и записи в данном приложении. Примеры этих политик включают в себя: <ul><li>Определение того, следует ли предоставить блокировку чтения или блокировку записи, когда ожидается как читатели, так и записи, в то время, когда модуль записи освобождает блокировку записи. Вариант записи распространен, так как записи, как ожидается, будут короткими и редко. Предпочтение читателя менее распространено, так как это может привести к длительным задержкам для записи, если читатели часты и долгоживущие, как ожидалось. Fair, or " in-order" Кроме того, возможны реализации.

<li>Определение того, запрашивают ли читатели блокировку чтения, пока читатель активен, и модуль записи ожидает, предоставляется блокировка чтения. Предпочтение читателю может отложить средство записи на неопределенный срок, а предпочтения средства записи могут уменьшить потенциал параллелизма.

<li>Определить, повторно ли выполняются блокировки: может ли поток с повторной настройкой блокировки записи? Может ли он получить блокировку чтения при удержании блокировки записи? Является ли блокировка чтения повторной отступом?

<li>Может ли блокировка записи быть понижена до блокировки чтения, не позволяя промежуточному записи? Можно ли обновить блокировку чтения до блокировки записи, предпочитая другие средства чтения или записи?

</ul> следует учитывать все эти вещи при оценке пригодности заданной реализации для вашего приложения.

Добавлено в версии 1.5.

Документация по Java для java.util.concurrent.locks.ReadWriteLock.

Части этой страницы — это изменения на основе работы, созданной и общей проектом с открытым исходным кодом Android и используемой в соответствии с условиями, описанными в лицензии Creative Commons 2.5 Attribution.

Свойства

Handle	Возвращает значение JNI базового объекта Android. (Унаследовано от IJavaObject)
JniIdentityHashCode	Возвращает значение `java.lang.System.identityHashCode()` для упаковаемого экземпляра. (Унаследовано от IJavaPeerable)
JniManagedPeerState	Состояние управляемого однорангового узла. (Унаследовано от IJavaPeerable)
JniPeerMembers	Поддержка доступа к членам и вызовов. (Унаследовано от IJavaPeerable)
PeerReference	JniObjectReference Возвращает экземпляр объекта Java в оболочке. (Унаследовано от IJavaPeerable)

Методы

Disposed()	Вызывается при удалении экземпляра. (Унаследовано от IJavaPeerable)
DisposeUnlessReferenced()	Если нет невыполненных ссылок на этот экземпляр, то вызывается `Dispose()`; в противном случае ничего не делает. (Унаследовано от IJavaPeerable)
Finalized()	Вызывается при завершении экземпляра. (Унаследовано от IJavaPeerable)
ReadLock()	Возвращает блокировку, используемую для чтения.
SetJniIdentityHashCode(Int32)	Задайте значение, возвращаемое `JniIdentityHashCode`. (Унаследовано от IJavaPeerable)
SetJniManagedPeerState(JniManagedPeerStates)	A `ReadWriteLock` поддерживает пару связанных `Lock locks`операций , один для операций только для чтения и один для записи. (Унаследовано от IJavaPeerable)
SetPeerReference(JniObjectReference)	Задайте значение, возвращаемое `PeerReference`. (Унаследовано от IJavaPeerable)
UnregisterFromRuntime()	Отмените регистрацию этого экземпляра, чтобы среда выполнения не возвращала ее из будущих Java.Interop.JniRuntime+JniValueManager.PeekValue вызовов. (Унаследовано от IJavaPeerable)
WriteLock()	Возвращает блокировку, используемую для записи.

Методы расширения

JavaCast<TResult>(IJavaObject)	Выполняет преобразование типа, проверяемого средой выполнения Android.
JavaCast<TResult>(IJavaObject)	A `ReadWriteLock` поддерживает пару связанных `Lock locks`операций , один для операций только для чтения и один для записи.
GetJniTypeName(IJavaPeerable)	A `ReadWriteLock` поддерживает пару связанных `Lock locks`операций , один для операций только для чтения и один для записи.

Применяется к

Поделиться через