IReadWriteLock 인터페이스
정의
중요
일부 정보는 릴리스되기 전에 상당 부분 수정될 수 있는 시험판 제품과 관련이 있습니다. Microsoft는 여기에 제공된 정보에 대해 어떠한 명시적이거나 묵시적인 보증도 하지 않습니다.
는 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- 파생
- 특성
- 구현
설명
는 ReadWriteLock 연결된 Lock locks쌍을 유지 관리합니다. 하나는 읽기 전용 작업용이고 다른 하나는 쓰기용입니다. #readLock 읽기 잠금은 기록기가 없는 한 여러 판독기 스레드에서 동시에 유지될 수 있습니다. #writeLock 쓰기 잠금은 배타적입니다.
모든 ReadWriteLock 구현은 연결된 readLock에 대해 연산의 writeLock 메모리 동기화 효과(인터페이스에 Lock 지정된 대로)도 보유하도록 보장해야 합니다. 즉, 읽기 잠금을 성공적으로 획득하는 스레드는 쓰기 잠금의 이전 릴리스에서 수행된 모든 업데이트를 볼 수 있습니다.
읽기-쓰기 잠금을 사용하면 상호 제외 잠금에서 허용하는 것보다 더 높은 수준의 공유 데이터에 액세스할 수 있습니다. 한 번에 하나의 스레드(<em 기록<기/em>> 스레드)만 공유 데이터를 수정할 수 있지만 대부분의 경우 스레드 수가 동시에 데이터를 읽을 수 있습니다(따라서 <em>reader</em> 스레드). 이론적으로 읽기-쓰기 잠금 사용으로 허용되는 동시성이 증가하면 상호 제외 잠금 사용에 비해 성능이 향상됩니다. 실제로 이러한 동시성 증가는 다중 프로세서에서만 완전히 실현된 다음 공유 데이터에 대한 액세스 패턴이 적합한 경우에만 실현됩니다.
읽기-쓰기 잠금이 상호 제외 잠금을 사용하는 동안 성능을 향상시킬지 여부는 데이터를 수정하는 것과 비교하여 데이터를 읽는 빈도, 읽기 및 쓰기 작업 기간 및 데이터 경합(즉, 동시에 데이터를 읽거나 쓰려고 시도하는 스레드 수)에 따라 달라집니다. 예를 들어 처음에 데이터로 채워지고 그 이후에 자주 수정되지 않는 컬렉션(예: 일종의 디렉터리)은 읽기-쓰기 잠금을 사용하기에 이상적인 후보입니다. 그러나 업데이트가 빈번해지면 데이터는 대부분의 시간을 독점적으로 잠그고 동시성이 증가하는 경우 거의 없습니다. 또한 읽기 작업이 너무 짧으면 읽기-쓰기 잠금 구현(기본적으로 상호 제외 잠금보다 더 복잡)의 오버헤드가 실행 비용을 지배할 수 있습니다. 특히 많은 읽기-쓰기 잠금 구현이 여전히 코드의 작은 섹션을 통해 모든 스레드를 직렬화하기 때문에 더욱 그러합니다. 궁극적으로 프로파일링 및 측정만 읽기-쓰기 잠금의 사용이 애플리케이션에 적합한지 여부를 설정합니다.
읽기-쓰기 잠금의 기본 작업은 간단하지만 구현에서 수행해야 하는 많은 정책 결정이 있으며, 이는 지정된 애플리케이션에서 읽기-쓰기 잠금의 효과에 영향을 줄 수 있습니다. 이러한 정책의 예로는 <ul><li>읽기 잠금을 부여할지 또는 쓰기 잠금을 부여할지, 판독기와 작성기 둘 다 대기 중일 때 기록기가 쓰기 잠금을 해제할 때 쓰기 잠금을 부여할지 여부를 결정합니다. 쓰기는 짧고 드물 것으로 예상되므로 작성기 기본 설정이 일반적입니다. 읽기 권한자 기본 설정은 독자가 예상대로 빈도가 높고 수명이 긴 경우 쓰기가 오래 지연될 수 있으므로 덜 일반적입니다. 공정하거나 &따옴표; 순서대로&따옴표; 구현도 가능합니다.
<li>판독기가 활성 상태이고 기록기가 대기하는 동안 읽기 잠금을 요청하는 판독기에 읽기 잠금이 부여되는지 여부를 결정합니다. 판독기에 대한 기본 설정은 작성기를 무기한 지연시킬 수 있지만 작성기에 대한 기본 설정은 동시성 가능성을 줄일 수 있습니다.
<li>잠금이 재진입되는지 여부를 결정합니다. 쓰기 잠금이 있는 스레드가 다시 액세스할 수 있나요? 쓰기 잠금을 유지하면서 읽기 잠금을 획득할 수 있나요? 읽기 잠금 자체가 재진입하나요?
<li>중간 기록기를 허용하지 않고 쓰기 잠금을 읽기 잠금으로 다운그레이드할 수 있나요? 읽기 잠금을 다른 대기 판독기 또는 작성기에 우선하여 쓰기 잠금으로 업그레이드할 수 있나요?
</ul> 애플리케이션에 대해 지정된 구현의 적합성을 평가할 때 이러한 모든 사항을 고려해야 합니다.
1.5에 추가되었습니다.
에 대한 Java 설명서입니다 java.util.concurrent.locks.ReadWriteLock.
이 페이지의 일부는 만들고 공유하며 에 설명된 용어에 따라 사용되는 작업을 기반으로 수정됩니다.
속성
| Handle |
기본 Android 개체의 JNI 값을 가져옵니다. (다음에서 상속됨 IJavaObject) |
| JniIdentityHashCode |
|
| JniManagedPeerState |
관리되는 피어의 상태입니다. (다음에서 상속됨 IJavaPeerable) |
| JniPeerMembers |
멤버 액세스 및 호출 지원. (다음에서 상속됨 IJavaPeerable) |
| PeerReference |
JniObjectReference 래핑된 Java 개체 instance 의 를 반환합니다. (다음에서 상속됨 IJavaPeerable) |
메서드
| Disposed() |
instance 삭제되었을 때 호출됩니다. (다음에서 상속됨 IJavaPeerable) |
| DisposeUnlessReferenced() |
이 instance 대한 미해결 참조가 없으면 를 호출 |
| Finalized() |
instance 완료되면 호출됩니다. (다음에서 상속됨 IJavaPeerable) |
| ReadLock() |
읽기에 사용되는 잠금을 반환합니다. |
| SetJniIdentityHashCode(Int32) |
에서 반환 |
| SetJniManagedPeerState(JniManagedPeerStates) |
는 |
| SetPeerReference(JniObjectReference) |
에서 반환 |
| UnregisterFromRuntime() |
런타임이 이후 Java.Interop.JniRuntime+JniValueManager.PeekValue 호출에서 반환되지 않도록 이 instance 등록을 취소합니다. (다음에서 상속됨 IJavaPeerable) |
| WriteLock() |
쓰기에 사용되는 잠금을 반환합니다. |
확장 메서드
| JavaCast<TResult>(IJavaObject) |
Android 런타임 확인 형식 변환을 수행합니다. |
| JavaCast<TResult>(IJavaObject) |
는 |
| GetJniTypeName(IJavaPeerable) |
는 |