★ 프로그래밍을 마냥 좋아하는 아이 - 심스의 프로그래밍 세상 ★

아주 예전에 제가 위의 문제로 고민을 한적이 있었습니다. 하하.

우리가 생각한대로 int *ptr = &array가 되어야 합리적으로 보여질 수 있습니다.

하지만 다음과 같은 에러를 출력하는 것을 보실 수 있습니다.

'initializing' : cannot convert from 'int (*)[10]' to 'int *'

참 이상하죠? 배열명 array 자체는 주소값을 의미하고 거기에 단지 &연산을 했을 뿐인데 말입니다.

독자는 분명히 array == &array 라는 사실을 의심치 않을 겁니다.

왜냐하면, printf( "%x", array  ); 와

            printf( "%x", &array ); 이 같고,

            printf( "%d", sizeof(array)  ); 와

            printf( "%d", sizeof(&array) ); 가 같은데 말이죠.

 즉, 대상체가 의미하는 주소값과 대상체의 크기는 모두 동일하다는 것입니다.

그럼 다시 위의 에러를 살펴 봅시다.

[배열 포인터]형을 [포인터]형으로 변환이 불가능하다는 의미가 될 겁니다.

그래서 다시, int (*ptr)[10] = &array; 해서 컴파일 해 보았습니다.

에러없이 컴파일이 잘 되는군요. 하지만 상식적으로 저 역시 이해가 되질 않습니다.

여전히 의문을 가질 수 밖에 없었습니다. 그렇다면 좀 더 시각을 달리해보는건 어떨까

합니다. 배열명 array는 우리가 알고 있는대로 [포인터 상수]입니다.

배열명 자체가 주소값을 의미합니다. 그렇다면 상수에 &연산이 가능하다는 것조차도

논리적으로 좀 이상하지  않겠습니까?

&연산은 변수의 선두 번지를 구하는 연산이라는 것을 독자들도 잘 아실 겁니다.

그렇지만 &연산은 가능합니다. 왜냐하면, printf( "%d", &array );가 무리없이 컴파일되니까

말입니다. 저는 사실 이것도 뭔가 찝찝하다고 생각하였는데 독자가 동의하실지 모르겠습니다.

상수에 &연산을 허용한다는 것은 결국 &(&array)도 허용해야 하지 않겠습니까?

하지만 이것은 컴파일 에러를 출력합니다. '&' requires l-value로 말이죠.

(VC++로 컴파일하였을 때 기준)

하지만 다른 여러 컴파일러에서는 int *ptr = &array;가 허용되는 것으로 알고 있습니다.
(리눅스의 gcc가 허용하는 것으로 알고 있습니다)

우리들이 의도하신대로 말이죠. 제가 말하고 싶은 결론은 컴파일러의 Dependent한 문제라고

볼 수 밖에 없습니다. 항상 우리가 생각하는 논리와 의도대로 모든 문법이 구성이 되어있지 않

습니다. 저 역시 이 부분은 개인적으로 굉장히 아쉬운 부분으로 생각하고 있습니다.

결국은 컴파일러 문제죠. 여기까지는 컴파일러가 정한 문법 규칙이라고 밖에 볼 수 없습니다.

제가 그렇게 확신하는 이유가 다음의 Disassembling 코드때문입니다.

9:        printf( "%d\n", array  );

0040D76B   lea           eax,[ebp-28h]
0040D76E   push        eax
0040D76F   push        offset string "%d" (0042201c)
0040D774   call          printf (0040d6c0)
0040D779   add          esp,8 

10:       printf( "%d\n", &array );

0040D77C   lea          ecx,[ebp-28h]
0040D77F   push        ecx
0040D780   push        offset string "%d" (0042201c)
0040D785   call          printf (0040d6c0)
0040D78A   add         esp,8

 
같은 Addressing Mode로 연산을 한다는 사실을 위의 코드로 증명하였습니다.

( [확장자 .c]로 하여 int *ptr = &array; 컴파일하면 에러는 나지 않고 경고만 출력하더군요. )

컴파일러에 의해서 어쩔수 없는 부분은 그려려니 인정하고 이해보다는 암기하여

사용할 수 밖에 없다는 것이라고 생각합니다.

Written By Sim-Hyeon, Choe

Windows 운영체제에서 일반적으로 쓰레드가 프로그램의 기본 실행 단위입니다.

쓰레드가 프로그램의 기본 실행 단위라는 말은 모든 프로세스는 쓰레드를 가지고 있음을 의미합니다. 

프로그램의 실행 과정을 간략히 살펴보면 실행된 프로그램은 로더의 의해서 메모리에 적재되고, 커널이

실행된 프로그램을 상주시키기 위한 하나의 프로세스를 생성시켜 주게 됩니다. 프로세스가 생성후, 메인
 
쓰레드를 하나 생성하고 그 메인 쓰레드가 main() 함수(Entry Point)를 실행하게 되는 것입니다.

(여기서 프로세스와 쓰레드는 커널에 의해 생성되고 커널 오브젝트에 의해 관리되어 집니다)

다시 한번 더 정리하자면,

기본적으로 모든 프로세스는 최소한의 메인 쓰레드를 가지고 있다는 뜻입니다. 

쓰레드는 생성시, 독립적인 메모리 공간(Stack 영역)을 가지며 프로세스 내의 나머지 외부 영역

(Global)은 (다른 쓰레드와) 공유하게 됩니다. 외부 영역을 공유하게 됨으로써, 쓰레드간의 편리하게

통신할 수 있다는 점이 장점이 될 수도 있습니다. 하지만, 공유된 메모리 영역을 두 개 이상의 쓰레드가

