프로세스의 스레드가 스택을 제외한 주소 공간 (모든 세그먼트)을 공유한다는 것을 알고 있습니다. 각 스레드는 자체 스택을 가지고 있습니다. 나는 또한 같은 주소 공간에 있다는 것을 읽었고 스레드는 다른 스레드 (here 및 here)의 스택에 속하는 메모리 위치에 액세스 할 수 있습니다.스레드가 동일한 프로세스의 다른 스레드 스택에 액세스 할 수 있습니까?
위의 내용이 정확하다면 OS에 스레드의 주소가 표시 될 때 어떤 결과가 발생합니까? 스레드가 다른 스택에 무언가를 쓰고 손상 시키면 어떻게 될까요? OS가 일종의 허가 거부 오류를 생성하지 않는 이유는 무엇입니까?
이 질문에 대한 대답이 운영 체제에 따라 다르면 Linux를 고려하십시오.
상태에 따라 스레드는 동일한 주소 공간을 공유합니다. 따라서 각 스레드는 다른 스레드와 마찬가지로 주소 공간에 동일한 액세스 권한을가집니다.
OS는 스레드에서 이러한 주소를 볼 수 있습니까?
나는 당신이 여기에서 묻고있는 것을 말할 수 없다.
스레드가 다른 스택에 무언가를 쓰고 손상 시키면 어떻게 될까요?
이것은 전적으로 가능하며 결과는 예측할 수 없습니다. 경쟁 조건과 같습니다.
OS가 일종의 권한 거부 오류를 생성하지 않는 이유는 무엇입니까?
메모리 액세스는 프로세서 모드 (예 : 사용자, 커널 및 일부 시스템의 추가 모드)로 제어됩니다. 일반적으로 모드 레벨 보호는 사용자가 논리 주소 공간의 공유 시스템 범위에 액세스하지 못하도록 설계되었습니다. 프로세스는 서로 다른 사용자 주소 공간 범위를 가짐으로써 서로 보호됩니다.
일반적으로 스레드는 동일한 주소 공간에서 읽고 쓸 수 있어야합니다. 그렇지 않으면 별도의 프로세스를 사용할 수도 있습니다.
스택은 단순히 읽기/쓰기 구성원 블록입니다. 스택에 대해 신성한 것은 없습니다. 메모리 블록은 스택으로 사용할 수 있습니다.
"OS가 일종의 권한 거부 오류를 생성하지 않는 이유는 무엇입니까?" 왜 그랬 겠지? 그리고 누가 반드시 * invalid *라고 말합니다 - 액세스되는 주소가 스택 공간의 쓰레기 부분에 있지 않는 한, 스택 주소를 공유하는 것은 적당하지만 기술적으로 합법적 인 사용법을 볼 수 있습니다 (주소를 공유 상태로 전달). 다른 스레드에서 액세스). 스레딩 모델과 메모리 모델을 매우 잘 알고 있지 않는 한 다시 * 추천하지는 않습니다.하지만 유효하지 않은 것과 같지는 않습니다. –
OS에는 이미 그 추상화가 있습니다. 한 프로세스는 다른 프로세스의 메모리를 엉망으로 만들 수 없습니다. 그러나 스레드와 같은 프로그래머는 훨씬 더 효율적입니다. 당신은 두 가지 방법 모두 가질 수 없습니다. –