cppreference 예제인데 lock.test_and_set 루프 안에 lock.test 루프도 넣어놨더라고
c++20에서 추가된거 이용하는것 같은데 위쪽 test_and_set에서 이미 테스트가 가능한데도 왜 따로 안에서 또 test하는거지?
내가 통박굴려본바로는 안에서 따로 test만 하면 relaxed memory order 사용 가능해서 그런거 같은데 맞나?
cppreference 예제인데 lock.test_and_set 루프 안에 lock.test 루프도 넣어놨더라고
c++20에서 추가된거 이용하는것 같은데 위쪽 test_and_set에서 이미 테스트가 가능한데도 왜 따로 안에서 또 test하는거지?
내가 통박굴려본바로는 안에서 따로 test만 하면 relaxed memory order 사용 가능해서 그런거 같은데 맞나?
1) 따로 test만 하면 relaxed memory order 사용 가능해서 그런거 같은데 맞나? => memory_order_acquire에 의해서 아래 명령어가 위로 재배치 안될 뿐이지, 그 아래에서 최적화되는건 괜찮아서 별 상관 없을듯 2) 왜 test를 했냐? 첫 번째 조건문인 test_and_set은 항상 set하니까 그런거같은데... 보니까 항상 true로 변경하면서 이전 값을 반환하잖아. 그런데, 일단 이전 값이 true인 경우라면, 다시 false가 나올때까지 체크(test)만 하는게 낫겠지. 굳이 이전값이 true인데 또 true로 바꿀 필요는 없으니까.
즉, 굳이 while문안에. while(lock.test...)같은 코드가 없어도, 정확히 동작하지만, 이정도까지 신경쓰는 코드라면 성능이 중요하니, 쓸데없이 값을 true로 변경시키지 않겠다는거 같은데
test_and_set에서 테스트 결과가 true가 아닐때만 set하는줄 알았는데 찾아보니 무조건 set하는게 맞네... 값 읽고-쓰기 아토믹 연산 자체가 따로 떼어낼수 없어서 그런가 어렵구만 ㅠ
lock-free에서 값을 비교하고 세팅하는게 thread-safe하게 되려면 그렇게됨. 더 궁금하면, CAS랑 lock-free 알고리듬으로 검색해보셈 ㅋ-ㅋ
해당 댓글은 삭제되었습니다.
나는 test_and_set만으로도 기회'만' 엿보기가 가능할 줄 알았는데 아닌듯
위에 댓글 실수로 삭제했다 미안 ㅠㅠ
원래 밑에 내 댓글 삭제하고 다시 쓰려던거였는데 마우스 조작 실패 ㅠ
해당 댓글은 삭제되었습니다.
쏘리쏘리 실수임 ㅠ
해당 댓글은 삭제되었습니다.
키워드들 찾아서 공부해봐야겠음 ㄱㅅㄱㅅ
여기서 캐쉬 코히런스가 나오나? 생각도 몬했다 ㄷㄷ