접근할 경우에 문제가 될 수 있다는 것이 바로 문제의 핵심입니다.

이렇게 두 개 이상의 쓰레드에 의해서 같은 공유 메모리 영역에 접근하면서 생길 수 있는 문제 구역 즉,

다시 한번더 정리하자면 두 개 이상의 쓰레드에 의해서 접근되면 안되는 메모리 영역을 두고 임계 영역

(Critical Section)이라고 합니다. 프로세스 내의 쓰레드들은 동시에 실행되는 것이 아니라 일정한

CPU Time을 조금씩 조금씩 나눠서 할당받기 때문에 실제 활성화(Activation)되는 쓰레드는 하나뿐입

니다. 하지만, 해당 영역이 문제가 되는 것은 확실합니다.

문제가 되는 이유를 아주 간단한 예를 들어, 설명해 드리겠습니다.

우선 A, B 두 개의 쓰레드가 있으며 두 개의 쓰레드가 전역으로 선언된 변수를

같이 사용하고 있다고 가정하겠습니다.

int shared_var = 0;     // UnInitialized Data Segment - BSS 영역

DWORD WINAPI Thread_A(void *arg)
{
    shared_val = shared_val + 5;
} 

DWORD WINAPI Thread_B(void *arg)
{
    printf( "%d \n", shared_val );
}

위의 예제를 보시면 아시겠지만, A 쓰레드는 전역 변수 shared_val을 5씩 증가시켜 주는 역할을 하며,

B 쓰레드는 전역 변수 shared_val을 연속적으로 출력해주는 역할을 하는 쓰레드입니다.

(이 프로그램의 의도는 연속적으로 계속 5씩 증가하는 결과를 보여주는 프로그램입니다)

여기서 반드시 정확하게 이해하고 있어야 하는 것은 연산되어지는 과정입니다.

shared_val = shared_val + 5;를 연산하기 위해서 우선 r-value의 첫번째 shared_val 을 임시 메모리
 
공간에 할당하게 됩니다. 그리고 5를 다른 임시 메모리 공간에 할당하게 됩니다. 할당된 두 임시 메모리

공간에서 각각의 값을 읽어와 연산을 하고 연산된 결과 값을 리턴하여 l-value의 shared_val에 저장하

게 됩니다.

제가 위에서도 말씀드렸지만, 쓰레드는 분명 Cpu Time을 할당받는다고 하였습니다. A 쓰레드가 어떤

작업을 수행하고 있는데 CPU Time을 초과하게 되면 B 쓰레드에게 CPU Time이 할당되게 됩니다.

그러니까 A 쓰레드가 수행중인 작업을 끝내든 못 끝내든 상관없이 말입니다.

문제는 이겁니다. 만약에 아까 코드에서 A 쓰레드가 shared + 5를 연산하기 위해 임시 메모리에 할당한

후, 각각 값을 메모리에 저장한 상태에서 cpu time이 끝난다면 어떻게 될까요? 연산까지는 하지 못한

상태에서 말이죠. (※ cpu time은 각 쓰레드에게 주어지는 시간은 분명 일정하지만 프로세스도 마찬가

지로 cpu time을 할당받는데 프로 세스가 받는 cpu time은 사용자나 외부 환경에 의해서 일정치가 않

습니다)

일단, 임시 메모리에 저장한 값은 다른 임시 메모리 영역으로 옮겨 놓고, B 쓰레드를 호출하게 되는데,

B 쓰레드가 하는 역할은 전역 변수 shared_val의 값을 출력하는 것입니다. 바로 이곳이 문제가 되는 부

분입니다. 전역 변수 shared_val의 값은 A 쓰레드가 연산하기 직전에 cpu time을 B 쓰레드에게 넘겨

주었는데, B 쓰레드는 A 쓰레드가 한 작업에 상관없이 무조건 출력을 하게 되는데, 결과값은 증가되지

않는 값을 출력하는 것이 문제점입니다.

사실, 지금과 같은 예제로 인한 Critical Section 접근 문제는 거의 희박합니다. 하지만, B 쓰레드가 단

순한 출력이 아니라, A 쓰레드보다 더욱 복잡한 연산을 수행하며, 두 개의 쓰레드가 아닌 여러개의 쓰레

드가 접근할 때는 문제가 심각해 질 수 있다는 것을 말씀드리고 싶었습니다. 실제 임계 영역을 해결해야

하는 문제는 프로그래밍 중에 꾀나 빈번히 발생합니다.

char *temp = NULL;

NULL 포인터는 메모리의 어느곳도 가리키지 않는 포인터를 의미합니다.

NULL 포인터를 Debugging해보면 0x00000000를 가리킨다는 사실을 확인하실 수 있는데,

그렇다고 하여도 널 포인터는 어느곳도 가리키지 않는 포인터를 의미합니다.

어느곳도 가리키지 않는곳에 문자 상수 'A'를 대입하려고 했으니 문제가 발생하겠지요.

윈도우즈 운영체제에서 유저가 NULL 포인터 영역의 접근을 제한하고 있는 것이 보다 정확한

의미가 되겠습니다.

보통 NULL 포인터의 용도는 리소스 할당 실패를 검출하거나, 일종의 포인터 초기화, 

메모리 할당 실패 정도로 말씀드릴 수 있겠습니다.

ex1) if( NULL == fopen(..., ...) )

ex2) struct DATA *link;

        link->next = NULL;

ex3) char *string = (char *)malloc( sizeof(20) * char );

       if( string == NULL )
       {
            printf( "Memory allocation error" );
       }


Written By Sim-Hyeon, Choe