내가 그때 주워들은 트랜잭셔널 메모리는,

하드웨어적으로 locking 같은 메카니즘을 구현해서 병렬화를 간편하게 (접근 권한 관리를 용이하게) 해주는 메모리라는 것이다.

그때 내가 물었지 실제 구현은 뭘로 하냐고 타겟 모델이 FPGA 같은거냐고.

그러니깐 실기에 적용하기 이전에 HDL 로 구현하는 수준이라고 하더군.

난 FPGA 로 VHDL, AHDL 좀 갖고 놀아보고 Verilog 코드도 눈짓은 했기 때문에 여기서 부턴 내 경험이 우위에 놓일 수 있게 되는뎅,

여튼 썰전은 거기서 끝나버렸다. 누군 헛다리만 짚었다고 하더군. 케케. 그건 FPGA, HDL, 내가 한 프로젝트들을 몰라서 하는 소리.


나는 그때 생각했다. 메모리 모듈을 관장하는 컨트롤러가 있고 그게 버스 마스터의 역할을 하면서 권한 관리를 하는 메카니즘이지,

메모리 소자 자체를 가지고 노는 존재는 아닐꺼라고 말야. 현실적으로 그렇잖아?

그렇다는건 메모리 소자와 같은 클럭이상의 속도로 동작해야 한다는걸 의미한다.

커플링된 메모리의 가속까지 받아내려면 당연히 많은 핀을 할당해야하고 FPGA 같은게 답이지.


근데 DoWhile 이 뭘 물었더라? (잠시 치매)


"형 트랜잭셔널 메모리에 대해서 그리고 트랜잭셔널 메모리가 상용화 되면 별령프로그래밍의 패러다임이 어떻게 변할지에 관한 썰도 좀 풀어주세요."


긁어왔다. 케케


일단 메모리고 자시고 모두 자원(resource)이고 장치(device)다.

우리는 다양한 장치를 일관성 있게 접근, 제어하기 위해 OOP 를 도입할 수 있다.

가령,


class SOME_MEMORY

{

private:

protected:

    virtual RETVAL do_lock(i64u address, int size, void*& memory);

public:

    RETVAL lock(i64u address, int size, void*& memory){ return do_lock(address, size, memory); }

    SOME_MEMORY(){};

    virtual ~SOME_MEMORY(){};

};

일단 읽던 쓰던 락걸고 놀자고. 복잡한거 질색.


class NORMAL_MEMORY : public SOME_MEMORY

{

private:

RETVAL software_lock(blah blah);

protected:

virtual RETVAL do_lock(i64u address, int size, void*& memory)

{

        RETVAL retval = software_lock(blah blah);

        if (retval != RV_OK) return retval;

        // something to do

        return RV_OK;

}

// blah blah

};


class TRANSACTIONAL_MEMORY : public SOME_MEMORY

{

// blah blah

protected:

virtual RETVAL do_lock(i64u address, int size, void*& memory)

{

// something to do

}

// blah blah

};


보통 하드웨어를 클래싱할 때, A 타잎 하드웨어와 B 타잎 하드웨어를 구현해보고 

공통점을 추상 클래스화 하고 상속받는게 기본이잖아?

이런 노가다가 주는 잇점은, 공통코드를 한 곳에 몰아서 관리할 수 있다는거고, (중복 제거)

사용할때 추상클래스 하나만으로 접근해 통일성을 부여하는 거지.

또한 에뮬레이션 클래스를 구성해서 실제 장비와 테스트하는 수고를 없앨 수 있다는게 가장 큰 장점이다.

프린터를 USB, SERIAL, ETHERNET 타잎으로 클래싱했을 경우,

실제 프린팅 할 필요없이 에뮬레이터 타잎으로 이미지 출력을 한다든지 하면 얼마나 시간을 벌겠수.

출력 폼을 구성하는 동안 일일이 삐딱하게 찍히는지 출력해 볼 필요 없으니 말야.

이와 마찬가지지~


여기서는 트랜잭셔널 메모리를 NORMAL_MEMORY 라는 녀석에서 에뮬레이션 하고 있고, 동시에 트랜잭셔널 메모리를 갖지 않은

시스템에서도 동일한 코드가 돌아갈 수 있게 HEL(Hardware emulation layer) 를 구성해 주는 역할을 하고 있음.


즉 transactional memory 가 상용화 되는 시점에서도 일반 메모리와 공존할거란거지? 왜?

당연히 일반 메모리는 부가 하드웨어가 필요 없어서 가격이 싸니까.

대신에 트랜잭셔널 메모리가 사용되는 경우 IO_COMPLETION 을 체크해야 하는 부분에서의 비용이 줄테고,

저기다 이벤트 핸들러를 추가해 줘야겠쥐. 동시, 비동시, 즉 비동기, 동기를 지원하기 위해 말야.

고로, OpenCL, C++Amp 와 같은 병렬화 플랫폼들 처럼,

DirectX 같은 개발 플랫폼 처럼

Hardware Abstraction Layer 와 Hardware Emulation Layer 의 구성이 필수적이 될거란 거지.


위에 언급된 코드에서 소유권을 인증하기 위한 절차 즉 Thread 나 Process ID 가 빠졌다.

그리고 Read / Write / Read + Write 에 대한 접근 방법에 대한 권한이 빠졌다.

그리고, DB Transaction 에서 이야기하는 안정성의 보장을 위한 Recovery 메카니즘도 들고 나오겠지?

고로 Sandbox 화도 빠졌다. (Commit - Rollback 구조)

그리고 언제나 동시성에서 대두되는 실패문제, 즉 timeout 에 대한 고려가 빠졌다.

하드웨어 내부적으로는,

다른 프로세스에 의해 점유된채 문제에 빠진 프로세스가 선점한 메모리에 대해 자원을 해제해주는 메카니즘이 필요하겠다.


결국 이런 읽기 쓰기, 프로세스와 같은 접근 방식과 권한 관리를 위해

메모리는 파일, DB접근과 동일한 수준으로 wrapping 될 가능성이 크고,

파편화 된 언어별로 상이한 접근방법을 취하는걸 막기위해 공통 플랫폼과 인터페이스가 대두될 가능성이 크다.

마치 socket 이나 ODBC 처럼 말야.


내생각엔 enterprise 시스템을 지원하는 운영체제에서 발빠르게 움직일것 같은데,

Sun microsystems (Solaris)를 먹은 Oracle 이 가장 주요하고,

IBM 과 Linux 진영이 표준화를 만들며 그 뒤 MS 가 되도않은 허접한 아키텍쳐로 경쟁을 시작하겠지.

일반 소비자와 멀티미디어 시장에 주목하고 있는 Apple 은 관망할 것 같군.


뭐~ 여러 생각들이 들지만, 요정도로 정리할까나?