이 기간 동안 약간의 연구는이 기록에서 일부 성공 간주 프로그램 자원 테이블을 최적화합니다.
우선 몇 가지 배경을 설명하기 : 자원 테이블에 우리의 서버를 공유 메모리에. 이에 대한 가장 큰 이유는 프로세스가 다음 코어 빌드 다시하고 필요하지 않을 때 다시 꺼내 자원 테이블 (본관 자원 테이블 HeroID 문의 영웅에 따라을 구성하는 데 사용됩니다 같은 해시 테이블을 구축하는 등의 인덱스 쿼리의 데이터 구조를 구축하는 것입니다 종). 그런 다음, 자원 테이블과 공유 메모리 시스템에서 여러 프로세스를 수있는 메커니즘이 있는지, 생각 자연스럽게, 동일한 시스템에 여러 프로세스를 배포의 가능성을 고려?
보다 직관적 인 아이디어는 여러 프로세스가 공유 메모리 리소스 테이블의 같은 부분에 걸려 있다는 것입니다. 이렇게하면 정말 공유 메모리의 목적을 달성하지만 자원 테이블 다시로드의 상황을 고려할 필요가 있습니다. 재 장전 작업을 작성할 때이 메모리는 할 것, 그리고 우리는 쓰기 한 번 많은 동시성 문제를 읽을 수있을 것이라는 점을 알고있다. 본 실시 예는, 따라서 여전히 동시성 문제를 처리하는 메커니즘을 도입 할 필요가있다. 일반적인 예는 새로운 자원 테이블 메모리에 좋은 빌드 타임 스위치 후 더블 버퍼입니다. 나는 어떤 팀이 정말 구체적으로 자세히 설명하지하고있다 배웠다.
내가 생각하는 방법은 이것이다 : 코드 생성 기술을 사용하여, 코드를 C ++로 자원 테이블 완전한 가이드. 쿼리 구조에 사용되는 모든 데이터는 자동 코드 생성을 통해이며, 정적으로 더 나은 건설 컴파일합니다. 이 메모리는 프로세스 실행에 직접로드 할 수 있습니다, 프로세스는 서비스로 구성 자원 테이블에서 이전 실행할 필요가 없습니다. 따라서,이 메모리는 수동으로 공유 메모리에 넣을 필요가 없습니다. 다음 핵심 공정 및 테이블 메모리까지 끌어 후 언로드 할 수있는 자원이며, 다음은 페이지 오류가 사용을 통해 다시 메모리에로드 트리거 할 수 있습니다. 동일한 시스템에서 공유 메모리를 수행하기 위하여, 자원 테이블 동적 라이브러리로 패키징 될 수있다. 그래서 작업 공유 메모리의이 작품은 자연스럽게 그것을 할 운영 체제에 밀었다.
이 방법은 몇 가지 장점이 있습니다. 나는이 (: P 나는 또한 이전 블로그에서 언급) 일회성 문제 해결 접근 방식이다 인의 가장 중요한 생각합니다. 코드 테이블의 대부분의 자원이 될 자동으로 생성되어 실질적으로. 프로세스가 테이블에 일부 리소스를 사용할 때,이 동적 라이브러리를 직접로드 할 수 있습니다. 비록 코드의 동적 로딩 프레임 층에 기록 될 수 있고, 기본 자원 테이블을로드 할 때마다 공정이다. 당신이 자원 테이블을 사용하려는 경우 (예 : 장면 프로세스와 gamesvr 이외의 프로세스 이외에) 다른 프로세스에서 우리는 매우 골칫거리하기 전에 지정된 파일 정의에 있어야하는 데 사용하는 자원 테이블, 그리고 만약 자원 테이블의 이 상호 의존 관계가있다,뿐만 아니라 또한 올 구성된 자원 테이블에 의존 할 필요가있다. 이제, 우리는 모든 프로세스에 대해 자원 테이블을로드 할 수 있으며, 메모리 증가의 위험에 대해 걱정할 필요가 없습니다.
둘째, 추정 자원 테이블 값의 메모리 제한을 경험 할 필요가 없습니다. 장비보다 1000 이상의 학생을 계획 할 때 예를 들어, 길이 (1000)의 배열의 정의는 장비 구성을 유지하기 위해, 메모리를 필요로하는, 수동으로 자원 테이블은 공유 메모리를 넣어 전에하기 때문에 (이 경험을 변경할 수있는 코드를 수정하는 것이 필요하다 ) 미리 할당. 자원 테이블이 정적으로 내장되어 있기 때문에, 배열의 크기는 완전 자동 코드 생성 할 수 있습니다. 또한, 우리는 모두 자동으로 도구에 의해 생성 된 자신의 필기 인덱싱 코드를 필요가 없습니다. 예를 들어, 이제, 당신은 자동으로 코드를이 인덱스를 생성 할 수있는 안내서의 기본 키 테이블을 지정해야합니다 요구와 수준 ID 조회에 따라 구성 테이블 기술이있을 수 있습니다.
정전기 축적 데이터 구조의 또 다른 이점은 저장소에 더 최적의 메모리 구조를 사용하는 것이 이론적으로 가능하다. 일반적으로, 자원 테이블 메모리는 우리가 빠른 인덱스를 할 싼 메모리 데이터 구조를 비스무트 Haxi 테이블을 설계 할 수 있습니다이 시나리오, 수정 후 다시로드되지 않습니다. 예를 들면, 각각의 기본 키가 해시 함수가 충돌하지 않는 생성을위한 완벽한 해시를 최소값. 아니오 동적 확장 때문에 성긴 (CAN 소형 어레이)를 저장하는 해시 표를 사용 할 필요하기 때문이다. 기본적인 아이디어는 생성 된 코드에 푸시 경우에도 컴파일 런타임에 의해 계산, 또는 푸시하는 것입니다.
, 다시로드 프로세스는 매우 간단있다가 할 수있는 새로운 동적 라이브러리를로드하기 위해 기존의 동적 라이브러리를 제거합니다. 필요할되기 전에 새로운 콘텐츠에 대한 메모리 공간을 예약하지 않도록 자원 테이블하고, 공유 메모리를 보유하기 때문에, 필요 공유 메모리 호환성 문제의 구조를 고려 없습니다.
마지막 포인트는 달성하기 매우 간단합니다. 모든 등 정적 코드 생성 도구를 사용하여 파이썬으로 작성된 코드 및 C ++ 자원 테이블 관리 코드와 코드 포함 미만 1,000 선까지 추가 할 수 있습니다.
구현 과정에서도에 대한 기록과 함께 너무 여기에 몇 가지 흥미로운 질문을,,,가 발생했습니다.
(1) 우선, 리눅스 동적 라이브러리는 단지는 .text 공유 메모리 세그먼트이다. 그리고 우리는 주요 데이터를 공유하기 위해 여기에 있습니다, 그것을 어떻게 할까? 이해하기 위해 먼저이 데이터의 일부가 로딩되는 과정에서 (구조적 쓰기 데이터뿐만 아니라 재배치 테이블 등을 포함)을 수정할 수 있기 때문에 동적 라이브러리가 메모리 세그먼트 .DATA을 공유하지 않는 이유는, 그것이 모든이어야한다는 것이다 프로세스는 전용 메모리를 유지합니다. 그러나 우리는 데이터의 개정이 때문에 공유 할 수있는 메모리가 없습니다. 이 솔루션은 간단 사용 CONST 어레이는 자원 테이블을 수정하는데 사용될 수있다. 그래서이 메모리는 .rodata에 넣어지게된다하고. 그리고 링크 단계에서, 링커 섹션는 .text 모든 .rodata을 병합합니다.
readelf -l 명령 프로그램을 헤더를 통해 PS 체크 ELF 파일 데이터 섹션에 포함된다는 .text 세그먼트에 포함되는 부분을 참조 할 수있을 것이다
(2) 또한, 얼마나 뜨거운 동적 라이브러리 업데이트에 대한 질문이 있습니다. 나는 항상 파일에 대해 생각하기 전에 직접 라이브러리 디렉토리 (때문에 파일 참조 수에) 문제가없는 대체. 그러나 상사가 실제로 새 파일 내용에 새로운 디렉토리 엔트리 포인트를 생성 한 후, 디렉토리에 원래 디렉토리 항목을 삭제하려면 해당하지, 원래 문서의 내용을 변경 cp 명령을 사용하여 리눅스에 덮여 지적했다. 원칙이 CP는 원본 파일의 아이 노드를 수정합니다 적용되는 경우, (자세한 내용은 볼 수있는 새로운 아이 노드를 만들 수 없습니다 여기 ). 그러나 여기에서 나는 더 많은 버그 cp 명령 같은 느낌 : 원본 파일에 대한 참조가 있는지 여부를 당신이 쓰는 새로운 아이 노드를 만드는 것이 아니라 유사 원래 아이 노드를 (다시 작성해야하는 경우 복사 프로세스가 고려해야 할 때 복사). 그러나 문제는 심층 모양, 다른 문제가 더 느낄 수 있습니다?