ICondition Интерфейс

Определение

ConditionObject учитывает методы мониторинга (Object#wait() waitObject#notify notifyи Object#notifyAll notifyAll) в отдельные объекты, чтобы обеспечить наличие нескольких наборов ожидания для каждого объекта, объединяя их с использованием произвольных реализацийLock.

[Android.Runtime.Register("java/util/concurrent/locks/Condition", "", "Java.Util.Concurrent.Locks.IConditionInvoker")]
public interface ICondition : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable
[<Android.Runtime.Register("java/util/concurrent/locks/Condition", "", "Java.Util.Concurrent.Locks.IConditionInvoker")>]
type ICondition = interface
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
Производный
Атрибуты
Реализации

Комментарии

ConditionObject учитывает методы мониторинга (Object#wait() waitObject#notify notifyи Object#notifyAll notifyAll) в отдельные объекты, чтобы обеспечить наличие нескольких наборов ожидания для каждого объекта, объединяя их с использованием произвольных реализацийLock. Если объект Lock заменяет использование synchronized методов и операторов, объект Condition заменяет использование методов монитора объектов.

Условия (также известные как <>em condition queues</em> или <em>condition variables</em>) предоставляют средства для одного потока для приостановки выполнения (для " ожидание") пока другой поток не уведомит о том, что какое-то условие состояния теперь может быть истинным. Так как доступ к этим общим сведениям о состоянии происходит в разных потоках, он должен быть защищен, поэтому блокировка той или иной формы связана с условием. Ключевое свойство, которое обеспечивает ожидание условия, заключается в том, что em <>атомарно< или em> освобождает связанную блокировку и приостанавливает текущий поток, как и Object.wait.

Экземпляр Condition внутренне привязан к блокировке. Чтобы получить Condition экземпляр для конкретного Lock экземпляра, используйте его Lock#newCondition newCondition() метод .

В качестве примера предположим, что у нас есть ограниченный буфер, который поддерживает put методы и take . take Если попытка выполняется в пустом буфере, поток будет блокироваться до тех пор, пока элемент не станет доступным; если put попытка выполняется в полном буфере, поток будет блокироваться до тех пор, пока не станет доступно пространство. Мы хотели бы сохранить ожидающие put потоки и take потоки в отдельных наборах ожидания, чтобы можно было использовать оптимизацию уведомления только одного потока в момент, когда элементы или пространства становятся доступными в буфере. Этого можно достичь с помощью двух Condition экземпляров.

class BoundedBuffer&lt;E&gt; {
<b>final Lock lock = new ReentrantLock();</b>
              final Condition notFull  = <b>lock.newCondition(); </b>
              final Condition notEmpty = <b>lock.newCondition(); </b>

              final Object[] items = new Object[100];
              int putptr, takeptr, count;

              public void put(E x) throws InterruptedException {
<b>lock.lock();
                try {</b>
                  while (count == items.length)
<b>notFull.await();</b>
                  items[putptr] = x;
                  if (++putptr == items.length) putptr = 0;
                  ++count;
<b>notEmpty.signal();</b>
<b>} finally {
                  lock.unlock();
                }</b>
              }

              public E take() throws InterruptedException {
<b>lock.lock();
                try {</b>
                  while (count == 0)
<b>notEmpty.await();</b>
                  E x = (E) items[takeptr];
                  if (++takeptr == items.length) takeptr = 0;
                  --count;
<b>notFull.signal();</b>
                  return x;
<b>} finally {
                  lock.unlock();
                }</b>
              }
            }

(Класс java.util.concurrent.ArrayBlockingQueue предоставляет эту функцию, поэтому нет оснований для реализации этого класса использования примера.)

Реализация Condition может обеспечить поведение и семантику, отличающиеся от Object поведения методов мониторинга, например гарантированный порядок уведомлений или отсутствие необходимости удерживать блокировку при выполнении уведомлений. Если реализация предоставляет такую специализированную семантику, то реализация должна документировать эти семантики.

Обратите внимание, что Condition экземпляры являются обычными объектами и сами могут использоваться в качестве целевого synchronized объекта в инструкции и могут иметь собственные мониторы Object#wait wait и Object#notify notify методы. Получение блокировки монитора экземпляра Condition или использование его методов мониторинга не имеет указанной связи с получением Lock связанного с этим Condition или использованием #await методов ожидания и #signal сигнализации. Во избежание путаницы рекомендуется никогда не использовать Condition экземпляры таким образом, за исключением случаев, когда они используются в собственной реализации.

За исключением случаев, когда указано, передача null значения для любого параметра приведет к возникновению NullPointerException .

<h2>Вопросы< реализации/h2>

При ожидании Condition, "<em>spurious wakeup</em>" допускается, как правило, как уступка базовой семантике платформы. Это практически не влияет на большинство программ приложений Condition , так как всегда следует ожидать в цикле, проверяя предикат состояния, который ожидается. Реализация позволяет исключить возможность фиктивных пробуждений, но рекомендуется, чтобы программисты приложений всегда предполагали, что они могут произойти, и поэтому всегда ждать в цикле.

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

Следовательно, реализация не требуется определять точно одинаковые гарантии или семантику для всех трех форм ожидания, а также не требуется поддерживать прерывание фактической приостановки потока.

Реализация требуется для четкого документирования семантики и гарантий, предоставляемых каждым из методов ожидания, и если реализация поддерживает прерывание приостановки потока, она должна подчиняться семантике прерывания, как определено в этом интерфейсе.

Так как прерывание обычно подразумевает отмену, а проверки на прерывание часто выполняются нечасто, реализация может предпочещать реагирование на прерывание, а не обычный метод возврата. Это верно, даже если можно показать, что прерывание произошло после другого действия, которое могло разблокировать поток. Реализация должна документировать это поведение.

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

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

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

Свойства

Handle

Возвращает значение JNI базового объекта Android.

(Унаследовано от IJavaObject)
JniIdentityHashCode

Возвращает значение для упаковаемого java.lang.System.identityHashCode() экземпляра.

(Унаследовано от IJavaPeerable)
JniManagedPeerState

Состояние управляемого однорангового узла.

(Унаследовано от IJavaPeerable)
JniPeerMembers

Поддержка доступа и вызова участников.

(Унаследовано от IJavaPeerable)
PeerReference

JniObjectReference Возвращает экземпляр объекта Java, заключенный в оболочку.

(Унаследовано от IJavaPeerable)

Методы

Await()

Приводит к тому, что текущий поток ожидает передачи сигнала или прерывания Thread#.

Await(Int64, TimeUnit)

Приводит к тому, что текущий поток будет ожидать передачи сигнала или прерывания, либо до истечения указанного времени ожидания.

AwaitNanos(Int64)

Приводит к тому, что текущий поток будет ожидать передачи сигнала или прерывания, либо до истечения указанного времени ожидания.

AwaitUninterruptibly()

Заставляет текущий поток ожидать передачи сигнала.

AwaitUntil(Date)

Приводит к тому, что текущий поток будет ожидать передачи сигнала или прерывания или истечения указанного крайнего срока.

Disposed()

Вызывается при удалении экземпляра.

(Унаследовано от IJavaPeerable)
DisposeUnlessReferenced()

Если отсутствуют незадающиеся ссылки на этот экземпляр, вызывает Dispose(); в противном случае ничего не делает.

(Унаследовано от IJavaPeerable)
Finalized()

Вызывается после завершения работы экземпляра.

(Унаследовано от IJavaPeerable)
SetJniIdentityHashCode(Int32)

Задайте значение, возвращаемое .JniIdentityHashCode

(Унаследовано от IJavaPeerable)
SetJniManagedPeerState(JniManagedPeerStates)

ConditionObject учитывает методы мониторинга (Object#wait() waitObject#notify notifyи Object#notifyAll notifyAll) в отдельные объекты, чтобы обеспечить наличие нескольких наборов ожидания для каждого объекта, объединяя их с использованием произвольных реализацийLock.

(Унаследовано от IJavaPeerable)
SetPeerReference(JniObjectReference)

Задайте значение, возвращаемое .PeerReference

(Унаследовано от IJavaPeerable)
Signal()

Пробуждает один поток ожидания.

SignalAll()

Пробуждает все ожидающие потоки.

UnregisterFromRuntime()

Отмените регистрацию этого экземпляра, чтобы среда выполнения не возвращала его из будущих Java.Interop.JniRuntime+JniValueManager.PeekValue вызовов.

(Унаследовано от IJavaPeerable)

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

JavaCast<TResult>(IJavaObject)

Выполняет преобразование типа, проверенное средой выполнения Android.

JavaCast<TResult>(IJavaObject)

ConditionObject учитывает методы мониторинга (Object#wait() waitObject#notify notifyи Object#notifyAll notifyAll) в отдельные объекты, чтобы обеспечить наличие нескольких наборов ожидания для каждого объекта, объединяя их с использованием произвольных реализацийLock.

GetJniTypeName(IJavaPeerable)

ConditionObject учитывает методы мониторинга (Object#wait() waitObject#notify notifyи Object#notifyAll notifyAll) в отдельные объекты, чтобы обеспечить наличие нескольких наборов ожидания для каждого объекта, объединяя их с использованием произвольных реализацийLock.

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