- 그렇다면 반대로 volatile 을 사용하지 않아 in-memory operation 을 얻
어냈을 때는 atomicity 가 보장되는지요?
x86에서 single instruction으로서 인터럽트가 걸린 상황에서 incl을 얘기 하시는 것이라면 여러 프로세서에서도 보장된다는 것이 제 해석입니다.
이것은 저 번에 인용한 원문에 인용된 글에서 single processor에서 보장된다는
것 보다 나아간 해석입니다.(intel manual)
manual 을 다시 한번 확인해 보시기 바랍니다. SMP 에서는 어차피
atomicity 가 보장되지 않습니다.
24547212.pdf (chapter 7.1)
Quote:
kyong wrote:
x86에서 물리적 메모리에 쓰는 것이 느리기 때문에 store buffer를 둬서 성능
을 관리하는데 이 때 이루어지는 delay를 갖고 얘기할 수있겠다는 생각이
들었습니다. 그렇지만 delay됐기 때문에 program oder가 안 지켜지는 것은
아닙니다.
이제 님과 제가 가장 의견일치를 보지 못하는 부분에 대한 내용입니다.
(non-volatile) operation 에 의한 delay 는 같은 프로그램의 실행 순서가
최적화로 인해 바뀌는 경우를 이야기하는 것입니다. 이는 아마도 님이 C 표
준이 C 프로그램의 실행에 대해 이야기하는 바를 제대로 알고 계시지 못한
탓이라 생각합니다.
for (i=0; i < 10; i++);
for (j=0; j < 10; j++);
printf("%d, %d\n", i, j);
이와 같은 문장이 있을 때 implementation 은 임의로 j 에 대한 loop 를 먼
저 실행시킬 수도, 혹은 i, j 에 대한 loop 를 한 주기씩 엇갈려가며 실행
시킬 수도 있습니다. C 프로그램은 actual machine 의 행동을 기술하는 것
이 아닌, C 프로그램이 최적화 없이 그대로 실행된다고 가정되는 abstract
machine 의 행동을 기술하는 것입니다. 그리고, 그 actual/abstract
machine 사이에는 완전히 동일한 행동이 보장되지는 않으며, 다만 abstract
machine 에서 얻은 최종적인 결과가 actual machine 에서 얻은 최종 결과와
같다는 것만 보장됩니다 - 이를 "as if 규칙" 이라고 부릅니다. 이와 같은
사실을 근거로 implementation 은 동일한 결과를 보장한다는 전제 아래 최
적화를 도입할 수 있는 것이며, 다만 그와 같은 최적화가 일으킬 수 있는
현실적인 문제를 막을 수 있도록 C 언어에서 volatile 을 제공하고 있는 것
입니다. 일례로, 어떤 implementation 이 actual/abstract machine 이 동일
하게 행동하도록 (따라서, 완전히 최적화가 배제되도록) 구성되어 있다면,
volatile 은 아예 무시될 수도 있습니다.
따라서, 님이 생각하시는 것과는 달리, 동일한 결과를 보인다면 "같은" 프
로그램의 다른 부분을 미리 실행하는 것이 가능하며, 실제로 그와 같은 일
이 일어남을 위의 다른 분이 보여주신 예에서 확인할 수 있습니다 - "code
가 가장 많은 것을 설명해준다" 고 믿는 분이 아니었는지요?
volatile이 아닌 object에 대해서 그런 식의 최적화가 가능하다는 것은 알
알고 있습니다. 그러나 문제의 양상을 그렇게 표현한 것이 아니라고 봅니다.
volatile이 가지는 의미 자체로 그런 설명 조차 필요없다고 생각하지만
incl이 나온 배경의 한 근거를 제시했기에 인용된다는데는 동의하실 것입니다.
이것은 또 그 원문이 왜 나왔는지 정확한 배경을 이해해야 하는 것입니다. http://www.ussg.iu.edu/hypermail/linux/kernel/0001.0/0276.html
Jamie Lokier는 Andrea Arcangeli 쓴 차이가 없다는 말에 이런 차이를 생각
해서 했을 수도 있다라고 얘기하고 결과적으로 timer irq design에 의해 그
것 조차 필요없으므로 jiffies++도 괜찮을 것이다 라고 얘기하고 있습니다.
이것은 만약 timer irq가 그렇게 design 되지 않았다면 반드시 *& hack을 써야
한다는 말이 됩니다. 이것은 자명합니다.
그러면 volatile인 jiffies++가 일으키는 문제가 뭐기 때문에 volatile의
의미를 제거해서 ++ 해야 하는 것이 맞다라는 설명이 전제 돼야겠지요.
그 설명이 2번 째 단락인 것입니다. volatile인 경우에 어떤 문제가 있다라고
설명하는 자리에서 non volatile의 문제점을 거론하면서 volatile을 써야한다는
님의 설명이 맞지 않은 것은 당연하다고 전 생각합니다.
위에서 얘기한 store buffer는 단지 read, write 시점이 달라서 메인 메모리에서
값이 보장되지 않는 한 예일 수 있다는 것을 보인 것입니다.
Quote:
kyong wrote:
그러나 read, write 할 때 access 시점이 다르고(incl이더라도)
interrupt나 lock이 걸린 상황이 아니므로 값의 차이를 낳는다입니다.
즉, access 시점이 다른 두 intruction을 결합해서는 예측할 수 없는 것이
volatile인 것입니다.
일단, 한 가지를 분명히 하겠습니다. 아래에서 다시 자세히 말씀드리겠지만
volatile 은 atomicity 와 아무런 관련이 없습니다. implementation 이 추
가적으로 atomicity 에 대한 보장을 줄 수는 있지만, 이는 표준이 volatile
에 대해 최소한으로 요구하는 것이 아닙니다. 따라서, volatile 은
atomicity 와 관련된 문제를 그대로 안고 있습니다. 하지만, 논의의 중심에
있는 do_timer 는 다른 이유로 atomicity 가 보장되는 문맥입니다.
volatile은 분명 free reader를 위한 것입니다. multi processor, multi thread
환경에서 정확한 값을 보장해 주기 위해서는 적절한 design이 필요한 것입
니다. 표준에서 writer의 atomicity를 위해서 어떻게 하라든지 그런 말은
당연히 없습니다. jiffies 처럼 10ms를 보장 받지 않는 상황이라면 필요없겠
지요. 여전히 관련이 없다고 생각하세요?
Quote:
kyong wrote:
do_timer상황에서는 맞습니다. 그러나 volatile과 atomicity와 아무 관련이
없다는 말은 틀렸습니다. in-memory operation에 대해 한 말은 제가 한 것과
는 다릅니다. volatile의 의미를 제거한 최적화의결과로서 의미를 가진다고
얘기로 한 줄로 압니다. volatile이 in-memory operation을 생성하는 것은 제가
기대하는 행동입니다.
앞으로 그런 기대를 버리시기 바랍니다. volatile 이 어떻게든 atomicity
와 관련되어 있다면, async signal 에 대해서 표준이 sig_atomic_t 를 도입
할 이유가 없습니다. signal 만 관련되어도 volatile 은 "접근" 에 대한
atomicity 를 보장해 주지 못합니다.
제 기대는 incl %eax 보다는 incl 0x80484a8 입니다.
asynchronous signal handler에 의해 수정되는 object인 경우 volatile로 선언
할 대상인 것입니다. 접근에 대한 atomicity와는 완전히 다른 얘기입니다.
a = jiffies;
while (a == jiffies) ;
true가 되지 않는 것입니다.
Quote:
kyong wrote:
volatile은 main memory에서의 여러 방법으로 값이 변경될 수 있음을 규정하기
때문에 atomicity를 위해서 별도의 design을 강요하는 것입니다.
절대로 그렇지 않습니다. 표준을 가지고 계신다면 "volatile" 로 본문을
검색해 보시기 바랍니다. 어떠한 경로를 통해 그와 같은 정보를 얻으셨는지
모르겠지만 틀린 이야기입니다.
위에서 얘기 했듯이 표준에 있다는 얘기가 아니고 현실적인 사용에서 필요한
부분이란 것을 얘기합니다.
Quote:
kyong wrote:
제가 저번에 조건을 둔 즉, 두 sequence point 사이에 같은 값이 여러번 사용된
경우를 애기한 것입니다. 즉 다음과 같은 경우입니다.
if (f(j*j)) => register int temp = j; if (f(temp*temp))
이 예제는 C reference manual 에서 인용했습니다.
해당 예제는 잘못된 것입니다. H&S4 에 대해서는 오래 전에 해당 저자에게
지적하는 메일을 보냈으며
(http://c-expert.uos.ac.kr/program/c_etcdoc/carmerror.pdf),
다만 그 시점이 H&S5 가 나온 이후 이기에 제대로 H&S5 에 제대로 반영되지
않았습니다. 제가 표준화 위원회의 멤버와 그와 같은 최적화에 대해 논의를
한 이유도 바로 그 예제에 대한 의심 때문이었고, 그와 같은 두 sequence
point 사이에서의 최적화는 올바르지 않다는 것이 결론이었습니다.
전 H&S5 92페이지에서 인용했는데 위 문서에서 언급된 곳은 못 찾겠더군요
그리고 최근 careferencemanual.com 에서 업데이트 된 내용에서도 전혀 찾
을 수 없더군요. .
혹시 링크를 아신다면 알려주시기 바랍니다.
변환 과정에서 side effect가 어떻게 생기는지 설명 부탁드립니다.
Quote:
kyong wrote:
전웅 wrote:
extern volatile int a;
i = a + a;
- 여기서 두 sequence point 가 어디인지요?
- 또, 그 사이에서 최적화가 허락된다는 것은 a 라는 대상체 (실제 메모리)
에 최소한 몇 번의 참조가 있어야 함을 의미하는 것인지요?
위 예제는 적절하지 않다고 생각됩니다.
위의 경우 side effect가 없는 경우입니다.
님께서 어떠한 경로를 통해 volatile 에 대한 지식을 얻으셨는지 모르겠지
만, 개인적으로 표준을 직접 보시거나 표준을 올바르게 기술한 책을 다시
보시기를 추천해 드립니다. volatile 대상체를 읽는 행동은 그 자체로 side
effect 입니다.
kyong wrote:
다음 질문에서 이 부분은 제가 표준화관련 문서를 정확히 본 것이 아니고 irc에서
들은 것이여서 정확한지는 모르겠으나 여러번이라고 했으니 2번 이상이라고 짐
작할 뿐입니다.
님께서 sequence point 사이에서의 최적화에 대한 이야기를 H&S 에서 얻으
셨을 것이라 예상했기에 일부러 유사한 예를 보여드린 것입니다. H&S 에 따
르면, 위의 예는
register r = a; // "register" obeyed
i = r + r;
와 같이 최적화가 가능합니다. 하지만, 말씀드렸듯이 이것은 사실이 아닙니
다. H&S 에서 유사한 예를 통해 seqeunce point 사이에서의 최적화가 가능
하다고 생각하시는 분이 이 상황에서는 최소한 2번의 접근이 필요하다고 추
측하시는 것은 모순됩니다.
전 expression관점에서 본 것입니다. volatile이 side effect라는 사실에
동의합니다.
그리고 이 경우 앞에 a와 뒤에 a가 같은 값이 아니기 때문에 당연히
최적화 대상이 아닙니다. 님의 말에 의해 전혀 모순이 없습니다.
그리고 irc 어떤 사람이 말한 f(r);f(r); 예제를 버리고 H&S5 에서
예제를 선책한 이유입니다.
그러면,
i= a - a;
인 경우는 어떻게 된다고 생각하세요?
register int temp = j;
if (f(temp*temp))
경우 위 경우와는 좀 다른 경우입니다.
f(temp*temp) // sequence point
if ( * ) // sequence point
같은 값이 two sequence point에 쓰인 경우입니다.
한 reference로 처리 될 수 있는 부분이 아닌가 생각됩니다.
그래서 compiler에게 맞겨도 될 것이란 생각입니다.
Quote:
kyong wrote:
volatile int i;
for (i = 0; i < 100; i++) func(i);
아래와 같이 번역할 수 없음의 의미하는 것 뿐이며,
register int r; // "register" obeyed
for (r = 0; r < 100; r++) func(r);
i = r;
님이 애초에 semantic을 보장하는 register caching까지 막지 않는다는 것을 말
하면서 든 예제인데 여기 예제는 register로 copy하지 말고 main memory를 읽어야한다는 volatile의 의미를 얘기한 예제일 뿐입니다.
그러니까 적절한 예제는 semantic을 보장하면서 register cacing하는
경우입니다.
"첫번째 보인 코드가 두번째 코드처럼 행동할 수 없다" 는 것을 보이는 위
의 예는 "volatile 의 semantic 을 보장하면서 register caching 을 막음을
보여주는" 예입니다 - C 표준의 Rationale 에 나온 것과 사실한 동일한 예
입니다. 다르게 생각하신다면 이는 님께서 volatile 에 대해서 오해하는 부
분이 있기 때문입니다.
제가 한 말을 잘 못 알아들으셨네요. 님이 한 말에 따라 semantic을 보장하면서
register caching을 막지 않는 예제가 나왔어야 하는데 volatile의 sematic을 보
장해서 register caching을 막는 예제가 나왔다는 것을 말합니다.
Quote:
kyong wrote:
제가 번역 기술상 맞다고 생각하는 번역은 다음과 같습니다.
Quote:
그 값은 캐쉬되지 않을 것이다.(컴파일러 버그인 경우를 뺀다면), 그러나 값이
읽어져서 증가된 다음 저장 될 수 있다. 그리고 저장은 volatile이 아닌 연산이
나 함수호출 이후로 연기될 수 있다.
즉, 지금 volatile 연산에 의해 변경된 값이 메모리에 반영되기 전에 volatile이
아닌 연산(즉 volatile 연산은 최적화 되지 않기 때문에 또 실행 된다고 해도 program order가 보장되므로)이나 함수로 인해 값이 또 읽혀 질 수 있고
저장된 후에는 다른 값이 되어서 atomicity가 회손되는 것입니다.
결국 atomicity가 회손된다는 것은 맞지만 다른 연산에 의해 지연되서 생긴 결과
라는 해석과는 다분히 차이가 있는 것입니다.
이 부분이 바로 님께서 오해하고 계신 부분입니다. 원하신다면 해당 글을
쓴 사람에게 그 의미를 직접 물어보시기 바랍니다. 이미 말씀드렸듯이 프로
그램의 실행 순서는 동일한 결과를 보인다는 전제 아래에서 뒤바뀔 수 있습
니다. 프로그램의 실행 순서가 보장된다는 님의 생각이 옳다면 gcc 는 어떠
한 옵션을 사용해도 표준을 따르지 않는 implementation 이 되어 버립니다.
그것이 최적화의 의미입니다. 그러나 volatile object는 다른 경우이기 때문에
예외를 두고 있다는 것을 잘 아시겠죠? volatile이기 때문에 read, write access
사이에 값이 변경되지 않음을 보장 못한다는 것을 이해하셨다면 의미가
자명합니다.
Quote:
그리고, 다시 한번 말씀드리지만, 해당 문단은 do_timer 가 처한 atomicity
가 보장되는 특수한 문맥에 대해서 이야기하고 있는 것이며, 만약 님의 생
각처럼 atomicity 문제를 이야기하는 것이라면 간섭이 가능한 연산을
non-volatile 로 한정할 이유가 없습니다. 같은 프로그램 안에서
implementation 이 side effect 를 예측할 수 없는 두 volailte 대상체에
대한 연산의 순서를 바꾸는 것은 결과에 영향을 줄 수 있기 때문에 거의 일
어나지 않는 일입니다. 하지만, 어떤 volatile 연산과 non-volatile 연산의
순서는 결과에 영향을 주지 않기에 (이론적으로는 큰 scale 도 가능하지만,
현실적인 이유로 보통은 작은 scale 에서) 순서가 뒤섞일 수 있습니다. 해
당 글이 말하는 "delay" 는 이로 인한 delay 입니다.
do_timer가 처한 상황은 두번째 문단에서 고려할 필요가 없다는 것이 원문
해석에 합당하다는 것을 위해서 밝혔습니다. 그리고 do_timer 상황에서는
delay가 생겨도 의미가 없음을 아래에서 밝히고 있습니다.
제가 생각한 것은 코드가 생성될 때 있는 상황이 아니라 실행 시점에 중심을
둔 것이고 님은 코드자체가 생성될 때 이미 가지는 의미에 중심을 둔 것 같
습니다. 그렇지만 volatile object는 main memory만을 가정하기 때문에
같은 프로그램에서 순서에 따라 의미가 delay가 생기기도 하지만 다른 프로
그램에서 접근하는 code에 의해서도 delay 내지는 값의 변경 되는 것입니다.
code가 어떻게 생성되더라도 결국 값은 main memory를 읽어서만 알 수 있는
것입니다. 결국 read, increment, store 에서 근본적으로 생기는 delay를 말하
는 것입니다. 결국 두 의미가 모두 volatile object에 있는 요소라고 생각합니다.
그렇지만 원저자가 value란 단어를 분명히 썼기 때문에 제가 한 말에 더 가깝
고 그것이 원래 volatile object를 잘 설명하고 있는 것입니다.
Quote:
kyong wrote:
non-volatile으로 한정한 것이 아니라 memory에 있기 때문에 memory를 접근
하는 모든 operation에 의해서 값이 수정될 수 있다는 것을 뜻한다고 생각합
니다.
kyong wrote:
인터럽트 상황에는 기존 operation을 끝내고 system bus를 독점하기 때문에
그럴 수 없다는 것이 제 해석입니다.
맞습니다. 따라서, do_timer 에 대한 논의에서는 atomicity 는 배제되어야
합니다. 그럼에도 님께서는 위에서 계속 해당 연산의 atomicity 에 대해
이야기하고 계십니다. 아직도 무엇이 문제인지 보이지 않으시는지요?
위에서 제가 한 설명을 잘 읽어 보시기 바랍니다.
Quote:
kyong wrote:
표준은 위애서 얘기 했듯이 read, write가 결합된 연산에 대해서 side effect가
없음을 얘기하고 있지 않습니다. do_timer는 atomicity를 고려된 경우이고요.
분명히 위해서 애기하신 것은 do_timer 상황에서 얘기한 경우가 아니라고
생각됩니다.
2번째 문단을 do_timer 문맥이 아닌 일반적인 문맥에 대한 이야기라고 믿고
계신 것 같습니다. 이 역시 해당 글쓴이에게 직접 메일을 보내 물어보시기
바랍니다. 만약, 해당 문맥이 do_timer 문맥이 아닌 일반적인 이야기로 쓴
것이라면 ++ 연산에 간섭을 줄 수 있는 연산을 non-volatile 로 한정할 필
요가 전혀 없습니다.
아니라고 생각합니다. do_timer안에서는 non-volatile object가 아무리 얼켜
있다고 해도 결국 순서대로 실행되서 끝날 때 까지 아무 곳에서도 영향을 줄
수 없습니다. 즉, 값이 atomic하게 증가 된다는 말씀이죠. 그러니 do_timer안
에서 간섭의 의미는 무의미합니다.
Quote:
kyong wrote:
timer_irq design을 몰랐음이 아니라는 가정하에 그것은 아니다입니다.
"가정하" 에 그렇습니다. 그럼 이제 그 가정을 증명할 차례입니다. 문제는
"원 개발자는 timer IRQ design 을 알았을까?" 가 됩니다. 이제 그 가정을
어떻게 증명하실 것인지요? 제가 왜 계속해서 "원 개발자의 마음 속에 들
어있는 생각" 을 찾고 계신지 그 이유를 모르시겠습니까?
저번에 얘기 했듯이 do_timer의 design을 몰랐다면 중간에 *& hack 이전에
jiffies++ 코드가 나오지 말알어야한다고 생각합니다.
Quote:
kyong wrote:
역사적인 이유에 대해서는 구체적으로 읽어 보지 못했습니다. 단 최근에
volatile을 busy-waiting과 관련해서 역사적인 이유에서 남겨 둔다는 말은
본 적이 있습니다. 최초 incl이 사용됐다면 중간에 jiffies++가 생겼다가
없어지는 일이 일어나지 말았어야 한다고 전 생각합니다.
이것은 atomicity에 대한 것도 해당되는것입니다.
유사한 이야기는 *& hack 에도 적용됩니다. "성능 향상" 이 그 주요한 목적
이었다면, 꾸준하게 "완전한" 성능 향상을 위한 최적화가 사용되었어야 합
니다. 단 한 시점에서라도 불완전한 형태를 보였다는 사실은 그에 대한 의
심을 남깁니다.
과거 코드는 항상 개선 대상이죠. 현재 없어진 것은 근거가 되지 않습니까?
Quote:
kyong wrote:
c 표준화 과정을 정확히 모르지만, draft를 거쳐 rfc가 만들어 지는 과정을 봐도
그렇고(rfc가 표준은 아니지만) 규정은 계속 진화하는 것입니다. C89, C99로
진화했듯이 변화하기 마련인데 그런 단정을 하시니 이해가 되지 않을 뿐입니다.
앞으로 발표될 예정인 C99 TC2 와 Embedded C TR 에는 그와 같은 보장이 추
가로 존재하지 않는다고 말씀드렸습니다. 그리고, 그 이후의 미래는 저도
확신할 수 없지만 ("역술가" 이야기를 언급했던 것으로 기억합니다), C 표
준화 위원회가 생각하고 있는 C 언어의 정의를 고려한다면 그럴 가능성이
적다고 말씀 드렸습니다. 즉, Embedded C TR 과 C99 TC2 가 발표되는 시점
까지는 제 예상이 맞을 수 밖에 없는 것이며, 그 이후에는 틀릴 가능성이
있음을 이미 인정하고 있습니다. 엉뚱한 부분을 인용하며 반박의 근거로 사
용하시지 않으셨으면 좋겠습니다.
kyong wrote:
특히 volatile에 대한 rvalue에 대한 의미는 표준에서 정확하지 않다는 글을 본적
이 있습니다.
잘못된 이야기입니다. "rvalue 에 대한 의미" 로 무엇을 말씀하고 계신지
불분명하지만,
- rvalue (값의) 문맥에서 형한정어는 무의미하다.
- volatile 대상체를 "읽는 행위" 는 side effect 이다.
임은 분명한 사실입니다. volatile 에 대한 불분명한 부분은 전혀 다른 곳
에 있습니다.
말씀하신 대로라면 volatile의 표준화는 완성된 것이 아니군요.
Quote:
kyong wrote:
거짓에 가능성이 아니라 변화의 가능성을 부정한 사실에 대한
일상적인 거부감이란 사실을 이해하시기 바랍니다.
가까운 미래에 대해서는 확실한 근거를 기반으로 한 단정적인 부정이었으며
먼 미래에 대해서는 기본적인 철학에 기반한 약한 부정이었습니다. 님이 말
씀하신 것과 유사하게, 님의 단정적인 표현을 빌린 "개인적 의견 혹은 추측"
에 대한 다른 사람들의 일상적인 거부감도 생각해 보시기 바랍니다.
철학은 시대에 따라 바뀐다는 사실을 잊은 듯하네요. 결론을 요약하실 때는
모두 반영하시기 바랍니다.
Quote:
kyong wrote:
sys_iopl에서 문제는 결국 다른 방법으로 해결됐습니다. 2.7.x 버젼에서 문제가
있어서 그런 *& hack으로 linus가 풀었지만 결국 2.8.x 에서 다시 불거져 나와서
다른 patch가 적용된 것입니다. 결국 bug를 피하기 위한 임시 방편은 오래 가지
못한다는 것이 제 생각입니다. 그리고 그것은 volatile 의미를 제거하는 hack
이 아니기 때문에 다른 문제라고 생각됩니다.
예, 그렇기 때문에 sys_iopl 을 "제외한" kernel 의 다른 부분에서
volatile 의 의미를 제거하기 위한 목적으로 *& hack 이 사용된 경우가 있
는지 묻고 있는 것입니다.
sparc/kernel/sun4d_smp.c swap 함수를 보시기 바랍니다.
Quote:
kyong wrote:
전웅 wrote:
저는 "in-memory incl 를 사용하는 것이 *& hack 의 목적이다" 라는 사실에
대해서는 님이 이 논의에 참여하기 이전부터 이야기하고 있었으며
...
그 이유가 "최적화" 인지는 의심스럽다고 말씀드리고 있는 것입니다. 논의
가 진행되면서 제 의견의 변화가 생긴 부분은 (이미 말씀드렸듯이) 최적화
일 가능성에 대한 생각이 이전보다 커졌다는 것 뿐입니다.
알겠습니다. *& hack은 platform independent 하기 때문에 incl 이 목적이
다라고 얘기할 수 없고 volatile 의미를 제거한 최적화 유도가 목적이다가 더 정확할 것 같습니다.
제가 말씀드린 바를 제대로 이해하고 계시지 못합니다. 상황을 어떻게 설명
드려야 의사소통이 가능할지 답답합니다. *& hack 은 결코 platform
independent 하지 않으며, *& hack 의 목적은 incl 이 분명합니다.
volatile 의 의미를 제거하는 것의 "일반적인" 의미는 최적화와 무관합니다.
platform independent 하다는 말은 incl을 똑같이 말들어 준다는 말이 아닙니다.
님께서도 이미 한 얘기입니다. asm 버젼을 만들지 않은 이유를 뜻합니다.
Quote:
kyong wrote:
전 lkml을 거의 매일 읽는 사람입니다.
위에서 애기 했듯이 code로 설명되지 않는다면 무의미 합니다.
역사적인 이유도 그렇고요. asm version을 제안한 사람이 누군지도 기억합니다.
님이 lkml 을 거의 매일 읽는 것과 code 로 설명되지 않으면 무의미하다는
주장 사이에는 연관 관계가 없습니다. asm version 을 제안한 사람이 누구
인지 기억하는 것 역시 님의 개인적인 생각이 진실임을 보장하는 근거가 되
지 않습니다.
근거도 없이 읽어 봤냐고 하시길래 늘 친숙한 만큼 잘 읽는다는 뜻이였습니다.
Quote:
kyong wrote:
틀릴 수 있고 맞을 수 있습니다. 사과할 일은 아닙니다.
저는 제가 말씀드린 기술적인 내용 중에 오류가 있다면 분명 사과드립니다.
이는 일정 시간동안 제 말을 믿고 잘못된 내용을 진실로 알고 계신 분들에
대한 사과입니다. 이는 제 글의 신뢰성을 높이기 위한 방법이며, 그 신뢰성
을 위해 글을 쓰기 전에 관련된 내용을 재확인해보도록 해주는 장치이기도
합니다.
manual 을 다시 한번 확인해 보시기 바랍니다. SMP 에서는 어차피
atomicity 가 보장되지 않습니다.
24547212.pdf (chapter 7.1)
P3 용 manual 의 7.1.2.1 을 보면, 자동 lock 이 이루어지는 상황과, lock
을 위해 LOCK 을 붙일 수 있는 명령어가 나열되어 있습니다. 자동 lock 이
이루어지는 상황에는 inc 이 없으며, 반면 LOCK 을 붙여 lock 을 할 수 있
는 명령어에는 inc 가 있습니다. 이 내용은 님께서 인용하신 lkml 에도 나
와있는 바입니다. 해당 논의를 모두 읽어보셨다면 이처럼 잘못된 주장은 하
지 않으셨을 것입니다. 더이상 inc 가 모든 상황에서 atomicity 를 보장해
준다고 주장하시는 일이 없기를 바랍니다. 따라서, 이에 의존하여 밑에서
주장을 펼치신 부분은 잘못된 근거에 의존한 잘못된 주장이기에 답하지 않
겠습니다.
그리고, 반복하여 부탁드리지만, 확실한 근거나 이해가 부족한 상태에서
(여러 사람이 분명한 여러 근거 확인을 통해) 이미 논의가 종료된 사실에
대해서 단정적인 태도로 "틀렸음" 을 제기하지 않으셨으면 좋겠습니다. 님
이 의심이 가는 부분이나 근거는 불충분하지만 잘못된 것 같다고 생각하는
부분이 있다면 질문으로도 충분히 사실을 확인할 수 있습니다. 왜 잘못된
이해와 근거에 의존하여 단정적인 표현을 사용해 사실을 왜곡하려 하시는지
그 의도를 알기 어렵습니다.
kyong wrote:
volatile이 아닌 object에 대해서 그런 식의 최적화가 가능하다는 것은 알
알고 있습니다. 그러나 문제의 양상을 그렇게 표현한 것이 아니라고 봅니다.
volatile이 가지는 의미 자체로 그런 설명 조차 필요없다고 생각하지만
incl이 나온 배경의 한 근거를 제시했기에 인용된다는데는 동의하실 것입니다.
이것은 또 그 원문이 왜 나왔는지 정확한 배경을 이해해야 하는 것입니다. http://www.ussg.iu.edu/hypermail/linux/kernel/0001.0/0276.html
Jamie Lokier는 Andrea Arcangeli 쓴 차이가 없다는 말에 이런 차이를 생각
해서 했을 수도 있다라고 얘기하고 결과적으로 timer irq design에 의해 그
것 조차 필요없으므로 jiffies++도 괜찮을 것이다 라고 얘기하고 있습니다.
이것은 만약 timer irq가 그렇게 design 되지 않았다면 반드시 *& hack을 써야
한다는 말이 됩니다. 이것은 자명합니다.
만약, 문제가 되는 상황이 do_timer 가 아닌 다른 thread 나 processor 의
간섭이 있을 수 있는 상황이라면 "interrupt 에 대해서" inc 를 선택하는
것이 유효한 차이를 가져올 수 있습니다. 또한, 님은 inc 가 SMP 에서도
atomicity 를 보장해준다고 믿기 때문에, 그 차이는 매우 중요하다고 생각
하실 수 있습니다. 하지만, 위에서 말씀드렸듯이 inc 가 (SMP 를 포함한)
일반적인 상황에서는 어차피 atomicity 를 보장해주지 않기 때문에 그러한
차이는 님이 생각하고 계신 것보다 극단적인 모습을 보이게 됩니다.
kyong wrote:
그러면 volatile인 jiffies++가 일으키는 문제가 뭐기 때문에 volatile의
의미를 제거해서 ++ 해야 하는 것이 맞다라는 설명이 전제 돼야겠지요.
그 설명이 2번 째 단락인 것입니다. volatile인 경우에 어떤 문제가 있다라고
설명하는 자리에서 non volatile의 문제점을 거론하면서 volatile을 써야한다는
님의 설명이 맞지 않은 것은 당연하다고 전 생각합니다.
문제가 되는 2번째 단락에 대한 제 이해는 이렇습니다. 해당 글쓴이는 2번
째 단락을 통해 do_timer 문맥에서 (gcc 에 의해 이루어지는) volatile 대
상체로의 접근에 대한 일반적인 내용을 기술하고 있다는 것입니다. 즉, 같
은 do_timer 문맥이더라도 single insturction 을 사용했다면 발생하지 않
을 일이, (gcc 의 volatile 에 대한 다소 과도한 최적화 금지에 의해)
volatile 한정이 남아 있는 경우 생긴다는 것입니다. 하지만, do_timer 가
속해 있는 상황이 다른 프로그램의 간섭이 자연히 배제되는 상황이기 때문
에, 그 차이는 같은 프로그램 실행의 reordering 에 의해 non-volatile 연
산이나 함수 호출이 먼저 실행될 수 있는 차이뿐이 낳지 않는다는 것입니다.
만약, 님께서 다르게 생각하신다면 해당 글쓴이에게 직접 물어보시기 바랍
니다.
그리고, 만약 해당 글쓴이가 2번째 문단에서 같은 프로그램 실행의
reordering 뿐 아니라 프로그램 외부의 다른 요인에 의한 간섭까지도 생각
하고 있는 것이라면 왜 간섭할 수 있는 연산을 non-volatile 로 한정하여
설명하고 있는지 분명히 밝혀주시기 바랍니다. 이에 대해서는 단 한번도 답
하지 않으셨습니다.
kyong wrote:
위에서 얘기한 store buffer는 단지 read, write 시점이 달라서 메인 메모리에서
값이 보장되지 않는 한 예일 수 있다는 것을 보인 것입니다.
자꾸 메인 메모리에서 값이 보장되지 않는다고 말씀하고 계시는데,
read i into r1
inc r1
store r1 into i
이는 위와 상황에서 inc r1 과 store r1 into i 사이에 메모리 i 에 저장된
값이 달라질 수 있음을 의미하고 계신 것이라 생각합니다. do_timer 와 같
이 간섭이 철저히 배제되지 않은 상황이라면 이는 가능합니다. 하지만, 논
의가 이루어지는 do_timer 문맥에서는 불필요한 걱정입니다.
논의가 진행 중인 do_timer 문맥이 아닌 일반적인 상황에 대한 고찰은 분리
하여 해주시기 바랍니다. 괜한 오해를 낳을 수 있습니다.
kyong wrote:
volatile은 분명 free reader를 위한 것입니다. multi processor, multi thread
환경에서 정확한 값을 보장해 주기 위해서는 적절한 design이 필요한 것입
니다. 표준에서 writer의 atomicity를 위해서 어떻게 하라든지 그런 말은
당연히 없습니다. jiffies 처럼 10ms를 보장 받지 않는 상황이라면 필요없겠
지요. 여전히 관련이 없다고 생각하세요?
volatile 이 multi processor/thread 상황까지 고려하여 적절한 설계가 필
요하다는 주장의 객관적 근거를 제시하시기 바랍니다. 반복하여 말씀드리지
만 표준은 (signal 이 존재하는) single thread 상황만을 고려한 C 언어의
spec 을 기술한 것이고, volatile 은 atomicity 와 아무런 관련이 없기 때
문에 async signal 에서 조차 접근에 대한 atomicity 를 보장해 주지 못합
니다 - 이것이 async signal 발생 시의 통신을 위해 volatile sig_atomic_t
형으로 선언된 static 대상체를 사용해야 하는 이유입니다. volatile 이
atomicity 를 보장해주지 않는다는 사실은 뉴스그룹의 여러 논의에서도 발
견할 수 있습니다. 어제 hclc 에 인용된 한 논의를 인용합니다 - C++ 에 대
한 논의이지만, volatile 을 C 언어가 (표준화 이전의) C++ 에서 빌려온 것
이기 때문에 미묘한 type algebra 를 제외하면 동일한 semantic 을 갖습니
다:
님은 계속해서 volatile 에 대한 잘못된 지식을 보여주고 계십니다. 근거도
존재하지 않는 보장에 함부로 의존하는 태도는 결코 안전한 프로그램 제작
에 도움이 되지 않습니다. 만약, 님의 말씀대로 volatile 이 atomicity 도
보장해줘야 하는 것이 사실이라면, 제가 알고 있는 대부분의
implementation 이 잘못된 것이 되어 버립니다. 분명,
implementation-defined access 이기에 implementation 이 추가적으로
volatile 에 atomic access/operation 의 의미를 부여할 수 있지만, 제가
아는 대부분의 환경에서 그렇지 않은 것이 사실입니다. 이미 위에서도
방준영님과 sliver 님의 논의를 보면, atomicity 를 위해 volatile 외에 다
른 장치를 사용하고 있는 것을 확인할 수 있습니다. 분명한 사실을 도처에
깔아놓은 상태에서 님이 믿고 있는 volatile 에 대한 잘못된 지식에만 의존
하는 이유도 이해하기 어렵습니다. 제 개인적인 또 이 글을 읽는 분들의 시
간 낭비를 막기 위해 앞으로 "분명한 객관적 근거를 인용하시기 이전에는"
님의 다음과 같은 주장에는 답하지 않겠습니다.
- volatile 이 multi thread/processor 환경에서 atomicity 를 보장한다.
- inc 는 모든 일반적인 상황에서도 atomicity 를 보장한다.
또한, 문제가 되고 있는 글의 2번째 문단에서 간섭할 수 있는 연산을
non-volatile 로 한정한 이유를 설명하지 못하신다면,
- 2번째 문단은 일반적인 상황에서 다른 프로그램에 의한 간섭을 포함하는
의도이다.
라는 주장 역시 답하지 않을 것입니다. 이는 님을 무시하거나 님의 기분을
불쾌하게 만들려는 의도가 절대 아닙니다. 저는 최선을 다해 님의 이해를
돕기 위해 노력했지만, 그와 같은 노력이 님의 그릇된 믿음 앞에서 간단히
무시되는 것 같아 앞으로 불필요한 노력을 하지 않겠다는 생각일 뿐입니다.
kyong wrote:
전 H&S5 92페이지에서 인용했는데 위 문서에서 언급된 곳은 못 찾겠더군요
그리고 최근 careferencemanual.com 에서 업데이트 된 내용에서도 전혀 찾
을 수 없더군요. .
혹시 링크를 아신다면 알려주시기 바랍니다.
변환 과정에서 side effect가 어떻게 생기는지 설명 부탁드립니다.
제 글을 "제대로" 읽어보신 후에 답변해 주시기 바랍니다. 저는 그 내용에
대한 지적을 H&S4 에 대해서 했으며, 개인적인 사정으로 H&S5 가 출판된 이
후에 저자에게 보냈습니다 - H&S5 가 출판된 한참 후에야 제가 H&S5 를 구
입했습니다. 저자는 제가 지적한 내용을 H&S4 에 대해서 검토했으며, 제게
H&S5 에서도 남아 있는 문제를 지적해 달라고 회신해 왔습니다. 제가 다른
바쁜 일로 H&S5 를 읽지 못하고 있기에 H&S5 에 대한 적용이 늦어지는 것입
니다. 인용된 PDF 문서의 6쪽을 보시기 바랍니다.
그리고, 해당 예제에서 side effect 가 어떻게 생길 수 있는지 이해하지 못
하셨다면 C 표준이나 C 언어를 제대로 기술하는 책을 다시 한번 보시기 바
랍니다. 참고로, volatile 에 대한 read 자체가 side effect 라는 논의는
이곳 (KLDP BBS) 에서도 있었습니다.
kyong wrote:
전 expression관점에서 본 것입니다. volatile이 side effect라는 사실에
동의합니다.
그리고 이 경우 앞에 a와 뒤에 a가 같은 값이 아니기 때문에 당연히
최적화 대상이 아닙니다. 님의 말에 의해 전혀 모순이 없습니다.
그리고 irc 어떤 사람이 말한 f(r);f(r); 예제를 버리고 H&S5 에서
예제를 선책한 이유입니다.
volatile 에 대해서 모든 가정을 버리고 처음부터 다시 공부하시기를 적극
추천합니다. 제가 보여드린 예와 H&S 의 예는 완전히 동일한 예입니다. 정
확히 volatile 대상체에 대한 2번의 접근이 유사한 성격의 이항 연산으로
연결되어 있으며, 두 sequence point 사이에 둘러싸인 형태입니다. 따라서,
제 예에 대해서는 volatile 대상체에 2번의 접근이 필요하다고 말씀하시는
반면, H&S 의 예에 대해서는 최적화가 가능하다는 주장하시는 것은 님 스스
로 모순된 상황을 만들고 계신 것입니다. 그리고 irc 에서 f(r); f(r); 에
대해서 어떤 잘못된 논의가 오고 갔는지 모르겠으나, r 이 volatile 로 한
정되어 있다면, f(r); f(r); 은 r 에 최소한 2번의 실제적인 접근이 있어야
합니다. H&S 와 제가 보여드린 예와, f(r); f(r); 은 완전히 다른 성격의
예입니다.
kyong wrote:
그러면,
i= a - a;
인 경우는 어떻게 된다고 생각하세요?
제가 보여드린 예와 + 연산이 - 연산으로 바뀐 것일 뿐, 동일한 예입니다.
이 경우에도 a 에 대한 최소한 2번 이상의 접근이 필요합니다. a 에 대한
접근을 register caching 하는 것은 허락되지 않습니다.
kyong wrote:
같은 값이 two sequence point에 쓰인 경우입니다.
한 reference로 처리 될 수 있는 부분이 아닌가 생각됩니다.
그래서 compiler에게 맞겨도 될 것이란 생각입니다.
님 (그리고 H&S 저자) 의 생각이지 진실이 아닙니다. 제가 보여드린 예도
모두 두개의 sequence point 사이에 쓰인 경우입니다. 제가 보기에는 님은
현재 sequence point 에 대해서도 오해하고 계신 부분이 있습니다.
kyong wrote:
제가 한 말을 잘 못 알아들으셨네요. 님이 한 말에 따라 semantic을 보장하면서
register caching을 막지 않는 예제가 나왔어야 하는데 volatile의 sematic을 보
장해서 register caching을 막는 예제가 나왔다는 것을 말합니다.
구구절절한 어셈블리어 코드를 쓰기 싫어 의도적으로 반대되는 예를 보이며
해당 문단의 의도를 설명한 것입니다.
kyong wrote:
그것이 최적화의 의미입니다. 그러나 volatile object는 다른 경우이기 때문에
예외를 두고 있다는 것을 잘 아시겠죠?
위에서 말씀드렸듯이 님의 volatile 에 대한 이해는 잘못되었습니다.
kyong wrote:
do_timer가 처한 상황은 두번째 문단에서 고려할 필요가 없다는 것이 원문
해석에 합당하다는 것을 위해서 밝혔습니다.
그렇다면 이제 왜 그 글쓴이가 간섭 가능한 연산을 non-volatile 로 제한했
는지 설명해 보실까요?
kyong wrote:
그리고 do_timer 상황에서는
delay가 생겨도 의미가 없음을 아래에서 밝히고 있습니다.
이는 이미 제가 반복하여 말씀드린 사실이고 참입니다.
kyong wrote:
그렇지만 volatile object는 main memory만을 가정하기 때문에
같은 프로그램에서 순서에 따라 의미가 delay가 생기기도 하지만 다른 프로
그램에서 접근하는 code에 의해서도 delay 내지는 값의 변경 되는 것입니다.
code가 어떻게 생성되더라도 결국 값은 main memory를 읽어서만 알 수 있는
것입니다.
일반적으로는 맞는 말씀입니다. 해당 글의 2번째 문단이 이 의도였는지는
별개의 문제입니다.
kyong wrote:
그렇지만 원저자가 value란 단어를 분명히 썼기 때문에 제가 한 말에 더 가깝
고 그것이 원래 volatile object를 잘 설명하고 있는 것입니다.
이 부분에서 님이 volatile 대상체에 대해서 일반적으로 하고 계시는 설명
에는 틀린 내용이 없습니다. 문제는 그 내용이 해당 글쓴이가 2번째 문단에
서 의도한 내용이냐, 아니냐 입니다. 이미 말씀드렸듯이, 해당 글쓴이가 말
하는 delay 는 "같은 프로그램의 실행 순서 재정렬" 에 의한 delay 입니다.
아니라고 생각하신다면, 왜 delay 에 영향을 줄 수 있는 연산을
non-volatile 로 제한했는지 설명해 보시기 바랍니다. 다른 processor 나
thread 에 의한 간섭까지 생각했다면 다른 프로그램의 volatile 연산 역시
영향주지 못할 이유가 없습니다. 반면, "같은" 프로그램의 "다른" volatile
연산은 (implementation 이 volatile 대상체 접근에 의한 side effect 를
모두 알기 이전에는) 해당 volatile 연산에 끼어들 수 없습니다.
kyong wrote:
아니라고 생각합니다. do_timer안에서는 non-volatile object가 아무리 얼켜
있다고 해도 결국 순서대로 실행되서 끝날 때 까지 아무 곳에서도 영향을 줄
수 없습니다. 즉, 값이 atomic하게 증가 된다는 말씀이죠. 그러니 do_timer안
에서 간섭의 의미는 무의미합니다.
이것이 제가 반복하여 말씀드리고 있는 것입니다! 같은 프로그램의
non-volatile 연산에 의한 간섭은 volatile 연산에 대해 delay 만 줄 뿐 결
국 결과에 아무런 영향을 주지 않습니다. 아무런 영향을 주지 않는 무의미
한 간섭이기 때문에 바로 그와 같은 프로그램 실행의 재정렬이 가능한 것입
니다.
kyong wrote:
저번에 얘기 했듯이 do_timer의 design을 몰랐다면 중간에 *& hack 이전에
jiffies++ 코드가 나오지 말알어야한다고 생각합니다.
반대로, *& hack 의 사용 목적이 성능 향상을 위한 최적화였다면 do_timer
의 역사에서 일관되게 성능 향상을 위한 최적화가 적용되었어야 한다는 것
입니다.
Quote:
과거 코드는 항상 개선 대상이죠. 현재 없어진 것은 근거가 되지 않습니까?
아전인수격의 해석입니다. 동등한 수준의 변화를 놓고, 하나는 님의 주장의
근거가 될 수 있는 반면, 다른 하나는 "개선 대상" 으로 치부되는 현장입니
다. 그와 같이 자의적이고 비논리적인 태도를 취하실 것이라면 논의에 참여
하는 의미 자체가 퇴색됩니다.
kyong wrote:
말씀하신 대로라면 volatile의 표준화는 완성된 것이 아니군요.
예, 맞습니다. volatile 은 "의도적으로" 불분명하게 정의되어 있습니다.
다만 과거 몇몇 논의에서 느낀 것은 그 불분명함이 너무 심해서 매우 간단
한 예에 대해서도 표준화 위원회 내에서 서로 다른 의견이 나온다는 것입니
다. 이 부분에 대해서는 제가 표준에 대한 defect report 를 작성 중에 있
습니다.
kyong wrote:
철학은 시대에 따라 바뀐다는 사실을 잊은 듯하네요.
잊지 않았기에 해당 이야기를 할 때
전웅 wrote:
그 이후의 미래는 역술인이 아닌 이상 맞추기 어렵겠지만, ...
와 같은 표현을 사용한 것입니다.
kyong wrote:
sparc/kernel/sun4d_smp.c swap 함수를 보시기 바랍니다.
어제 포스팅한 글에서 말씀드렸듯이 개인적인 시간이 많지 않아서 님께서
추가로 제시해주신 근거들을 주의깊게 확인해 볼 시간이 충분치 않습니다.
"원 개발자의 의도는 무엇인가?" 에 대한 문제는 추가로 제공해주신 근거들
을 확인해본 후에 이어나갔으면 합니다. 다만, 이번에 인용해주신 근거에
대해서 다음과 같은 질문을 드립니다.
(1) *& hack 을 오로지 volatile 한정을 제거하기 위한 목적으로만 사용한
것인지요?
(2) 해당 근거가 platform independent 한 부분에 속해있는 것인지요?
(3) platform independent 한 부분이 아니라면 해당 트릭이 RISC 인 SPARC
에서만 사용되는 것인지요, 아니면 CISC 에서도 사용되는 것인지요?
쓰레드가 길어지면서 이 스레드가 무슨 내용에 대해 이야기하고 있는 것인지, 쟁점이 되는 사안이 무엇인지 파악하기가 점점 힘들어지고 있습니다. 물론 이야기하고 계신 두분(전웅님, kyung님)은 잘 알겠지만 처음 읽는 사람들의 입장에서는 스레드 전체를 읽어 보아야 논의가 시작된 부분을 알 수 있기 때문에 시간이 많이 걸리게 됩니다.
그러므로 별다른 반대 의견이 없으면 이 스레드는 두분이 한번씩 더 글을 올릴 수 있는 기회를 드린 후 잠그도록 하고, 두분중 한분이 쟁점이 되는 사안을 따로 정리해서 새로운 스레드에 올려 주신 후 그 안에서 논의해 주시는게 좋을것 같습니다.
manual 을 다시 한번 확인해 보시기 바랍니다. SMP 에서는 어차피
atomicity 가 보장되지 않습니다.
24547212.pdf (chapter 7.1)
P3 용 manual 의 7.1.2.1 을 보면, 자동 lock 이 이루어지는 상황과, lock
을 위해 LOCK 을 붙일 수 있는 명령어가 나열되어 있습니다. 자동 lock 이
이루어지는 상황에는 inc 이 없으며, 반면 LOCK 을 붙여 lock 을 할 수 있
는 명령어에는 inc 가 있습니다. 이 내용은 님께서 인용하신 lkml 에도 나
와있는 바입니다. 해당 논의를 모두 읽어보셨다면 이처럼 잘못된 주장은 하
지 않으셨을 것입니다. 더이상 inc 가 모든 상황에서 atomicity 를 보장해
준다고 주장하시는 일이 없기를 바랍니다. 따라서, 이에 의존하여 밑에서
주장을 펼치신 부분은 잘못된 근거에 의존한 잘못된 주장이기에 답하지 않
겠습니다.
제가 모든 상황에서 inc가 atomicity를 보장해 준다고 한 적은 없습니다.
7.1.1을 보세요. memory operand의 의미를 아시기 바랍니다.
lock prefix는 필요 없습니다.
Quote:
kyong wrote:
volatile이 아닌 object에 대해서 그런 식의 최적화가 가능하다는 것은 알
알고 있습니다. 그러나 문제의 양상을 그렇게 표현한 것이 아니라고 봅니다.
volatile이 가지는 의미 자체로 그런 설명 조차 필요없다고 생각하지만
incl이 나온 배경의 한 근거를 제시했기에 인용된다는데는 동의하실 것입니다.
이것은 또 그 원문이 왜 나왔는지 정확한 배경을 이해해야 하는 것입니다. http://www.ussg.iu.edu/hypermail/linux/kernel/0001.0/0276.html
Jamie Lokier는 Andrea Arcangeli 쓴 차이가 없다는 말에 이런 차이를 생각
해서 했을 수도 있다라고 얘기하고 결과적으로 timer irq design에 의해 그
것 조차 필요없으므로 jiffies++도 괜찮을 것이다 라고 얘기하고 있습니다.
이것은 만약 timer irq가 그렇게 design 되지 않았다면 반드시 *& hack을 써야
한다는 말이 됩니다. 이것은 자명합니다.
만약, 문제가 되는 상황이 do_timer 가 아닌 다른 thread 나 processor 의
간섭이 있을 수 있는 상황이라면 "interrupt 에 대해서" inc 를 선택하는
것이 유효한 차이를 가져올 수 있습니다. 또한, 님은 inc 가 SMP 에서도
atomicity 를 보장해준다고 믿기 때문에, 그 차이는 매우 중요하다고 생각
하실 수 있습니다. 하지만, 위에서 말씀드렸듯이 inc 가 (SMP 를 포함한)
일반적인 상황에서는 어차피 atomicity 를 보장해주지 않기 때문에 그러한
차이는 님이 생각하고 계신 것보다 극단적인 모습을 보이게 됩니다.
제가 한 말은 분명히 interrupt 상황에서 incl 이라고 했습니다.
incl 메모리 는 분명히 보장해 준다는 것을 아셔야 합니다.
Quote:
kyong wrote:
그러면 volatile인 jiffies++가 일으키는 문제가 뭐기 때문에 volatile의
의미를 제거해서 ++ 해야 하는 것이 맞다라는 설명이 전제 돼야겠지요.
그 설명이 2번 째 단락인 것입니다. volatile인 경우에 어떤 문제가 있다라고
설명하는 자리에서 non volatile의 문제점을 거론하면서 volatile을 써야한다는
님의 설명이 맞지 않은 것은 당연하다고 전 생각합니다.
문제가 되는 2번째 단락에 대한 제 이해는 이렇습니다. 해당 글쓴이는 2번
째 단락을 통해 do_timer 문맥에서 (gcc 에 의해 이루어지는) volatile 대
상체로의 접근에 대한 일반적인 내용을 기술하고 있다는 것입니다. 즉, 같
은 do_timer 문맥이더라도 single insturction 을 사용했다면 발생하지 않
을 일이, (gcc 의 volatile 에 대한 다소 과도한 최적화 금지에 의해)
volatile 한정이 남아 있는 경우 생긴다는 것입니다. 하지만, do_timer 가
속해 있는 상황이 다른 프로그램의 간섭이 자연히 배제되는 상황이기 때문
에, 그 차이는 같은 프로그램 실행의 reordering 에 의해 non-volatile 연
산이나 함수 호출이 먼저 실행될 수 있는 차이뿐이 낳지 않는다는 것입니다.
만약, 님께서 다르게 생각하신다면 해당 글쓴이에게 직접 물어보시기 바랍
니다.
제가 말한 do_timer는 timer irq handler design에 의해 single threaded
라는 상황을 말하는 것입니다. 그래서 do_timer 문맥에서라고 하면 애초에
2번째 단락 자체를 언급할 필요가 없다는 것입니다.
값의 차이를 낳지 않는다면 왜 2번째 단락이 왜 들어간 것입니까?
그러나 gcc관점에서 do_timer가 single threaded라는 것을 뜻하지 않는
것이라면 바로 제가 원하던 문맥입니다. 그래서 interrupt에 걸린 상황에서
smp까지 고려해서 single instruction이 atomic한데 do_timer의 원래
문맥(single threaded)에서는 굳이 필요없다 이 말입니다.
Quote:
그리고, 만약 해당 글쓴이가 2번째 문단에서 같은 프로그램 실행의
reordering 뿐 아니라 프로그램 외부의 다른 요인에 의한 간섭까지도 생각
하고 있는 것이라면 왜 간섭할 수 있는 연산을 non-volatile 로 한정하여
설명하고 있는지 분명히 밝혀주시기 바랍니다. 이에 대해서는 단 한번도 답
하지 않으셨습니다.
이미 위에서 밝힌 것입니다.
외부 요인은 volatile object로서 일반론을 얘기한 것입니다.
제가 잘 못 생각한 것 중 하나는 읽는 관점에서 atomicity 해석을 시도한 점입
니다. 여기서는 쓰는 관점에서 생각해야 하므로 다른 프로세서로 volatile
value에 접근하는 문제라고 보는 것이 가장 정확할 것 같습니다.
Quote:
kyong wrote:
volatile은 분명 free reader를 위한 것입니다. multi processor, multi thread
환경에서 정확한 값을 보장해 주기 위해서는 적절한 design이 필요한 것입
니다. 표준에서 writer의 atomicity를 위해서 어떻게 하라든지 그런 말은
당연히 없습니다. jiffies 처럼 10ms를 보장 받지 않는 상황이라면 필요없겠
지요. 여전히 관련이 없다고 생각하세요?
volatile 이 multi processor/thread 상황까지 고려하여 적절한 설계가 필
요하다는 주장의 객관적 근거를 제시하시기 바랍니다. 반복하여 말씀드리지
만 표준은 (signal 이 존재하는) single thread 상황만을 고려한 C 언어의
spec 을 기술한 것이고, volatile 은 atomicity 와 아무런 관련이 없기 때
문에 async signal 에서 조차 접근에 대한 atomicity 를 보장해 주지 못합
니다 - 이것이 async signal 발생 시의 통신을 위해 volatile sig_atomic_t
형으로 선언된 static 대상체를 사용해야 하는 이유입니다. volatile 이
atomicity 를 보장해주지 않는다는 사실은 뉴스그룹의 여러 논의에서도 발
견할 수 있습니다. 어제 hclc 에 인용된 한 논의를 인용합니다 - C++ 에 대
한 논의이지만, volatile 을 C 언어가 (표준화 이전의) C++ 에서 빌려온 것
이기 때문에 미묘한 type algebra 를 제외하면 동일한 semantic 을 갖습니
다:
volatitle과 atomicity가 표준과 관련있다고 한 적이 없습니다. 그리고 제가
든 예제는 volatile이 사용될 수 있는 예로서 언급되고 있는 것입니다.
그리고 위에서 하신 말이 제가 한 말이라고 생각하세요?
volatile은 dynamic한 system programming에서 아주 유용한 개념입니다.
값을 쓴 후에 cache에 넣지 않고 잊어 버리는 것입니다. free reader로서 유용
한 개념이란 것을 이미 말씀드렸습니다. jiffy처럼 writer로서 atomic한
operation을 얘기한 것입니다. free writer가 아닙니다. synchronization,
mutex라는 개념이 왜 나왔다고 생각하세요? 아무 process에서 뒤죽박죽
쓴 값을 아무나 읽으려고 volatile로 선언할 수도 있겠지요.
Quote:
님은 계속해서 volatile 에 대한 잘못된 지식을 보여주고 계십니다. 근거도
존재하지 않는 보장에 함부로 의존하는 태도는 결코 안전한 프로그램 제작
에 도움이 되지 않습니다. 만약, 님의 말씀대로 volatile 이 atomicity 도
보장해줘야 하는 것이 사실이라면, 제가 알고 있는 대부분의
implementation 이 잘못된 것이 되어 버립니다. 분명,
implementation-defined access 이기에 implementation 이 추가적으로
volatile 에 atomic access/operation 의 의미를 부여할 수 있지만, 제가
아는 대부분의 환경에서 그렇지 않은 것이 사실입니다. 이미 위에서도
방준영님과 sliver 님의 논의를 보면, atomicity 를 위해 volatile 외에 다
른 장치를 사용하고 있는 것을 확인할 수 있습니다. 분명한 사실을 도처에
깔아놓은 상태에서 님이 믿고 있는 volatile 에 대한 잘못된 지식에만 의존
하는 이유도 이해하기 어렵습니다. 제 개인적인 또 이 글을 읽는 분들의 시
간 낭비를 막기 위해 앞으로 "분명한 객관적 근거를 인용하시기 이전에는"
님의 다음과 같은 주장에는 답하지 않겠습니다.
- volatile 이 multi thread/processor 환경에서 atomicity 를 보장한다.
- inc 는 모든 일반적인 상황에서도 atomicity 를 보장한다.
또한, 문제가 되고 있는 글의 2번째 문단에서 간섭할 수 있는 연산을
non-volatile 로 한정한 이유를 설명하지 못하신다면,
- 2번째 문단은 일반적인 상황에서 다른 프로그램에 의한 간섭을 포함하는
의도이다.
라는 주장 역시 답하지 않을 것입니다. 이는 님을 무시하거나 님의 기분을
불쾌하게 만들려는 의도가 절대 아닙니다. 저는 최선을 다해 님의 이해를
돕기 위해 노력했지만, 그와 같은 노력이 님의 그릇된 믿음 앞에서 간단히
무시되는 것 같아 앞으로 불필요한 노력을 하지 않겠다는 생각일 뿐입니다.
당연히 안 하셔도 됩니다. 제가 한 말이 아니니까요.
2번째 문단에서 의미는 좀 구체적인 의미로 정정했습니다. 그런데 님의 의견
은 reordering에 의해서 delay를 만들지만 차이가 없다로 끝나서 결국 아무
의미도 없는 말이 되었다는 것을 아시기 바랍니다.
Quote:
kyong wrote:
전 H&S5 92페이지에서 인용했는데 위 문서에서 언급된 곳은 못 찾겠더군요
그리고 최근 careferencemanual.com 에서 업데이트 된 내용에서도 전혀 찾
을 수 없더군요. .
혹시 링크를 아신다면 알려주시기 바랍니다.
변환 과정에서 side effect가 어떻게 생기는지 설명 부탁드립니다.
제 글을 "제대로" 읽어보신 후에 답변해 주시기 바랍니다. 저는 그 내용에
대한 지적을 H&S4 에 대해서 했으며, 개인적인 사정으로 H&S5 가 출판된 이
후에 저자에게 보냈습니다 - H&S5 가 출판된 한참 후에야 제가 H&S5 를 구
입했습니다. 저자는 제가 지적한 내용을 H&S4 에 대해서 검토했으며, 제게
H&S5 에서도 남아 있는 문제를 지적해 달라고 회신해 왔습니다. 제가 다른
바쁜 일로 H&S5 를 읽지 못하고 있기에 H&S5 에 대한 적용이 늦어지는 것입
니다. 인용된 PDF 문서의 6쪽을 보시기 바랍니다.
그리고, 해당 예제에서 side effect 가 어떻게 생길 수 있는지 이해하지 못
하셨다면 C 표준이나 C 언어를 제대로 기술하는 책을 다시 한번 보시기 바
랍니다. 참고로, volatile 에 대한 read 자체가 side effect 라는 논의는
이곳 (KLDP BBS) 에서도 있었습니다.
volatile이 sequence point라는데 당연히 동의합니다.
volatile 자체가 side effect가 현실적으로 아닌 경우가 있을 것이라고 생각
됩니다. hardware I/O와 같은 경우를 어떻게 생각하시는지요.
Quote:
kyong wrote:
전 expression관점에서 본 것입니다. volatile이 side effect라는 사실에
동의합니다.
그리고 이 경우 앞에 a와 뒤에 a가 같은 값이 아니기 때문에 당연히
최적화 대상이 아닙니다. 님의 말에 의해 전혀 모순이 없습니다.
그리고 irc 어떤 사람이 말한 f(r);f(r); 예제를 버리고 H&S5 에서
예제를 선책한 이유입니다.
volatile 에 대해서 모든 가정을 버리고 처음부터 다시 공부하시기를 적극
추천합니다. 제가 보여드린 예와 H&S 의 예는 완전히 동일한 예입니다. 정
확히 volatile 대상체에 대한 2번의 접근이 유사한 성격의 이항 연산으로
연결되어 있으며, 두 sequence point 사이에 둘러싸인 형태입니다. 따라서,
제 예에 대해서는 volatile 대상체에 2번의 접근이 필요하다고 말씀하시는
반면, H&S 의 예에 대해서는 최적화가 가능하다는 주장하시는 것은 님 스스
로 모순된 상황을 만들고 계신 것입니다. 그리고 irc 에서 f(r); f(r); 에
대해서 어떤 잘못된 논의가 오고 갔는지 모르겠으나, r 이 volatile 로 한
정되어 있다면, f(r); f(r); 은 r 에 최소한 2번의 실제적인 접근이 있어야
합니다. H&S 와 제가 보여드린 예와, f(r); f(r); 은 완전히 다른 성격의
예입니다.
제가 아니라고 한 얘기는 인용하지 마시기 바랍니다.
H&S5 에서 예제에 대해서는 동의합니다. 그러나 원래 의도했던 의미는
two sequenc point 사이에 one reference가 쓰인 경우에 가능하다는
것입니다.
implementaion defined 부분은
What constitutes an access to an object that has volatile-qualified type (6.7.3).
인데, volatile object에 one store operation은 hardware적으로 one store operation에 해당하고 read의 경우도 마찬가지이고 인접한
sequence point 사이에 n read 가 있다면 n개 까지 load는 자유롭게 할 수
있다는 생각입니다.(이것은 뉴스그룹에서 읽은 얘기입니다.)
Quote:
kyong wrote:
그러면,
i= a - a;
인 경우는 어떻게 된다고 생각하세요?
제가 보여드린 예와 + 연산이 - 연산으로 바뀐 것일 뿐, 동일한 예입니다.
이 경우에도 a 에 대한 최소한 2번 이상의 접근이 필요합니다. a 에 대한
접근을 register caching 하는 것은 허락되지 않습니다.
expressions evaluation 관점에서 무의미하게 제거될 가능성에 대해서
생각해 본 것입니다. gcc가 어떻게 만들지 알아보는 것은 흥미 있을 것
같습니다. system programming 관점에서 중요한 문제라고 생각합니다.
Quote:
kyong wrote:
do_timer가 처한 상황은 두번째 문단에서 고려할 필요가 없다는 것이 원문
해석에 합당하다는 것을 위해서 밝혔습니다.
그렇다면 이제 왜 그 글쓴이가 간섭 가능한 연산을 non-volatile 로 제한했
는지 설명해 보실까요?
volatile object는 reordering 대상이 아니라서 volatile object 끼리 ordering이 안지켜지는 경우는 없다는 답변을 원하세요? 그건 핵심과 상관없
는 얘기란 걸 아셔야 합니다. volatile object가 하나 뿐이고 쓰는 함수도 하나
뿐인 상황입니다.(single thread를 떠나서) 다른 processor를 고려하지 않고
서는 설명이 되지 않는다는 것을 아시기 바랍니다.
Quote:
kyong wrote:
그렇지만 원저자가 value란 단어를 분명히 썼기 때문에 제가 한 말에 더 가깝
고 그것이 원래 volatile object를 잘 설명하고 있는 것입니다.
이 부분에서 님이 volatile 대상체에 대해서 일반적으로 하고 계시는 설명
에는 틀린 내용이 없습니다. 문제는 그 내용이 해당 글쓴이가 2번째 문단에
서 의도한 내용이냐, 아니냐 입니다. 이미 말씀드렸듯이, 해당 글쓴이가 말
하는 delay 는 "같은 프로그램의 실행 순서 재정렬" 에 의한 delay 입니다.
아니라고 생각하신다면, 왜 delay 에 영향을 줄 수 있는 연산을
non-volatile 로 제한했는지 설명해 보시기 바랍니다. 다른 processor 나
thread 에 의한 간섭까지 생각했다면 다른 프로그램의 volatile 연산 역시
영향주지 못할 이유가 없습니다. 반면, "같은" 프로그램의 "다른" volatile
연산은 (implementation 이 volatile 대상체 접근에 의한 side effect 를
모두 알기 이전에는) 해당 volatile 연산에 끼어들 수 없습니다.
위에서 말한 부분입니다. smp에서는 같은 volatile object writer가 문제를
일으키는 것입니다.(timer IRQ design 문제를 고려하지 않은 상황이고요.)
non-volatile 때문에 더 심해진다고 할 수는 있겠지요. 위에서 한 얘기 같은데
현실적으로 unction에서 volatile object 앞뒤로 재 정렬이 일어나지 read,
increment, rite 사이에 일어날 가능성은 적다고 생각되기에 더 심해지는 경우
도 극히 물다고 할 수 있겠습니다. 아마 gcc가 그런 코드를 만들었다면
implementation define 된 부분이라고 자기들을 방어하겠고 개발자들은
gcc 무지 욕할 것 같네요.
Quote:
Quote:
과거 코드는 항상 개선 대상이죠. 현재 없어진 것은 근거가 되지 않습니까?
아전인수격의 해석입니다. 동등한 수준의 변화를 놓고, 하나는 님의 주장의
근거가 될 수 있는 반면, 다른 하나는 "개선 대상" 으로 치부되는 현장입니
다. 그와 같이 자의적이고 비논리적인 태도를 취하실 것이라면 논의에 참여
하는 의미 자체가 퇴색됩니다.
과거에 있었다고 불완전하다고 하니 같은 의미에서 하는 말입니다.
Quote:
kyong wrote:
말씀하신 대로라면 volatile의 표준화는 완성된 것이 아니군요.
예, 맞습니다. volatile 은 "의도적으로" 불분명하게 정의되어 있습니다.
다만 과거 몇몇 논의에서 느낀 것은 그 불분명함이 너무 심해서 매우 간단
한 예에 대해서도 표준화 위원회 내에서 서로 다른 의견이 나온다는 것입니
다. 이 부분에 대해서는 제가 표준에 대한 defect report 를 작성 중에 있
습니다.
수고하십니다.
지금 제 관심은 sequence point 사이의 one reference에 대한(hardware
I/O) 님의 생각을 아는 정도입니다. 주제가 이미 해결된 상황에서(최소한 제 생
각은) 곁가지로 나온 문제로 이 thread의 의미를 놓치게 할 수는 없으니까요.
제가 한 말은 분명히 interrupt 상황에서 incl 이라고 했습니다.
incl 메모리 는 분명히 보장해 준다는 것을 아셔야 합니다.
- A 는 X 라면 B 이고 Y 라면 C 이다
이것이 님이 이 논의에 참여하기 이전에 내려진 기술적 결론이라면, 님은
갑자기
- A 는 C 이다
라고 말씀하십니다. 그러면 전 그렇지 않다는 것을 설명하고, 곧 이어 님은
- A 가 모든 경우에 C 라고 한 적은 없다. X 면 B 이고 Y 면 C 이다
라고 말씀하십니다. 님이 지금까지의 기술적 내용에 취한 행동이 얼마나 무
가치하고 무책임한 일인지 생각해 보시기 바랍니다.
kyong wrote:
제가 말한 do_timer는 timer irq handler design에 의해 single threaded
라는 상황을 말하는 것입니다. 그래서 do_timer 문맥에서라고 하면 애초에
2번째 단락 자체를 언급할 필요가 없다는 것입니다.
single thread 여도 같은 프로그램의 non-volatile 연산에 의해 volatile
에 대한 단위 instruction 의 일부가 delay 될 수 있습니다. 님께서 반복하
여 2번째 문단에 대해서 이의를 제기하셔서 이 논의가 진행되는 동안 원 글
쓴이에게 메일을 보내
Quote:
And the store may be deferred past other
non-volatile operations and function calls.
문장의 의도를
Quote:
And the store may be deferred past other
non-volatile operations and function calls (in the same program).
로 이해할 수 있다는 답을 얻었습니다.
kyong wrote:
값의 차이를 낳지 않는다면 왜 2번째 단락이 왜 들어간 것입니까?
글쓴이가 자기가 알고 있는 바를 추가로 이야기하는 것이 문제가 된다는 뜻
입니까? 어쩌면 이 thread 에서처럼 do_timer 를 jiffies++; 로 바꿔 컴파
일했을 때 volatile 연산의 일부가 같은 프로그램에 의해 reordering 되는
것을 궁금해할 사람을 위해 그와 같은 설명을 넣었을 수도 있습니다. 즉,
단일 instruction 이 아닌 여러 instruction 으로 하나의 논리적 operation
이 구성되었을 때 발생하는 (최종적인 결과에는 영향을 주지 않는) 사소한
차이를 언급하기 위한 것일 수도 있습니다. 더이상 의미가 분명한 2번째 문
단에 대해서는 이의 제기는 불필요합니다.
kyong wrote:
그러나 gcc관점에서 do_timer가 single threaded라는 것을 뜻하지 않는
것이라면 바로 제가 원하던 문맥입니다. 그래서 interrupt에 걸린 상황에서
smp까지 고려해서 single instruction이 atomic한데 do_timer의 원래
문맥(single threaded)에서는 굳이 필요없다 이 말입니다.
님이 2번째 문단에서 설명하는 delay 를 제대로 이해하고 계시지 못하기 때
문에 계속 그와 같은 의심을 버리실 수 없다고 생각합니다. 2번째 문단의
제대로 된 의미는 이 thread 의 초반부에 있는 제 글에서 설명하고 있습니
다. 읽어보시고 이해가 되지 않는 부분을 질문해 주시기 바랍니다.
kyong wrote:
volatitle과 atomicity가 표준과 관련있다고 한 적이 없습니다.
님이 했던 말씀 중에서 인용합니다.
kyong wrote:
volatile은 main memory에서의 여러 방법으로 값이 변경될 수 있음을 규정하기
때문에 atomicity를 위해서 별도의 design을 강요하는 것입니다.
그럼, 기타 어떤 표준이 volatile 에 atomicity 의 의미를 보장하지 않는데
(관련되어 있지 않은데) 대체 누가 atomicity 를 위한 별도의 design 을
"강요" 한다는 말입니까?
기술적으로 잘못된 내용을 적었을 때 사과하는 모습이 좋은 태도라고 말씀
하신 것으로 기억하고 있습니다.
kyong wrote:
전웅 wrote:
저는 제가 말씀드린 기술적인 내용 중에 오류가 있다면 분명 사과드립니다.
이는 일정 시간동안 제 말을 믿고 잘못된 내용을 진실로 알고 계신 분들에
대한 사과입니다. 이는 제 글의 신뢰성을 높이기 위한 방법이며, 그 신뢰성
을 위해 글을 쓰기 전에 관련된 내용을 재확인해보도록 해주는 장치이기도
합니다.
아주 좋은 습관이라고 생각됩니다.
님께서도 좋은 습관을 가지시길 바랍니다.
kyong wrote:
free reader로서 유용
한 개념이란 것을 이미 말씀드렸습니다. jiffy처럼 writer로서 atomic한
operation을 얘기한 것입니다. free writer가 아닙니다.
결국, 표준의 volatile 에 대한 최소한의 요구와 마찬가지로
implementation 은 volatile 에 대해서 atomicity 와 관련해서는 별도의 보
장을 해줄 필요가 없는 거로군요 - 이는 제가 지금까지 반복해서 말씀드린
바입니다! 그리고 동시에 님이 이전에 말씀하신 것과 상반되는 이야기입니
다! 알고 계신 내용을 표현하는 것에 서투신 것인지, 아니면 내용이 진행됨
에 따라 말을 바꾸고 계신 것인지 알기 어렵습니다.
kyong wrote:
2번째 문단에서 의미는 좀 구체적인 의미로 정정했습니다. 그런데 님의 의견
은 reordering에 의해서 delay를 만들지만 차이가 없다로 끝나서 결국 아무
의미도 없는 말이 되었다는 것을 아시기 바랍니다.
그와 같은 delay 가 유효한 차이를 만들어야만 해당 delay 에 대해서 설명
할 수 있는 것은 아닙니다. 이 thread 에서도 볼 수 있듯이 그와 같은
delay 가 실제로 일어나고 있으며, 그것이 volatile 의 semantic 을 망치지
는 않는지 혹은 허락되는 것인지 혹은 (단일 instruction 과 비교해) 어떤
유효한 차이를 만드는 것은 아닌지 의심하는 사람이 있을 수 있습니다 - 또
한, 실제로 있었습니다. 이에 대해 미리 설명하는 것이 죄일 수는 없습니다.
kyong wrote:
volatile이 sequence point라는데 당연히 동의합니다.
volatile 이 sequence point 라는 뜻이 아니었습니다. 제발 부탁드리지만
volatile 과 sequence point 에 대해서 C 표준 혹은 C 표준을 잘 설명하는
책을 다시 보신 후에 의심이 되는 부분을 질문해 주시기 바랍니다.
volatile 과 sequence point 에 대한 이해가 결여된 상태에서 어떻게 까다
로운 내용에 대한 기술적 토론이 오해 없이 가능하겠습니까. 이런 상황에서
는 같은 개념을 설명해도 서로 다른 방법을 사용하게 되므로 끝없는 오해만
되풀이될 뿐입니다.
kyong wrote:
volatile 자체가 side effect가 현실적으로 아닌 경우가 있을 것이라고 생각
됩니다. hardware I/O와 같은 경우를 어떻게 생각하시는지요.
volatile 이 side effect 라는 것은 표준의 "정의" 입니다. 이는 일부 IO
에서 volatile 대상체에 대한 단순한 read 가 실제적이고 가시적인 side
effect 를 낳지 않는다해도 변하는 사실이 아닙니다. 님과 같은 논리라면
"왜 물 한방울에 한방울을 더하면 두방울이 아닌 한방울인데 1+1=2 라고 하
느냐?" 라고 묻는 것과 동일합니다.
kyong wrote:
implementaion defined 부분은
What constitutes an access to an object that has volatile-qualified type (6.7.3).
인데,
H&S 의 예제나 제가 보여드린 예제와 무관한 부분입니다.
kyong wrote:
volatile object에 one store operation은 hardware적으로 one store operation에 해당하고 read의 경우도 마찬가지이고 인접한
sequence point 사이에 n read 가 있다면 n개 까지 load는 자유롭게 할 수
있다는 생각입니다.(이것은 뉴스그룹에서 읽은 얘기입니다.)
n개까지의 load 가 자유로운 정도가 아니라 반드시 있어야 한다는 것이 표
준의 요구입니다.
kyong wrote:
expressions evaluation 관점에서 무의미하게 제거될 가능성에 대해서
생각해 본 것입니다. gcc가 어떻게 만들지 알아보는 것은 흥미 있을 것
같습니다.
해당 volatile 대상체에 이루어지는 접근이 만드는 side effect 를
implementation 이 모두 예측할 수 없는 이상, 수식 평가 차원에서 제거되
어서는 안 된다는 것이 표준의 "요구" 입니다. volatile 에 대해서 다시 한
번 자세히 알아보시기를 진심으로 부탁드립니다.
gcc 는 volatile 대상체 접근에 대해 어떠한 "예측" 도 하지 않습니다. 따
라서 gcc 가 해당 수식을 최적화하는 일은 없습니다 - 이는 다수의 다른
implementation 에서도 적용되는 이야기입니다.
kyong wrote:
volatile object는 reordering 대상이 아니라서 volatile object 끼리 ordering이 안지켜지는 경우는 없다는 답변을 원하세요? 그건 핵심과 상관없
는 얘기란 걸 아셔야 합니다. volatile object가 하나 뿐이고 쓰는 함수도 하나
뿐인 상황입니다.(single thread를 떠나서) 다른 processor를 고려하지 않고
서는 설명이 되지 않는다는 것을 아시기 바랍니다.
"같은" 프로그램의 "다른" non-volatile operation 이 이미 끼어들 수 있는
(또한 끼어들고 있는) 상황에서 "다른" processor 나 "다른" thread 만을
고려할 필요는 이미 없습니다. 또한, "다른" processor/thread 의 간섭이
가능하다면 "다른" processor/thread 의 volatile operation 이 배제될 이
유가 없는 상황입니다 - 이는 do_timer 와 같은 특수한 상황이 아닐때,
atomicity 를 위한 별도의 장치를 사용하는 중요한 이유입니다. 따라서, 해
당 글쓴이는 single thread 문맥에서 "같은" 프로그램의 "다른" non-
volatile operation 이 끼어드는 것에 대해서 이야기하고 있는 것입니다 -
이는 분명한 사실로 밝혀졌으므로 더 이상 이의의 가능성이 없습니다. 이해
되지 않는 부분 있으면 질문해 주시기 바랍니다.
kyong wrote:
지금 제 관심은 sequence point 사이의 one reference에 대한(hardware
I/O) 님의 생각을 아는 정도입니다.
제 생각을 알려고 하시기 전에 volatile 과 sequence point 에 대해서 다시
한번 알아보셨으면 합니다. 이 상태에서는 제가 제 생각을 잘 설명드린다고
해도 의사소통에 오해만 발생할 수 있습니다 - 더구나 저는 글을 친절히 잘
쓰지도 못합니다. 표준이 기술하고 있는 volatile 은 실제로는 몇부분 되지
않지만 상당히 어려운 기술적인 문제가 관련되어 있습니다.
kyong wrote:
주제가 이미 해결된 상황에서(최소한 제 생
각은) 곁가지로 나온 문제로 이 thread의 의미를 놓치게 할 수는 없으니까요.
주제는 해결된 것이 아니라 잠시 보류되어 있는 상태입니다. 추가로 제공해
주신 근거 (이 근거들에 대해서는 진심으로 감사하게 생각합니다) 는 여유
가 생기는대로 확인해 보도록 하겠습니다. 제 이전 글에서도 보셨겠지만,
새로운 근거에 대해 고려할 문제가 많기에 어설프게 훑어보고 결론 내리고
싶지 않아서 따로 시간을 내어 천천히 살펴볼 생각입니다.
그리고, 제 글을 마지막으로 관리자님에 의해 이 thread 가 닫힐 수도 있습
니다. 제 글에 추가적인 답을 하시려면 별도의 새로운 thread 를 만들어 주
시기 바랍니다.
댓글
[quote][quote="kyong"][quote="전웅"]- 그렇
24547212.pdf (chapter 7.1)
volatile이 아닌 object에 대해서 그런 식의 최적화가 가능하다는 것은 알
알고 있습니다. 그러나 문제의 양상을 그렇게 표현한 것이 아니라고 봅니다.
volatile이 가지는 의미 자체로 그런 설명 조차 필요없다고 생각하지만
incl이 나온 배경의 한 근거를 제시했기에 인용된다는데는 동의하실 것입니다.
이것은 또 그 원문이 왜 나왔는지 정확한 배경을 이해해야 하는 것입니다.
http://www.ussg.iu.edu/hypermail/linux/kernel/0001.0/0276.html
Jamie Lokier는 Andrea Arcangeli 쓴 차이가 없다는 말에 이런 차이를 생각
해서 했을 수도 있다라고 얘기하고 결과적으로 timer irq design에 의해 그
것 조차 필요없으므로 jiffies++도 괜찮을 것이다 라고 얘기하고 있습니다.
이것은 만약 timer irq가 그렇게 design 되지 않았다면 반드시 *& hack을 써야
한다는 말이 됩니다. 이것은 자명합니다.
그러면 volatile인 jiffies++가 일으키는 문제가 뭐기 때문에 volatile의
의미를 제거해서 ++ 해야 하는 것이 맞다라는 설명이 전제 돼야겠지요.
그 설명이 2번 째 단락인 것입니다. volatile인 경우에 어떤 문제가 있다라고
설명하는 자리에서 non volatile의 문제점을 거론하면서 volatile을 써야한다는
님의 설명이 맞지 않은 것은 당연하다고 전 생각합니다.
위에서 얘기한 store buffer는 단지 read, write 시점이 달라서 메인 메모리에서
값이 보장되지 않는 한 예일 수 있다는 것을 보인 것입니다.
volatile은 분명 free reader를 위한 것입니다. multi processor, multi thread
환경에서 정확한 값을 보장해 주기 위해서는 적절한 design이 필요한 것입
니다. 표준에서 writer의 atomicity를 위해서 어떻게 하라든지 그런 말은
당연히 없습니다. jiffies 처럼 10ms를 보장 받지 않는 상황이라면 필요없겠
지요. 여전히 관련이 없다고 생각하세요?
제 기대는 incl %eax 보다는 incl 0x80484a8 입니다.
asynchronous signal handler에 의해 수정되는 object인 경우 volatile로 선언
할 대상인 것입니다. 접근에 대한 atomicity와는 완전히 다른 얘기입니다.
a = jiffies;
while (a == jiffies) ;
true가 되지 않는 것입니다.
위에서 얘기 했듯이 표준에 있다는 얘기가 아니고 현실적인 사용에서 필요한
부분이란 것을 얘기합니다.
전 H&S5 92페이지에서 인용했는데 위 문서에서 언급된 곳은 못 찾겠더군요
그리고 최근 careferencemanual.com 에서 업데이트 된 내용에서도 전혀 찾
을 수 없더군요. .
혹시 링크를 아신다면 알려주시기 바랍니다.
변환 과정에서 side effect가 어떻게 생기는지 설명 부탁드립니다.
전 expression관점에서 본 것입니다. volatile이 side effect라는 사실에
동의합니다.
그리고 이 경우 앞에 a와 뒤에 a가 같은 값이 아니기 때문에 당연히
최적화 대상이 아닙니다. 님의 말에 의해 전혀 모순이 없습니다.
그리고 irc 어떤 사람이 말한 f(r);f(r); 예제를 버리고 H&S5 에서
예제를 선책한 이유입니다.
그러면,
i= a - a;
인 경우는 어떻게 된다고 생각하세요?
register int temp = j;
if (f(temp*temp))
경우 위 경우와는 좀 다른 경우입니다.
f(temp*temp) // sequence point
if ( * ) // sequence point
같은 값이 two sequence point에 쓰인 경우입니다.
한 reference로 처리 될 수 있는 부분이 아닌가 생각됩니다.
그래서 compiler에게 맞겨도 될 것이란 생각입니다.
제가 한 말을 잘 못 알아들으셨네요. 님이 한 말에 따라 semantic을 보장하면서
register caching을 막지 않는 예제가 나왔어야 하는데 volatile의 sematic을 보
장해서 register caching을 막는 예제가 나왔다는 것을 말합니다.
그것이 최적화의 의미입니다. 그러나 volatile object는 다른 경우이기 때문에
예외를 두고 있다는 것을 잘 아시겠죠? volatile이기 때문에 read, write access
사이에 값이 변경되지 않음을 보장 못한다는 것을 이해하셨다면 의미가
자명합니다.
do_timer가 처한 상황은 두번째 문단에서 고려할 필요가 없다는 것이 원문
해석에 합당하다는 것을 위해서 밝혔습니다. 그리고 do_timer 상황에서는
delay가 생겨도 의미가 없음을 아래에서 밝히고 있습니다.
제가 생각한 것은 코드가 생성될 때 있는 상황이 아니라 실행 시점에 중심을
둔 것이고 님은 코드자체가 생성될 때 이미 가지는 의미에 중심을 둔 것 같
습니다. 그렇지만 volatile object는 main memory만을 가정하기 때문에
같은 프로그램에서 순서에 따라 의미가 delay가 생기기도 하지만 다른 프로
그램에서 접근하는 code에 의해서도 delay 내지는 값의 변경 되는 것입니다.
code가 어떻게 생성되더라도 결국 값은 main memory를 읽어서만 알 수 있는
것입니다. 결국 read, increment, store 에서 근본적으로 생기는 delay를 말하
는 것입니다. 결국 두 의미가 모두 volatile object에 있는 요소라고 생각합니다.
그렇지만 원저자가 value란 단어를 분명히 썼기 때문에 제가 한 말에 더 가깝
고 그것이 원래 volatile object를 잘 설명하고 있는 것입니다.
위에서 제가 한 설명을 잘 읽어 보시기 바랍니다.
아니라고 생각합니다. do_timer안에서는 non-volatile object가 아무리 얼켜
있다고 해도 결국 순서대로 실행되서 끝날 때 까지 아무 곳에서도 영향을 줄
수 없습니다. 즉, 값이 atomic하게 증가 된다는 말씀이죠. 그러니 do_timer안
에서 간섭의 의미는 무의미합니다.
저번에 얘기 했듯이 do_timer의 design을 몰랐다면 중간에 *& hack 이전에
jiffies++ 코드가 나오지 말알어야한다고 생각합니다.
과거 코드는 항상 개선 대상이죠. 현재 없어진 것은 근거가 되지 않습니까?
말씀하신 대로라면 volatile의 표준화는 완성된 것이 아니군요.
철학은 시대에 따라 바뀐다는 사실을 잊은 듯하네요. 결론을 요약하실 때는
모두 반영하시기 바랍니다.
sparc/kernel/sun4d_smp.c swap 함수를 보시기 바랍니다.
platform independent 하다는 말은 incl을 똑같이 말들어 준다는 말이 아닙니다.
님께서도 이미 한 얘기입니다. asm 버젼을 만들지 않은 이유를 뜻합니다.
근거도 없이 읽어 봤냐고 하시길래 늘 친숙한 만큼 잘 읽는다는 뜻이였습니다.
아주 좋은 습관이라고 생각됩니다.
[quote="kyong"][quote="전웅"]manual 을 다시 한
P3 용 manual 의 7.1.2.1 을 보면, 자동 lock 이 이루어지는 상황과, lock
을 위해 LOCK 을 붙일 수 있는 명령어가 나열되어 있습니다. 자동 lock 이
이루어지는 상황에는 inc 이 없으며, 반면 LOCK 을 붙여 lock 을 할 수 있
는 명령어에는 inc 가 있습니다. 이 내용은 님께서 인용하신 lkml 에도 나
와있는 바입니다. 해당 논의를 모두 읽어보셨다면 이처럼 잘못된 주장은 하
지 않으셨을 것입니다. 더이상 inc 가 모든 상황에서 atomicity 를 보장해
준다고 주장하시는 일이 없기를 바랍니다. 따라서, 이에 의존하여 밑에서
주장을 펼치신 부분은 잘못된 근거에 의존한 잘못된 주장이기에 답하지 않
겠습니다.
그리고, 반복하여 부탁드리지만, 확실한 근거나 이해가 부족한 상태에서
(여러 사람이 분명한 여러 근거 확인을 통해) 이미 논의가 종료된 사실에
대해서 단정적인 태도로 "틀렸음" 을 제기하지 않으셨으면 좋겠습니다. 님
이 의심이 가는 부분이나 근거는 불충분하지만 잘못된 것 같다고 생각하는
부분이 있다면 질문으로도 충분히 사실을 확인할 수 있습니다. 왜 잘못된
이해와 근거에 의존하여 단정적인 표현을 사용해 사실을 왜곡하려 하시는지
그 의도를 알기 어렵습니다.
만약, 문제가 되는 상황이 do_timer 가 아닌 다른 thread 나 processor 의
간섭이 있을 수 있는 상황이라면 "interrupt 에 대해서" inc 를 선택하는
것이 유효한 차이를 가져올 수 있습니다. 또한, 님은 inc 가 SMP 에서도
atomicity 를 보장해준다고 믿기 때문에, 그 차이는 매우 중요하다고 생각
하실 수 있습니다. 하지만, 위에서 말씀드렸듯이 inc 가 (SMP 를 포함한)
일반적인 상황에서는 어차피 atomicity 를 보장해주지 않기 때문에 그러한
차이는 님이 생각하고 계신 것보다 극단적인 모습을 보이게 됩니다.
문제가 되는 2번째 단락에 대한 제 이해는 이렇습니다. 해당 글쓴이는 2번
째 단락을 통해 do_timer 문맥에서 (gcc 에 의해 이루어지는) volatile 대
상체로의 접근에 대한 일반적인 내용을 기술하고 있다는 것입니다. 즉, 같
은 do_timer 문맥이더라도 single insturction 을 사용했다면 발생하지 않
을 일이, (gcc 의 volatile 에 대한 다소 과도한 최적화 금지에 의해)
volatile 한정이 남아 있는 경우 생긴다는 것입니다. 하지만, do_timer 가
속해 있는 상황이 다른 프로그램의 간섭이 자연히 배제되는 상황이기 때문
에, 그 차이는 같은 프로그램 실행의 reordering 에 의해 non-volatile 연
산이나 함수 호출이 먼저 실행될 수 있는 차이뿐이 낳지 않는다는 것입니다.
만약, 님께서 다르게 생각하신다면 해당 글쓴이에게 직접 물어보시기 바랍
니다.
그리고, 만약 해당 글쓴이가 2번째 문단에서 같은 프로그램 실행의
reordering 뿐 아니라 프로그램 외부의 다른 요인에 의한 간섭까지도 생각
하고 있는 것이라면 왜 간섭할 수 있는 연산을 non-volatile 로 한정하여
설명하고 있는지 분명히 밝혀주시기 바랍니다. 이에 대해서는 단 한번도 답
하지 않으셨습니다.
자꾸 메인 메모리에서 값이 보장되지 않는다고 말씀하고 계시는데,
이는 위와 상황에서 inc r1 과 store r1 into i 사이에 메모리 i 에 저장된
값이 달라질 수 있음을 의미하고 계신 것이라 생각합니다. do_timer 와 같
이 간섭이 철저히 배제되지 않은 상황이라면 이는 가능합니다. 하지만, 논
의가 이루어지는 do_timer 문맥에서는 불필요한 걱정입니다.
논의가 진행 중인 do_timer 문맥이 아닌 일반적인 상황에 대한 고찰은 분리
하여 해주시기 바랍니다. 괜한 오해를 낳을 수 있습니다.
volatile 이 multi processor/thread 상황까지 고려하여 적절한 설계가 필
요하다는 주장의 객관적 근거를 제시하시기 바랍니다. 반복하여 말씀드리지
만 표준은 (signal 이 존재하는) single thread 상황만을 고려한 C 언어의
spec 을 기술한 것이고, volatile 은 atomicity 와 아무런 관련이 없기 때
문에 async signal 에서 조차 접근에 대한 atomicity 를 보장해 주지 못합
니다 - 이것이 async signal 발생 시의 통신을 위해 volatile sig_atomic_t
형으로 선언된 static 대상체를 사용해야 하는 이유입니다. volatile 이
atomicity 를 보장해주지 않는다는 사실은 뉴스그룹의 여러 논의에서도 발
견할 수 있습니다. 어제 hclc 에 인용된 한 논의를 인용합니다 - C++ 에 대
한 논의이지만, volatile 을 C 언어가 (표준화 이전의) C++ 에서 빌려온 것
이기 때문에 미묘한 type algebra 를 제외하면 동일한 semantic 을 갖습니
다:
http://groups.google.com/groups?threadm=b9a051e6.0211031951.706bd8b6%40posting.google.com
님은 계속해서 volatile 에 대한 잘못된 지식을 보여주고 계십니다. 근거도
존재하지 않는 보장에 함부로 의존하는 태도는 결코 안전한 프로그램 제작
에 도움이 되지 않습니다. 만약, 님의 말씀대로 volatile 이 atomicity 도
보장해줘야 하는 것이 사실이라면, 제가 알고 있는 대부분의
implementation 이 잘못된 것이 되어 버립니다. 분명,
implementation-defined access 이기에 implementation 이 추가적으로
volatile 에 atomic access/operation 의 의미를 부여할 수 있지만, 제가
아는 대부분의 환경에서 그렇지 않은 것이 사실입니다. 이미 위에서도
방준영님과 sliver 님의 논의를 보면, atomicity 를 위해 volatile 외에 다
른 장치를 사용하고 있는 것을 확인할 수 있습니다. 분명한 사실을 도처에
깔아놓은 상태에서 님이 믿고 있는 volatile 에 대한 잘못된 지식에만 의존
하는 이유도 이해하기 어렵습니다. 제 개인적인 또 이 글을 읽는 분들의 시
간 낭비를 막기 위해 앞으로 "분명한 객관적 근거를 인용하시기 이전에는"
님의 다음과 같은 주장에는 답하지 않겠습니다.
- volatile 이 multi thread/processor 환경에서 atomicity 를 보장한다.
- inc 는 모든 일반적인 상황에서도 atomicity 를 보장한다.
또한, 문제가 되고 있는 글의 2번째 문단에서 간섭할 수 있는 연산을
non-volatile 로 한정한 이유를 설명하지 못하신다면,
- 2번째 문단은 일반적인 상황에서 다른 프로그램에 의한 간섭을 포함하는
의도이다.
라는 주장 역시 답하지 않을 것입니다. 이는 님을 무시하거나 님의 기분을
불쾌하게 만들려는 의도가 절대 아닙니다. 저는 최선을 다해 님의 이해를
돕기 위해 노력했지만, 그와 같은 노력이 님의 그릇된 믿음 앞에서 간단히
무시되는 것 같아 앞으로 불필요한 노력을 하지 않겠다는 생각일 뿐입니다.
제 글을 "제대로" 읽어보신 후에 답변해 주시기 바랍니다. 저는 그 내용에
대한 지적을 H&S4 에 대해서 했으며, 개인적인 사정으로 H&S5 가 출판된 이
후에 저자에게 보냈습니다 - H&S5 가 출판된 한참 후에야 제가 H&S5 를 구
입했습니다. 저자는 제가 지적한 내용을 H&S4 에 대해서 검토했으며, 제게
H&S5 에서도 남아 있는 문제를 지적해 달라고 회신해 왔습니다. 제가 다른
바쁜 일로 H&S5 를 읽지 못하고 있기에 H&S5 에 대한 적용이 늦어지는 것입
니다. 인용된 PDF 문서의 6쪽을 보시기 바랍니다.
그리고, 해당 예제에서 side effect 가 어떻게 생길 수 있는지 이해하지 못
하셨다면 C 표준이나 C 언어를 제대로 기술하는 책을 다시 한번 보시기 바
랍니다. 참고로, volatile 에 대한 read 자체가 side effect 라는 논의는
이곳 (KLDP BBS) 에서도 있었습니다.
volatile 에 대해서 모든 가정을 버리고 처음부터 다시 공부하시기를 적극
추천합니다. 제가 보여드린 예와 H&S 의 예는 완전히 동일한 예입니다. 정
확히 volatile 대상체에 대한 2번의 접근이 유사한 성격의 이항 연산으로
연결되어 있으며, 두 sequence point 사이에 둘러싸인 형태입니다. 따라서,
제 예에 대해서는 volatile 대상체에 2번의 접근이 필요하다고 말씀하시는
반면, H&S 의 예에 대해서는 최적화가 가능하다는 주장하시는 것은 님 스스
로 모순된 상황을 만들고 계신 것입니다. 그리고 irc 에서 f(r); f(r); 에
대해서 어떤 잘못된 논의가 오고 갔는지 모르겠으나, r 이 volatile 로 한
정되어 있다면, f(r); f(r); 은 r 에 최소한 2번의 실제적인 접근이 있어야
합니다. H&S 와 제가 보여드린 예와, f(r); f(r); 은 완전히 다른 성격의
예입니다.
제가 보여드린 예와 + 연산이 - 연산으로 바뀐 것일 뿐, 동일한 예입니다.
이 경우에도 a 에 대한 최소한 2번 이상의 접근이 필요합니다. a 에 대한
접근을 register caching 하는 것은 허락되지 않습니다.
님 (그리고 H&S 저자) 의 생각이지 진실이 아닙니다. 제가 보여드린 예도
모두 두개의 sequence point 사이에 쓰인 경우입니다. 제가 보기에는 님은
현재 sequence point 에 대해서도 오해하고 계신 부분이 있습니다.
구구절절한 어셈블리어 코드를 쓰기 싫어 의도적으로 반대되는 예를 보이며
해당 문단의 의도를 설명한 것입니다.
위에서 말씀드렸듯이 님의 volatile 에 대한 이해는 잘못되었습니다.
그렇다면 이제 왜 그 글쓴이가 간섭 가능한 연산을 non-volatile 로 제한했
는지 설명해 보실까요?
이는 이미 제가 반복하여 말씀드린 사실이고 참입니다.
일반적으로는 맞는 말씀입니다. 해당 글의 2번째 문단이 이 의도였는지는
별개의 문제입니다.
이 부분에서 님이 volatile 대상체에 대해서 일반적으로 하고 계시는 설명
에는 틀린 내용이 없습니다. 문제는 그 내용이 해당 글쓴이가 2번째 문단에
서 의도한 내용이냐, 아니냐 입니다. 이미 말씀드렸듯이, 해당 글쓴이가 말
하는 delay 는 "같은 프로그램의 실행 순서 재정렬" 에 의한 delay 입니다.
아니라고 생각하신다면, 왜 delay 에 영향을 줄 수 있는 연산을
non-volatile 로 제한했는지 설명해 보시기 바랍니다. 다른 processor 나
thread 에 의한 간섭까지 생각했다면 다른 프로그램의 volatile 연산 역시
영향주지 못할 이유가 없습니다. 반면, "같은" 프로그램의 "다른" volatile
연산은 (implementation 이 volatile 대상체 접근에 의한 side effect 를
모두 알기 이전에는) 해당 volatile 연산에 끼어들 수 없습니다.
이것이 제가 반복하여 말씀드리고 있는 것입니다! 같은 프로그램의
non-volatile 연산에 의한 간섭은 volatile 연산에 대해 delay 만 줄 뿐 결
국 결과에 아무런 영향을 주지 않습니다. 아무런 영향을 주지 않는 무의미
한 간섭이기 때문에 바로 그와 같은 프로그램 실행의 재정렬이 가능한 것입
니다.
반대로, *& hack 의 사용 목적이 성능 향상을 위한 최적화였다면 do_timer
의 역사에서 일관되게 성능 향상을 위한 최적화가 적용되었어야 한다는 것
입니다.
아전인수격의 해석입니다. 동등한 수준의 변화를 놓고, 하나는 님의 주장의
근거가 될 수 있는 반면, 다른 하나는 "개선 대상" 으로 치부되는 현장입니
다. 그와 같이 자의적이고 비논리적인 태도를 취하실 것이라면 논의에 참여
하는 의미 자체가 퇴색됩니다.
예, 맞습니다. volatile 은 "의도적으로" 불분명하게 정의되어 있습니다.
다만 과거 몇몇 논의에서 느낀 것은 그 불분명함이 너무 심해서 매우 간단
한 예에 대해서도 표준화 위원회 내에서 서로 다른 의견이 나온다는 것입니
다. 이 부분에 대해서는 제가 표준에 대한 defect report 를 작성 중에 있
습니다.
잊지 않았기에 해당 이야기를 할 때
와 같은 표현을 사용한 것입니다.
어제 포스팅한 글에서 말씀드렸듯이 개인적인 시간이 많지 않아서 님께서
추가로 제시해주신 근거들을 주의깊게 확인해 볼 시간이 충분치 않습니다.
"원 개발자의 의도는 무엇인가?" 에 대한 문제는 추가로 제공해주신 근거들
을 확인해본 후에 이어나갔으면 합니다. 다만, 이번에 인용해주신 근거에
대해서 다음과 같은 질문을 드립니다.
(1) *& hack 을 오로지 volatile 한정을 제거하기 위한 목적으로만 사용한
것인지요?
(2) 해당 근거가 platform independent 한 부분에 속해있는 것인지요?
(3) platform independent 한 부분이 아니라면 해당 트릭이 RISC 인 SPARC
에서만 사용되는 것인지요, 아니면 CISC 에서도 사용되는 것인지요?
각 질문에 대한 답이
- (1) Yes, (2) Yes, (3) X (X 는 질문이 적용되지 않음을 의미)
혹은
- (1) Yes, (2) No, (3) CISC 에서도 사용됨
이어야만 이번 문제에 대한 근거로서의 자격을 갖습니다.
그럼...
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
쓰레드가 길어지면서 이 스레드가 무슨 내용에 대해 이야기하고 있는 것인지
쓰레드가 길어지면서 이 스레드가 무슨 내용에 대해 이야기하고 있는 것인지, 쟁점이 되는 사안이 무엇인지 파악하기가 점점 힘들어지고 있습니다. 물론 이야기하고 계신 두분(전웅님, kyung님)은 잘 알겠지만 처음 읽는 사람들의 입장에서는 스레드 전체를 읽어 보아야 논의가 시작된 부분을 알 수 있기 때문에 시간이 많이 걸리게 됩니다.
그러므로 별다른 반대 의견이 없으면 이 스레드는 두분이 한번씩 더 글을 올릴 수 있는 기회를 드린 후 잠그도록 하고, 두분중 한분이 쟁점이 되는 사안을 따로 정리해서 새로운 스레드에 올려 주신 후 그 안에서 논의해 주시는게 좋을것 같습니다.
[quote][quote="kyong"][quote="전웅"]manu
제가 모든 상황에서 inc가 atomicity를 보장해 준다고 한 적은 없습니다.
7.1.1을 보세요. memory operand의 의미를 아시기 바랍니다.
lock prefix는 필요 없습니다.
제가 한 말은 분명히 interrupt 상황에서 incl 이라고 했습니다.
incl 메모리 는 분명히 보장해 준다는 것을 아셔야 합니다.
제가 말한 do_timer는 timer irq handler design에 의해 single threaded
라는 상황을 말하는 것입니다. 그래서 do_timer 문맥에서라고 하면 애초에
2번째 단락 자체를 언급할 필요가 없다는 것입니다.
값의 차이를 낳지 않는다면 왜 2번째 단락이 왜 들어간 것입니까?
그러나 gcc관점에서 do_timer가 single threaded라는 것을 뜻하지 않는
것이라면 바로 제가 원하던 문맥입니다. 그래서 interrupt에 걸린 상황에서
smp까지 고려해서 single instruction이 atomic한데 do_timer의 원래
문맥(single threaded)에서는 굳이 필요없다 이 말입니다.
이미 위에서 밝힌 것입니다.
외부 요인은 volatile object로서 일반론을 얘기한 것입니다.
제가 잘 못 생각한 것 중 하나는 읽는 관점에서 atomicity 해석을 시도한 점입
니다. 여기서는 쓰는 관점에서 생각해야 하므로 다른 프로세서로 volatile
value에 접근하는 문제라고 보는 것이 가장 정확할 것 같습니다.
volatitle과 atomicity가 표준과 관련있다고 한 적이 없습니다. 그리고 제가
든 예제는 volatile이 사용될 수 있는 예로서 언급되고 있는 것입니다.
그리고 위에서 하신 말이 제가 한 말이라고 생각하세요?
volatile은 dynamic한 system programming에서 아주 유용한 개념입니다.
값을 쓴 후에 cache에 넣지 않고 잊어 버리는 것입니다. free reader로서 유용
한 개념이란 것을 이미 말씀드렸습니다. jiffy처럼 writer로서 atomic한
operation을 얘기한 것입니다. free writer가 아닙니다. synchronization,
mutex라는 개념이 왜 나왔다고 생각하세요? 아무 process에서 뒤죽박죽
쓴 값을 아무나 읽으려고 volatile로 선언할 수도 있겠지요.
당연히 안 하셔도 됩니다. 제가 한 말이 아니니까요.
2번째 문단에서 의미는 좀 구체적인 의미로 정정했습니다. 그런데 님의 의견
은 reordering에 의해서 delay를 만들지만 차이가 없다로 끝나서 결국 아무
의미도 없는 말이 되었다는 것을 아시기 바랍니다.
volatile이 sequence point라는데 당연히 동의합니다.
volatile 자체가 side effect가 현실적으로 아닌 경우가 있을 것이라고 생각
됩니다. hardware I/O와 같은 경우를 어떻게 생각하시는지요.
제가 아니라고 한 얘기는 인용하지 마시기 바랍니다.
H&S5 에서 예제에 대해서는 동의합니다. 그러나 원래 의도했던 의미는
two sequenc point 사이에 one reference가 쓰인 경우에 가능하다는
것입니다.
implementaion defined 부분은
What constitutes an access to an object that has volatile-qualified type (6.7.3).
인데, volatile object에 one store operation은 hardware적으로 one store operation에 해당하고 read의 경우도 마찬가지이고 인접한
sequence point 사이에 n read 가 있다면 n개 까지 load는 자유롭게 할 수
있다는 생각입니다.(이것은 뉴스그룹에서 읽은 얘기입니다.)
expressions evaluation 관점에서 무의미하게 제거될 가능성에 대해서
생각해 본 것입니다. gcc가 어떻게 만들지 알아보는 것은 흥미 있을 것
같습니다. system programming 관점에서 중요한 문제라고 생각합니다.
volatile object는 reordering 대상이 아니라서 volatile object 끼리 ordering이 안지켜지는 경우는 없다는 답변을 원하세요? 그건 핵심과 상관없
는 얘기란 걸 아셔야 합니다. volatile object가 하나 뿐이고 쓰는 함수도 하나
뿐인 상황입니다.(single thread를 떠나서) 다른 processor를 고려하지 않고
서는 설명이 되지 않는다는 것을 아시기 바랍니다.
위에서 말한 부분입니다. smp에서는 같은 volatile object writer가 문제를
일으키는 것입니다.(timer IRQ design 문제를 고려하지 않은 상황이고요.)
non-volatile 때문에 더 심해진다고 할 수는 있겠지요. 위에서 한 얘기 같은데
현실적으로 unction에서 volatile object 앞뒤로 재 정렬이 일어나지 read,
increment, rite 사이에 일어날 가능성은 적다고 생각되기에 더 심해지는 경우
도 극히 물다고 할 수 있겠습니다. 아마 gcc가 그런 코드를 만들었다면
implementation define 된 부분이라고 자기들을 방어하겠고 개발자들은
gcc 무지 욕할 것 같네요.
과거에 있었다고 불완전하다고 하니 같은 의미에서 하는 말입니다.
수고하십니다.
지금 제 관심은 sequence point 사이의 one reference에 대한(hardware
I/O) 님의 생각을 아는 정도입니다. 주제가 이미 해결된 상황에서(최소한 제 생
각은) 곁가지로 나온 문제로 이 thread의 의미를 놓치게 할 수는 없으니까요.
[quote="kyong"]제가 모든 상황에서 inc가 atomicity
- A 는 X 라면 B 이고 Y 라면 C 이다
이것이 님이 이 논의에 참여하기 이전에 내려진 기술적 결론이라면, 님은
갑자기
- A 는 C 이다
라고 말씀하십니다. 그러면 전 그렇지 않다는 것을 설명하고, 곧 이어 님은
- A 가 모든 경우에 C 라고 한 적은 없다. X 면 B 이고 Y 면 C 이다
라고 말씀하십니다. 님이 지금까지의 기술적 내용에 취한 행동이 얼마나 무
가치하고 무책임한 일인지 생각해 보시기 바랍니다.
single thread 여도 같은 프로그램의 non-volatile 연산에 의해 volatile
에 대한 단위 instruction 의 일부가 delay 될 수 있습니다. 님께서 반복하
여 2번째 문단에 대해서 이의를 제기하셔서 이 논의가 진행되는 동안 원 글
쓴이에게 메일을 보내
문장의 의도를
로 이해할 수 있다는 답을 얻었습니다.
글쓴이가 자기가 알고 있는 바를 추가로 이야기하는 것이 문제가 된다는 뜻
입니까? 어쩌면 이 thread 에서처럼 do_timer 를 jiffies++; 로 바꿔 컴파
일했을 때 volatile 연산의 일부가 같은 프로그램에 의해 reordering 되는
것을 궁금해할 사람을 위해 그와 같은 설명을 넣었을 수도 있습니다. 즉,
단일 instruction 이 아닌 여러 instruction 으로 하나의 논리적 operation
이 구성되었을 때 발생하는 (최종적인 결과에는 영향을 주지 않는) 사소한
차이를 언급하기 위한 것일 수도 있습니다. 더이상 의미가 분명한 2번째 문
단에 대해서는 이의 제기는 불필요합니다.
님이 2번째 문단에서 설명하는 delay 를 제대로 이해하고 계시지 못하기 때
문에 계속 그와 같은 의심을 버리실 수 없다고 생각합니다. 2번째 문단의
제대로 된 의미는 이 thread 의 초반부에 있는 제 글에서 설명하고 있습니
다. 읽어보시고 이해가 되지 않는 부분을 질문해 주시기 바랍니다.
님이 했던 말씀 중에서 인용합니다.
그럼, 기타 어떤 표준이 volatile 에 atomicity 의 의미를 보장하지 않는데
(관련되어 있지 않은데) 대체 누가 atomicity 를 위한 별도의 design 을
"강요" 한다는 말입니까?
기술적으로 잘못된 내용을 적었을 때 사과하는 모습이 좋은 태도라고 말씀
하신 것으로 기억하고 있습니다.
님께서도 좋은 습관을 가지시길 바랍니다.
결국, 표준의 volatile 에 대한 최소한의 요구와 마찬가지로
implementation 은 volatile 에 대해서 atomicity 와 관련해서는 별도의 보
장을 해줄 필요가 없는 거로군요 - 이는 제가 지금까지 반복해서 말씀드린
바입니다! 그리고 동시에 님이 이전에 말씀하신 것과 상반되는 이야기입니
다! 알고 계신 내용을 표현하는 것에 서투신 것인지, 아니면 내용이 진행됨
에 따라 말을 바꾸고 계신 것인지 알기 어렵습니다.
그와 같은 delay 가 유효한 차이를 만들어야만 해당 delay 에 대해서 설명
할 수 있는 것은 아닙니다. 이 thread 에서도 볼 수 있듯이 그와 같은
delay 가 실제로 일어나고 있으며, 그것이 volatile 의 semantic 을 망치지
는 않는지 혹은 허락되는 것인지 혹은 (단일 instruction 과 비교해) 어떤
유효한 차이를 만드는 것은 아닌지 의심하는 사람이 있을 수 있습니다 - 또
한, 실제로 있었습니다. 이에 대해 미리 설명하는 것이 죄일 수는 없습니다.
volatile 이 sequence point 라는 뜻이 아니었습니다. 제발 부탁드리지만
volatile 과 sequence point 에 대해서 C 표준 혹은 C 표준을 잘 설명하는
책을 다시 보신 후에 의심이 되는 부분을 질문해 주시기 바랍니다.
volatile 과 sequence point 에 대한 이해가 결여된 상태에서 어떻게 까다
로운 내용에 대한 기술적 토론이 오해 없이 가능하겠습니까. 이런 상황에서
는 같은 개념을 설명해도 서로 다른 방법을 사용하게 되므로 끝없는 오해만
되풀이될 뿐입니다.
volatile 이 side effect 라는 것은 표준의 "정의" 입니다. 이는 일부 IO
에서 volatile 대상체에 대한 단순한 read 가 실제적이고 가시적인 side
effect 를 낳지 않는다해도 변하는 사실이 아닙니다. 님과 같은 논리라면
"왜 물 한방울에 한방울을 더하면 두방울이 아닌 한방울인데 1+1=2 라고 하
느냐?" 라고 묻는 것과 동일합니다.
H&S 의 예제나 제가 보여드린 예제와 무관한 부분입니다.
n개까지의 load 가 자유로운 정도가 아니라 반드시 있어야 한다는 것이 표
준의 요구입니다.
해당 volatile 대상체에 이루어지는 접근이 만드는 side effect 를
implementation 이 모두 예측할 수 없는 이상, 수식 평가 차원에서 제거되
어서는 안 된다는 것이 표준의 "요구" 입니다. volatile 에 대해서 다시 한
번 자세히 알아보시기를 진심으로 부탁드립니다.
gcc 는 volatile 대상체 접근에 대해 어떠한 "예측" 도 하지 않습니다. 따
라서 gcc 가 해당 수식을 최적화하는 일은 없습니다 - 이는 다수의 다른
implementation 에서도 적용되는 이야기입니다.
"같은" 프로그램의 "다른" non-volatile operation 이 이미 끼어들 수 있는
(또한 끼어들고 있는) 상황에서 "다른" processor 나 "다른" thread 만을
고려할 필요는 이미 없습니다. 또한, "다른" processor/thread 의 간섭이
가능하다면 "다른" processor/thread 의 volatile operation 이 배제될 이
유가 없는 상황입니다 - 이는 do_timer 와 같은 특수한 상황이 아닐때,
atomicity 를 위한 별도의 장치를 사용하는 중요한 이유입니다. 따라서, 해
당 글쓴이는 single thread 문맥에서 "같은" 프로그램의 "다른" non-
volatile operation 이 끼어드는 것에 대해서 이야기하고 있는 것입니다 -
이는 분명한 사실로 밝혀졌으므로 더 이상 이의의 가능성이 없습니다. 이해
되지 않는 부분 있으면 질문해 주시기 바랍니다.
제 생각을 알려고 하시기 전에 volatile 과 sequence point 에 대해서 다시
한번 알아보셨으면 합니다. 이 상태에서는 제가 제 생각을 잘 설명드린다고
해도 의사소통에 오해만 발생할 수 있습니다 - 더구나 저는 글을 친절히 잘
쓰지도 못합니다. 표준이 기술하고 있는 volatile 은 실제로는 몇부분 되지
않지만 상당히 어려운 기술적인 문제가 관련되어 있습니다.
주제는 해결된 것이 아니라 잠시 보류되어 있는 상태입니다. 추가로 제공해
주신 근거 (이 근거들에 대해서는 진심으로 감사하게 생각합니다) 는 여유
가 생기는대로 확인해 보도록 하겠습니다. 제 이전 글에서도 보셨겠지만,
새로운 근거에 대해 고려할 문제가 많기에 어설프게 훑어보고 결론 내리고
싶지 않아서 따로 시간을 내어 천천히 살펴볼 생각입니다.
그리고, 제 글을 마지막으로 관리자님에 의해 이 thread 가 닫힐 수도 있습
니다. 제 글에 추가적인 답을 하시려면 별도의 새로운 thread 를 만들어 주
시기 바랍니다.
그럼...
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
페이지
댓글 달기