여기서 GC.KeepAlive가 필요합니까? 아니면 객체를 유지하면서 지역 및 인수에 의존 할 수 있습니까?

Question

나는 안전하지 않은 코드를 사용하여 WPF의 WriteableBitmap을 받아 BackBuffer에서 직접 읽는 방법을 사용합니다. 한편으로

int MyMethod(WriteableBitmap bmp) 
{ 
    return DoUnsafeWork(bmp.BackBuffer); 
} 

는 MyMethod의 스택에 bmp에 대한 참조가 남아 :

내가 같은 것을 할 때마다 내가 GC.KeepAlive을 사용할지 여부를 완전히 명확하지 않다. 다른 한편으로 구현 세부 사항에 의존하는 것처럼 보입니다. 예를 들어 bmp에 대한 참조를 유지하지 않고도 DoUnsafeWork을 입력하면 꼬리 호출로 컴파일 할 수 있습니다. 이론적으로

int MyMethod() 
{ 
    WriteableBitmap bmp1 = getABitmap(); 
    var ptr = bmp.BackBuffer; 
    WriteableBitmap bmp2 = getABitmap(); 
    return DoUnsafeWork(ptr, bmp2); 
} 

이 bmp1에 대한 참조 메서드가 반환 될 때까지 스택에 남아 있지만 다시는 구현 상세를 사용하는 것 같아 :

마찬가지로, 다음의 가상 코드를 상상한다. 물론 컴파일러는 bmp1과 bmp2을 병합하는 것이 자유 롭습니다. 왜냐하면 컴파일러가 결코 그런 일을하지 않을지라도 JITter가 여전히 가능하고 아마도 그렇습니다 (예를 들어 둘 다 동일한 레지스터에 저장함으로써 하나, 다른 하나).

그래서 일반적으로 객체에 대한 유효한 참조 인 지역/인수에 의존해야합니까? 아니면 정확성을 보장하기 위해 항상 GC.KeepAlive을 사용해야합니까?

특히, 이것은 분명히 FxCop thinks GC.KeepAlive is always bad이므로 수수께끼입니다.

Answer 1

개체에 대한 유효한 참조 인 지역/인수에 의존해야합니까?

아니오. 지터는 가비지 컬렉터에게 관리 코드에 의해 더 이상 사용되지 않는 순간에 로컬의 내용이 죽었다는 것을 전적으로 그 권리 범위 내에두고 있습니다.

정확성을 보장하기 위해 항상 GC.KeepAlive를 사용해야합니까?

예. 그것이 바로 그 때문입니다.

Answer 2

백 버퍼를 가져 오기 전에 WriteableBitmap.Lock을 호출 한 경우 WriteableBitmap을 고정해야하며 기본 메모리가 이동되지 않습니다. 적어도 WriteableBitmapAPI에 대한 나의 해석입니다.

필자는 WriteableBitmap을 광범위하게 사용했으며, 특히 오픈 소스 WriteableBitmapEx 라이브러리 (codeplex) (공개,이 라이브러리에는 한 번만 기여했지만 프로젝트에는 포함되지 않았습니다)를 사용했습니다. 잠금/액세스 백 버퍼 (반복)/잠금 해제/무효화 패턴을 사용하여 그립니다. Backbuffer IntPtr이 구조체에 저장되어 있고 응용 프로그램을 전달한 경우에도이 패턴에 문제가 없었습니다.

안부,