어떤 값이 읽힐지 예상할 수 없어서?
생각해보니 이건 아닌거 같고 그냥 원래 변수의 사용 자체를 막는거 같은데?
borrowed 된 변수는 그 스코프가 끝날 때 까지 값이 변하지 않는다는 것을 보장 받아야 함 - dc App
어떤 변수의 mut borrow 가 있으면 mut borrow 유효하지 않을 때 까지, 변수가 변하지 않음을 보장할 수 없기 때문에 에러가 발생함 - dc App
매번 느끼지만 실수하기 쉬운 포인트를 러스트는 완강하게 막는거 같음 ㅋㅋㅋ
동시성이 있을 때에는 read-write data race가 생기고 이건 C/C++ 에서도 UB임
동시성 없을 때는 잘 모르겠다. 무슨 이유가 있었던것 같기도 한데
데이터 레이스는 동시에 값을 쓰려고 할 때 발생하는거 아녔음? 읽기 작업도 문제가 돼?
읽기랑 쓰는걸 같이하는게 문제
러스트 겉핥기인데 뮤터블 참조한놈이 값을 변경할 수 있어서? 그런거 아니냐? 오래되서 기억나는건 값을 변경하는 놈은 딱 하나만 가능 읽기만 있다면 여러개 가능 이랬던거 같음 마치 스레드제어처럼
읽기 - 쓰기 가 동시에 허용 안되는 거는 아마도 읽기 참조(이뮤터블) 만들었는데 그뒤에 쓰기참조가 메모리 헤제시켜버린다던가 하면 읽기는 여전히 기존 메모리 참조로 댕글링포인트 문제 발생해서인듯 함? 초보 생각임
애초에 데이터 레이스 정의할 때 ‘여러 쓰레드 중 하나 이상이 값을 쓰려고 시도할 때’라고 정의함
그래서 cell이나 refcell을 쓰라고 있는거임
"The Rust compiler is allowed to assume that the value a shared reference points to will not change while that reference lives."
변수가 힙에 저장될때는 댕글링 포인터가 발생할 수 있으니까 그렇다치는데 스택에 저장되는 경우까지 막는 이유는 잘 모르겠네.. high-level model관점에선 flow conflict로 보던데 나도 아직 잘 이해가 안된듯
어떤 값이 읽힐지 예상할 수 없어서?
생각해보니 이건 아닌거 같고 그냥 원래 변수의 사용 자체를 막는거 같은데?
borrowed 된 변수는 그 스코프가 끝날 때 까지 값이 변하지 않는다는 것을 보장 받아야 함 - dc App
어떤 변수의 mut borrow 가 있으면 mut borrow 유효하지 않을 때 까지, 변수가 변하지 않음을 보장할 수 없기 때문에 에러가 발생함 - dc App
매번 느끼지만 실수하기 쉬운 포인트를 러스트는 완강하게 막는거 같음 ㅋㅋㅋ
동시성이 있을 때에는 read-write data race가 생기고 이건 C/C++ 에서도 UB임
동시성 없을 때는 잘 모르겠다. 무슨 이유가 있었던것 같기도 한데
데이터 레이스는 동시에 값을 쓰려고 할 때 발생하는거 아녔음? 읽기 작업도 문제가 돼?
읽기랑 쓰는걸 같이하는게 문제
러스트 겉핥기인데 뮤터블 참조한놈이 값을 변경할 수 있어서? 그런거 아니냐? 오래되서 기억나는건 값을 변경하는 놈은 딱 하나만 가능 읽기만 있다면 여러개 가능 이랬던거 같음 마치 스레드제어처럼
읽기 - 쓰기 가 동시에 허용 안되는 거는 아마도 읽기 참조(이뮤터블) 만들었는데 그뒤에 쓰기참조가 메모리 헤제시켜버린다던가 하면 읽기는 여전히 기존 메모리 참조로 댕글링포인트 문제 발생해서인듯 함? 초보 생각임
애초에 데이터 레이스 정의할 때 ‘여러 쓰레드 중 하나 이상이 값을 쓰려고 시도할 때’라고 정의함
그래서 cell이나 refcell을 쓰라고 있는거임
"The Rust compiler is allowed to assume that the value a shared reference points to will not change while that reference lives."
변수가 힙에 저장될때는 댕글링 포인터가 발생할 수 있으니까 그렇다치는데 스택에 저장되는 경우까지 막는 이유는 잘 모르겠네.. high-level model관점에선 flow conflict로 보던데 나도 아직 잘 이해가 안된듯