전역변수의 폐혜~

싱글 코어에서 동작하는 펌웨어를 멀티 코어로 옮기는 작업이 요즘 제가 하는 작업 중 하나입니다.

펌웨어의 수많은 함수들을 기능적으로 레이어를 나누고 각 코어당 레이어를 할당해서 서로 통신하게 만드는 작업이죠.

그런데 이놈의 코드가 분명 설계상 레이어가 나눠져 있는데도 레이어간 콜백 함수와 전역 변수로 강결합되어 있는 겁니다. 콜백함수는 어찌 어찌해서 콜백 호출 시기에 메시지를 날리는 방식으로 해결 할 수 있을 것 같은데 전역 변수는 뭐 해결이 안되는 군요.

각 코어에 올리는 이미지를 따로 빌드해서 올려야 하기 때문에 코드의 데이터 영역을 같은 위치에 로드시킨다 하여도 각 코어에 올라가는 이미지의 심볼과 주소가 같으리란 보장도 없고, 혹시나 심볼과 주소가 맞더라도 역시 동기화 작업이 필요하게 되어 전체 소스 코드에서 전역 변수를 건드리는 부분을 모조리 찾아 작업을 해야 하는 처지 입니다.

"애초에 전역 변수를 사용하지 않으면서 코드를 만들 순 없는 것이었을까?"

라는 생각을 해봅니다. 제가 지금까지 알골 계열 언어(C/C++/Java 등)를 사용해서 만들었던 프로그램들을 돌이켜 봐도 전역변수를 하나도 사용하지 않고 만든것은 아주 간단한 스크립트 수준의 프로그램이 아닌 이상 거의 없네요.

PC 기반에서 멀티 쓰레드 프로그램을 작성할 때도 전역 변수를 이용해서 동기화 기법을 사용해 쓰레드간 데이터 공유를 하는 방법을 많이 사용했기에, 저는 멀티 코어 프로그래밍에 있어서도 전역 변수가 그렇게 크게 문제가 될 것이라고 생각하진 않았습니다.

하지만 동기화에 따른 여러가지 부작용. 그로 인한 프로그램의 복잡도 상승등을 생각 해 볼때 멀티 코어/ 멀티 쓰레드 환경에서 공유 자원(이 글에서는 전역 변수가 되겠네요..)의 사용이라는 것에 대해 진지하게 생각 해 보게 만듭니다.

요즘 저는 얼랭(Erlang)을 공부하고 있습니다. 이 언어는 언어 자체에서 공유자원을 지원하지 않습니다. (물론 다른 테크닉으로 가능하긴 하지만 C 처럼 쉽게 쓸 수 있진 않습니다.) 그러면서도 언어 자체에서 멀티 쓰레딩 (프로세싱)을 아주 잘 지원합니다.

요즘 제가 하고 있는 일의 문제점과 맞물려서 많은 생각을 하게 해 주네요.

물론 함수형 언어(얼랭)과 명령형 언어(C)와의 차이도 있겠지만 앞으로 멀티 쓰레드 환경에서 프로그램을 작성할 일이 분명 또 생길 텐데. 그때는 아마 전역 변수나 공유 자원의 사용에 대한 정책을 많이 고민하고 프로그램을 작성할 것 같습니다.