Lines Matching refs:READ_ONCE
259 Q = READ_ONCE(P); D = READ_ONCE(*Q);
266 READ_ONCE() 는 메모리 배리어 명령도 내게 되어 있어서, DEC Alpha CPU 는
271 DEC Alpha 에서 수행되든 아니든, READ_ONCE() 는 컴파일러로부터의 악영향
277 a = READ_ONCE(*X); WRITE_ONCE(*X, b);
285 WRITE_ONCE(*X, c); d = READ_ONCE(*X);
296 (*) 컴파일러가 READ_ONCE() 나 WRITE_ONCE() 로 보호되지 않은 메모리 액세스를
458 삭제되었습니다. 오늘날에는 공유된 변수들의 로드를 표시하는 READ_ONCE() 나
581 리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에
583 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
605 않는 READ_ONCE() 에 해당합니다.
622 이 문제 상황을 제대로 해결하기 위해, READ_ONCE() 는 커널 v4.15 릴리즈 부터
631 Q = READ_ONCE(P);
665 않습니다. 달리 말하면, 오늘날의 READ_ONCE() 의 묵시적 주소 의존성 배리어가
701 q = READ_ONCE(a);
705 p = READ_ONCE(b);
714 q = READ_ONCE(a);
717 p = READ_ONCE(b);
724 q = READ_ONCE(a);
730 하나, READ_ONCE() 도 WRITE_ONCE() 도 선택사항이 아니라 필수사항임을 부디
731 명심하세요! READ_ONCE() 가 없다면, 컴파일러는 'a' 로부터의 로드를 'a' 로부터의
742 그러니 READ_ONCE() 를 반드시 사용하세요.
747 q = READ_ONCE(a);
761 q = READ_ONCE(a);
778 q = READ_ONCE(a);
790 q = READ_ONCE(a);
799 처음의 READ_ONCE() 는 컴파일러가 'a' 의 값을 증명해내는 것을 막기 위해 여전히
806 q = READ_ONCE(a);
818 q = READ_ONCE(a);
828 q = READ_ONCE(a);
845 q = READ_ONCE(a);
853 q = READ_ONCE(a);
857 강조합니다. 조금 더 일반적으로 말해서, READ_ONCE() 는 컴파일러에게 주어진 로드
864 q = READ_ONCE(a);
915 최적화로 없애버렸을 겁니다. READ_ONCE() 와 WRITE_ONCE() 의 주의 깊은
919 합니다. 주의 깊은 READ_ONCE() 나 atomic{,64}_read() 의 사용이 컨트롤
955 WRITE_ONCE(b, 2); x = READ_ONCE(b);
957 y = READ_ONCE(a);
965 WRITE_ONCE(b, &a); x = READ_ONCE(b);
973 r1 = READ_ONCE(y);
975 WRITE_ONCE(x, 1); if (r2 = READ_ONCE(x)) {
990 WRITE_ONCE(a, 1); }---- --->{ v = READ_ONCE(c);
991 WRITE_ONCE(b, 2); } \ / { w = READ_ONCE(d);
993 WRITE_ONCE(c, 3); } / \ { x = READ_ONCE(a);
994 WRITE_ONCE(d, 4); }---- --->{ y = READ_ONCE(b);
1442 r4 = READ_ONCE(v);
1443 r5 = READ_ONCE(u);
1457 r3 = READ_ONCE(u);
1523 하지만, READ_ONCE() 와 WRITE_ONCE() 는 특정 액세스들에 대해서만 동작하는
1535 READ_ONCE() 와 WRITE_ONCE() 함수는 싱글 쓰레드 코드에서는 문제 없지만 동시성이
1549 a[0] = READ_ONCE(x);
1550 a[1] = READ_ONCE(x);
1552 즉, READ_ONCE() 와 WRITE_ONCE() 는 여러 CPU 에서 하나의 변수에 가해지는
1568 컴파일러가 이런 짓을 하지 못하게 하려면 READ_ONCE() 를 사용하세요:
1570 while (tmp = READ_ONCE(a))
1590 이번에도, 컴파일러가 그런 짓을 하는걸 막기 위해 READ_ONCE() 를 사용하세요:
1592 while (tmp = READ_ONCE(a))
1616 READ_ONCE() 를 사용하세요:
1618 while (tmp = READ_ONCE(a))
1621 하지만 컴파일러는 READ_ONCE() 뒤에 나오는 값에 대해서도 눈길을 두고 있음을
1625 while ((tmp = READ_ONCE(a)) % MAX)
1691 if (READ_ONCE(flag))
1692 process_message(READ_ONCE(msg));
1697 READ_ONCE() 와 WRITE_ONCE() 를 사용해야 함을 기억해 두세요. 만약 그런
1699 READ_ONCE() 와 WRITE_ONCE() 는 필요치 않습니다. (근래의 리눅스 커널에서
1704 컴파일러는 READ_ONCE() 와 WRITE_ONCE() 뒤의 READ_ONCE() 나 WRITE_ONCE(),
1708 이 효과는 barrier() 를 통해서도 만들 수 있지만, READ_ONCE() 와
1709 WRITE_ONCE() 가 좀 더 안목 높은 선택입니다: READ_ONCE() 와 WRITE_ONCE()는
1713 READ_ONCE() 와 WRITE_ONCE() 가 일어난 순서도 지켜줍니다, CPU 는 당연히
1742 날조된 로드를 막기 위해선 READ_ONCE() 를 사용하세요.
1777 READ_ONCE() 나 WRITE_ONCE() 도 없고 volatile 마킹도 없기 때문에,
1780 스토어 티어링을 초래할 겁니다. 이 예에서도 READ_ONCE() 와 WRITE_ONCE()
1784 WRITE_ONCE(foo2.b, READ_ONCE(foo1.b));
1787 그렇지만, volatile 로 마크된 변수에 대해서는 READ_ONCE() 와 WRITE_ONCE() 가
1789 READ_ONCE(jiffies) 라고 할 필요가 없습니다. READ_ONCE() 와 WRITE_ONCE() 가
1807 주소 의존성 READ_ONCE()
1820 READ_ONCE() 매크로부터 보기 시작하는게 좋은 시작이 될겁니다.
2739 a = READ_ONCE(*A);
2741 c = READ_ONCE(*C);
2742 d = READ_ONCE(*D);
2789 U = READ_ONCE(*A);
2792 X = READ_ONCE(*A);
2794 Z = READ_ONCE(*A);
2812 READ_ONCE() 와 WRITE_ONCE() 는 반드시 존재해야 함을 알아두세요. 그런 종류의
2813 아키텍쳐에서 READ_ONCE() 와 WRITE_ONCE() 는 이 문제를 막기 위해 필요한 일을
2814 뭐가 됐든지 하게 되는데, 예를 들어 Itanium 에서는 READ_ONCE() 와 WRITE_ONCE()
2836 는, 메모리 배리어나 READ_ONCE() 와 WRITE_ONCE() 없이는 다음과 같이 변형될 수
2856 부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의