IReadWriteLock Interface
Definição
Importante
Algumas informações se referem a produtos de pré-lançamento que podem ser substancialmente modificados antes do lançamento. A Microsoft não oferece garantias, expressas ou implícitas, das informações aqui fornecidas.
A ReadWriteLock mantém um par de associados Lock locks, um para operações somente leitura e outro para gravação.
[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
- Atributos
- Implementações
Comentários
A ReadWriteLock mantém um par de associados Lock locks, um para operações somente leitura e outro para gravação. O bloqueio de leitura #readLock pode ser mantido simultaneamente por vários threads de leitor, desde que não haja escritores. O bloqueio de gravação #writeLock é exclusivo.
Todas as ReadWriteLock implementações devem garantir que os efeitos de sincronização de memória das writeLock operações (conforme especificado na Lock interface) também se mantenham em relação ao .readLock Ou seja, um thread adquirindo com sucesso o bloqueio de leitura verá todas as atualizações feitas após a liberação anterior do bloqueio de gravação.
Um bloqueio de leitura-gravação permite um nível maior de simultaneidade no acesso a dados compartilhados do que o permitido por um bloqueio de exclusão mútua. Ele explora o fato de que, enquanto apenas um único thread de cada vez (um <thread em>writer</em> ) pode modificar os dados compartilhados, em muitos casos qualquer número de threads pode ler simultaneamente os dados (portanto <, em>reader</em> threads). Em teoria, o aumento da simultaneidade permitido pelo uso de um bloqueio de leitura-gravação levará a melhorias de desempenho em relação ao uso de um bloqueio de exclusão mútua. Na prática, esse aumento na simultaneidade só será totalmente realizado em um multiprocessador e, em seguida, somente se os padrões de acesso para os dados compartilhados forem adequados.
Se um bloqueio de leitura-gravação melhorará ou não o desempenho em relação ao uso de um bloqueio de exclusão mútua depende da frequência com que os dados são lidos em comparação com a modificação, da duração das operações de leitura e gravação e da contenção dos dados - ou seja, do número de threads que tentarão ler ou gravar os dados ao mesmo tempo. Por exemplo, uma coleção que é inicialmente preenchida com dados e, posteriormente, pouco modificada, enquanto é pesquisada com frequência (como um diretório de algum tipo) é um candidato ideal para o uso de um bloqueio de leitura-gravação. No entanto, se as atualizações se tornarem frequentes, os dados passam a maior parte do tempo sendo bloqueados exclusivamente e há pouco, ou nenhum aumento na simultaneidade. Além disso, se as operações de leitura forem muito curtas, a sobrecarga da implementação de bloqueio de leitura-gravação (que é inerentemente mais complexa do que um bloqueio de exclusão mútua) pode dominar o custo de execução, especialmente porque muitas implementações de bloqueio de leitura-gravação ainda serializam todos os threads por meio de uma pequena seção de código. Em última análise, somente a criação de perfil e a medição estabelecerão se o uso de um bloqueio de leitura-gravação é adequado para seu aplicativo.
Embora a operação básica de um bloqueio de leitura-gravação seja direta, há muitas decisões de política que uma implementação deve tomar, o que pode afetar a eficácia do bloqueio de leitura-gravação em um determinado aplicativo. Exemplos dessas políticas incluem: <ul><li>Determinar se deve conceder o bloqueio de leitura ou o bloqueio de gravação, quando leitores e escritores estão aguardando, no momento em que um gravador libera o bloqueio de gravação. A preferência do escritor é comum, pois espera-se que as escritas sejam curtas e pouco frequentes. A preferência do leitor é menos comum, pois pode levar a longos atrasos para uma escrita se os leitores forem frequentes e de longa duração como esperado. Justo, ou " em ordem" implementações também são possíveis.
<li>Determinar se os leitores que solicitam o bloqueio de leitura enquanto um leitor está ativo e um gravador está aguardando, recebem o bloqueio de leitura. A preferência pelo leitor pode atrasar o escritor indefinidamente, enquanto a preferência pelo escritor pode reduzir o potencial de simultaneidade.
<li>Determinando se os bloqueios são reentrantes: um thread com o bloqueio de gravação pode readquiri-lo? Ele pode adquirir um bloqueio de leitura enquanto mantém o bloqueio de gravação? O bloqueio de leitura em si é reentrante?
<li>O bloqueio de gravação pode ser rebaixado para um bloqueio de leitura sem permitir que um escritor intervenha? Um bloqueio de leitura pode ser atualizado para um bloqueio de gravação, de preferência para outros leitores ou escritores em espera?
</ul> Você deve considerar todas essas coisas ao avaliar a adequação de uma determinada implementação para seu aplicativo.
Adicionado em 1.5.
Documentação Java para java.util.concurrent.locks.ReadWriteLock.
Partes desta página são modificações baseadas no trabalho criado e compartilhado pelo Android Open Source Project e usado de acordo com os termos descritos na Creative Commons 2.5 Attribution License.
Propriedades
| Handle |
Obtém o valor JNI do objeto Android subjacente. (Herdado de IJavaObject) |
| JniIdentityHashCode |
Retorna o valor de |
| JniManagedPeerState |
Estado do par gerenciado. (Herdado de IJavaPeerable) |
| JniPeerMembers |
Acesso de membros e suporte à invocação. (Herdado de IJavaPeerable) |
| PeerReference |
Retorna uma JniObjectReference das instâncias do objeto Java encapsulado. (Herdado de IJavaPeerable) |
Métodos
| Disposed() |
Chamado quando a instância tiver sido descartada. (Herdado de IJavaPeerable) |
| DisposeUnlessReferenced() |
Se não houver referências pendentes a este caso, então chame |
| Finalized() |
Chamado quando a instância tiver sido finalizada. (Herdado de IJavaPeerable) |
| ReadLock() |
Retorna o bloqueio usado para leitura. |
| SetJniIdentityHashCode(Int32) |
Defina o valor retornado por |
| SetJniManagedPeerState(JniManagedPeerStates) |
A |
| SetPeerReference(JniObjectReference) |
Defina o valor retornado por |
| UnregisterFromRuntime() |
Cancele o registro dessa instância para que o tempo de execução não a retorne de chamadas futuras Java.Interop.JniRuntime+JniValueManager.PeekValue . (Herdado de IJavaPeerable) |
| WriteLock() |
Retorna o cadeado usado para gravação. |
Métodos de Extensão
| JavaCast<TResult>(IJavaObject) |
Executa uma conversão de tipo verificada em tempo de execução do Android. |
| JavaCast<TResult>(IJavaObject) |
A |
| GetJniTypeName(IJavaPeerable) |
A |