KR101367450B1

KR101367450B1 - 멀티 스레드 어플리케이션을 위한 해시 테이블의 동시 리해싱의 수행

Info

Publication number: KR101367450B1
Application number: KR1020117026459A
Authority: KR
Inventors: 안톤 알렉산드로비치 말라코브
Original assignee: 인텔 코오퍼레이션
Priority date: 2009-04-08
Filing date: 2009-04-08
Publication date: 2014-02-25
Also published as: CN102460392B; RU2517238C2; CN102460392A; JP5401676B2; RU2011144807A; JP2012523610A; SG175109A1; KR20120014141A; WO2010117294A1; US20120036134A1; US9563477B2

Abstract

일 실시예에서, 본 발명은 복수의 스레드들에 의해 동시에 공유되는 해시 테이블을 위해 제2 수의 버킷들을 할당하기 위한 방법을 포함하며, 제2 수의 버킷들은 제1 수의 버킷들 중 대응하는 페어런트 버킷에 논리적으로 맵핑되며, 리해싱이 이후에 주문형, 버킷 당 원칙으로 수행될 수 있도록 리해싱을 수행하지 않고 상기 할당을 완료하기 위해 해시 테이블의 업데이트된 용량을 발표한다. 다른 실시예들이 설명되고 청구된다.

Description

멀티 스레드 어플리케이션을 위한 해시 테이블의 동시 리해싱의 수행{PERFORMING CONCURRENT REHASHING OF A HASH TABLE FOR MULTITHREADED APPLICATIONS}

해시 테이블은 데이터베이스, 검색 엔진, 통계 프로세싱, 및 동적 스크립트 언어와 같은 다양한 어플리케이션들의 기본적인 구성 블록이다. 해시 테이블은 키들을 값들과 연관시키는 컨테이너들의 패밀리이다. 해시 테이블은 테이블의 엔트리 즉, 버킷(bucket)에 저장된 항목을 위한 배치 위치를 그것의 해시 값 및 컨테이너의 현재의 용량을 사용하여 계산한다. 그러나, 일반적으로 컨테이너들은 용량을 동적으로 증가시킬 필요가 있으며, 이는 메모리의 추가적인 청크(chunk)의 재할당 또는 할당을 의미한다. 그러므로, 증가된 용량은 항목 배치의 무효화를 야기하고 항목들이 새로운 장소들로 이동되는 것을 요구하며, 이는 보통 리해싱(rehashing)으로 명명된다.

해시 테이블을 위한 알려진 동시의 알고리즘들에 대해, 스레드가 컨테이너를 리사이징하기로 결정하면, 그것이 리사이징 및 리해싱 프로세스 양쪽 모두를 완료할 때까지 그것은 테이블 상의 일부의(또는 전부까지도) 동시 동작들을 블록한다(즉, 일시적으로 멈춘다). 이는 동시성의 퇴화, 따라서 성능의 퇴화를 야기한다. 다른 문제는, 리사이징을 갖는 동작들의 실행 시간 및 복잡도는 리사이징이 없는 동일한 동작들과 현저히 다르다는 것이다.

도 1은 본 발명의 일 실시예에 따른 해시 테이블을 업데이트하기 위한 방법의 흐름도이다.
도 2a는 본 발명의 일 실시예에 따른 버킷의 블록도이다.
도 2b는 본 발명의 일 실시예에 따른 새로운 버킷들의 할당을 예시하는 블록도이다.
도 2c는 본 발명의 다른 실시예에 따른 새로운 버킷들의 할당을 예시하는 블록도이다.
도 3은 본 발명의 실시예에 따른 룩업/리해싱을 수행하기 위한 방법의 흐름도이다.
도 4는 본 발명의 일 실시예에 따른 시스템의 블록도이다.

하나 또는 그 이상의 멀티 코어 프로세서들을 갖는 시스템과 같은 멀티 프로세서 시스템의 하나 또는 그 이상의 코어들에서 실행될 수 있는 하나 또는 그 이상의 스레드에 의해 액세스되는 공유 메모리인 동시의 해시 테이블을 위한 동시의 리사이징 및 주문형의 버킷 당 리해싱(on-demand per-bucket rehashing)을 수행하는 실시예들이 사용될 수 있다. 그것은 버킷이 항목들의 세트를 저장할 수 있는 해시 테이블들을 위해 적용 가능하다. 간단함을 위해, 테이블의 초기 용량이 2의 거듭제곱이라 가정한다. 항목을 위한 해시 값을 용량으로 나눈 것의 나머지는 항목을 저장하는 버킷의 인덱스이다. 간략화를 통해, 일부 실시예에서 버킷 인덱스는 하기 수학식에 의해 계산될 수 있다.

여기서, hash는 해시 값을 생성하는 해시 함수에 키가 적용되는 해시 계산에 의해 얻어진 해시 값이며, "&"는 2진 표현들의 비트 단위 AND를 나타낸다. 일 실시예에서, 용량(capacity)은 해시 테이블의 버킷들의 수의 단위일 수 있으나, 본 발명의 범위는 이 점에 있어서 제한되지 않는다.

용량을 증가시키기 위해, 본 발명의 실시예에 따른 알고리즘이 이미 존재하는 만큼의 버킷들을 할당하고 이전의 버킷들을 유지함으로써 버킷들의 수가 두 배가 되게 할 수 있다. 각각의 새로운 버킷은, 최대 비트 홀딩 값 1을 제외하면 새로운 버킷의 인덱스와 동일한 값(즉, 비트 세트)을 포함하는 인덱스를 갖는 기존의 버킷(페어런트)에 논리적으로 맵핑된다. 예컨대, 버킷의 인덱스가 2진수 표기로 00101101이라면, 페어런트 버킷의 각각의 인덱스는 00001101이다. 즉, 페어런트 버킷 인덱스는 다음과 같이 얻을 수 있다.

여기서, <<는 2진 좌항 피연산자를 우항 피연산자에 의해 특정된 비트들의 수만큼 쉬프팅하는 것을 나타낸다.

많은 구현들에서, 특정한 새로운 버킷들은 페어런트로서 다른 새로운 버킷들을 가질 수 있다. 하기 설명한 것과 같이, 일부 구현들에서 그것을 야기하는 할당들은 하나의 메모리 요청으로 결합될 수 있다.

이제 도 1을 참조하여, 본 발명의 일 실시예에 따른 해시 테이블을 업데이트하기 위한 방법의 흐름도가 도시되었다. 도 1에 도시된 것과 같이, 방법(10)은 해시 테이블에서 증가된 공간이 필요하다는 것을 결정함(블록 20)으로써 시작할 수 있다. 본 발명의 범위는 이 점에 있어서 제한되지 않지만, 그러한 결정은, 예컨대, 해시 테이블에 저장된 데이터의 양이 미리 결정된 역치, 예컨대, 총 테이블 양의 특정 비율에 도달할 때 새로운 데이터 쌍을 위한 삽입 동작과 동시에 시스템 소프트웨어에 의해 테이블의 부하율(load factor)에 기초하여 이루어질 수 있다. 물론, 증가된 공간이 필요하다는 것을 결정하는 다른 방법들이 다른 실시예들에서 사용될 수 있다. 예컨대, 사용자는 예비 동작으로의 호출에서 버킷들의 수를 지정할 수 있다.

그러한 결정과 동시에, 제어는 다수의 새로운 버킷들이 할당될 수 있는 블록(30)으로 진행한다. 더 구체적으로, 해시 테이블의 버킷들의 현재의 수에 대응하는 다수의 버킷들이 할당될 수 있다. 이러한 방식으로, 테이블에 할당된 버킷들의 수는 두 배가 된다. 일 실시예에서, 요구되는 양의 메모리를 입수하고, 버킷들을 새로운 빈 버킷들로 초기화하기 위해 할당자가 호출된다. 그 후, 이 새로운 공간은 발표될 수 있다(블록(40)). 본 발명의 범위는 이 점에 있어서 제한되지 않지만, 발표는 용량 값을 포함하는 변수에 대한 업데이트를 통해 이루어질 수 있다. 일 실시예에서, 이 업데이트는 "용량" 변수로의 릴리스 동작(release operation) (또는 원자적 기입)에 의한 저장을 통해 이루어질 수 있다. 대안적으로, 그러한 업데이트는 용량 마이너스 1의 값에 대응하는 마스크에 대한 것일 수 있다. 그러므로, 새로운 버킷들을 할당하고 이 새로운 공간을 발표함으로써, 원래의 버킷들에 존재하는 데이터의 새로운 버킷들로의 완전한 리해싱을 수행할 필요 없이 할당이 완료된다. 즉, 할당은 리해싱으로부터 독립적으로 수행되며, 새로운 공간의 발표에 의해 종료된다. 새로 발표된 공간의 각각의 버킷은 처음에 리해싱되지 않은 것으로 표시된다.

이제 도 2a를 참조하여, 본 발명의 일 실시예에 따른 버킷의 블록도가 도시되었다. 도 2a에 도시된 것과 같이, 버킷(100)은 데이터, 즉, 본원에서 일반적으로 데이터 쌍들로 명명되는 키 및 항목 쌍들을 포함하는 데이터 부분(110)을 포함할 수 있다. 옵션으로서, 데이터 부분(110)은 쌍들의 제한된 세트(어레이)를 직접(내장된) 및 간접적으로 예컨대, 포인터를 통해 포함할 수 있다. 추가적으로, 제어 정보(120)가 존재한다. 예컨대 뮤텍스(mutex)와 같은 동기화 대상(a), 플래그, 카운터 등과 같은 다양한 정보를 포함할 수 있는 제어 필드(b), 및 주어진 버킷이 리해싱되었는지, 및 리해싱된 레벨들의 수(하기 설명된, 일 대 다 접근법(one-to-many approach)을 위해 사용될 수 있는)를 나타내는 다양한 정보를 포함할 수 있는 리해시 상태 필드(c)를 포함하는 다양한 정보가 제어 정보(120)에 포함될 수 있다.

이제 도 2b를 참조하여, 본 발명의 실시예에 따른 새로운 버킷들의 할당을 예시하는 블록도가 도시되었다. 도 2b에 도시된 것과 같이, 복수의 현존하는 버킷들 200_a - 200_n이 존재한다. 예로서, 각각의 그러한 버킷은 도 2a의 버킷(100)과 일치할 수 있다. 재할당 동작에서, 새로운 버킷들이 페어런트 버킷들에 논리적으로 매핑되어 빈 버킷들 210_a - 210_n의 새로운 세트를 생성한다. 보여진 것과 같이, 상기 할당은 이미 존재하는 버킷들과 동일한 수에 대한 것이다. 이러한 새로운 버킷들 각각은 페어런트 버킷들 중 하나에 논리적으로 맵핑되며, 예컨대 도 2a에 도시된 리해시 필드(c)와 같은, 그것의 제어 정보(120)에서 리해싱되지 않은 것으로 표시된다.

다른 경우들에서, 도 2c에 예시된 것과 같이 새로운 버킷들 중 적어도 일부가 다른 새로운 버킷들에 맵핑될 수 있다. 그러므로, 도 2c는 도 2b의 서브세트이며, 그것은 두개의 개별적인 가능성들을 설명한다. (1) 페어런트 버킷들이 또한 리해싱되지 않은 것일 수 있으며, (2) 할당들이 결합될 수 있다. 보여진 것과 같이, 새로운 빈 버킷들 210_a - 210_n이 기존의 버킷들 200_a - 200_n에 맵핑한다. 차례로, 추가적인 새로운 빈 버킷들 220_a - 220_n이 기존의 버킷들 200_a - 200_n에 또한 맵핑한다. 게다가, 다른 새로운 빈 버킷들 230_a - 230_n이 새로운 빈 버킷들 210_a - 210_n에 또한 맵핑한다. 버킷 210_a에서 시작하고 230_n에서 끝나는 새로운 빈 버킷들은 결합된 할당의 인접한 공간일 수 있으며, 버킷들의 수는 한번에 몇 배 배가될 수 있다(예컨대, 버킷들의 수는 4의 인수로 곱해질 수 있다)는 것을 유념한다.

새로운 용량 값의 할당 및 발표 후, 임의의 룩업(lookup) 동작이 새로운 용량 값을 사용하여 버킷 인덱스를 계산한다. 새로운 용량의 발표 후, 새로운 버킷을 조사하는 임의의 동작은 먼저 페어런트 버킷(들)을 조사해야 하며, 옵션으로서(그러나 결국에는) 그것의(그들의) 콘텐츠를 새로운 버킷(들)으로 리해싱해야 한다. 그러므로, 리해싱 작업은 연기될 수 있고 컨테이너 내의 후속 동작들에 걸쳐 분할될 수 있다. 새로운 용량 값을 사용하는 계산된 인덱스가 리해싱되지 않은 것으로 표시된 버킷을 지시할 수 있다. 그렇다면, 룩업 동작은 리해싱된 버킷 또는 요구되는 키가 발견될 때까지 페어런트 버킷, 그랜드페어런트 버킷 등을 먼저 조사하도록 진행될 수 있다. 희망한 정보가 발견되면, 룩업 결과들이 요청자에게 반환될 수 있다. 더욱이, (처리된 버킷들의) 버킷 당 리해시(per-bucket rehash)가 일어날 수 있다. 그러한 리해싱은 재할당에서 테이블 전체의 완전한 리해싱을 수행하기 위해 시간과 비용을 들이기보다는, 룩업 요청에 응답하여 개별적인 (주문형) 버킷 리해싱이 일어날 수 있기 때문에 게으른 리해시(lazy rehash)로 명명될 수 있다. 대안적으로, 그러한 리해싱은 외부(사용자) 요청에 의해 일어날 수 있다.

그러므로, 옵션으로서(그러나 결국에는), 데이터 쌍들을 새로운 버킷(들) 내로 이동시킴으로써(그것들이 거기에 속한다면) 도중에 있던 모든 항목들이 리해싱될 수 있다. 그것을 위해 다른 전략들이 가능하다. 예로서, (리해싱된 및 리해싱되지 않은) 버킷들을 식별하기 위해 두개의 상태들이 사용될 수 있다. 이 구현에서, 리해싱 동작을 위해 전용 소유자가 제공된다. 이를 위해, 동작 시간 동안 다른 스레드가 버킷에 액세스할 수 없고 대기해야 하도록, 스레드가 상호 배타적인 동기화를 사용하여 버킷을 잠근다.

다른 스레드들이 리해싱되는 새로운 버킷에 동시에 액세스하거나, 동일한 페어런트 버킷의 리해싱에 참여할 수 있도록 제3의 상태, 즉 "부분적으로 리해싱된" 상태가 추가될 수 있다. 3상태 구현의 주 목적은, 다른 경우라면 다른 스레드에 의해 버킷이 리해싱될 때까지 대기해야 하는 스레드들을 언블록하는 것이다.

2상태 로직에 대해, 두개의 버킷들(예컨대, 페어런트 및 다음 후계자) 사이의 순환적인 리해싱이 수행될 수 있거나, 페어런트가 모든 리해싱되지 않은 후계자들로 리해싱되는 일 대 다 접근법이 수행될 수 있다. 2상태 순환적인 리해싱 알고리즘에 대해, 예컨대 (도 2a의 제어 정보(120)에 존재하는) 하나의 상태 변수가 상태들 NEW(빈, 리해싱되지 않은), EMPTY(그러나 리해싱된), 및 FILLED(리해싱된)과 함께 존재할 수 있다. 예컨대, 데이터 쌍들에 대한 포인터는 모든 세개의 상태들을 나타내면서 여전히 데이터를 참조할 수 있다. 일 대 다 구현은 버킷에 대한 리해싱된 레벨들의 수(용량)를 나타내는 버킷 데이터 구조의 추가적인 멤버를 사용한다는 것을 유념한다.

이제 도 3을 참조하여, 본 발명의 실시예에 따른 룩업/리해싱을 수행하기 위한 방법의 흐름도가 도시되었다. 이 흐름도는 (둘 중 어느 것이든 구현될 수 있고, 양쪽 모두가 하기 더 설명되는) 일 대 일(순환적인) 및 일 대 다 접근법 양쪽 모두에 대응하는 하이 레벨 뷰를 도시하도록 의도되었다. 룩업 요청은 찾기 전용(find-only) 또는 삽입 동작을 위한 것일 수 있다. 논의의 용이함을 위해 찾기 동작이 설명될 것이다. 도 3에 도시된 것과 같이, 방법(300)은 룩업 요청을 위해 버킷 인덱스 및 주소를 계산(블록 305)함으로써 시작할 수 있다. 예컨대, 요청된 데이터 쌍과 연관된 키가 인덱스, 따라서 메모리의 주소를 얻기 위해 해시 테이블 용량과 함께 사용될 수 있는 해시 값을 생성하는 해시 함수에 제공될 수 있다. 다음, 상기 룩업 요청이 리해싱되지 않은 빈 버킷에 대한 것인지의 여부가 결정될 수 있다(다이아몬드 310). 그렇지 않다면, 인덱싱된 버킷에 액세스하고 데이터 쌍(들)을 요청자에게 제공함으로써 룩업이 수행될 수 있다(블록 315). 하기 더 설명될 것과 같이, 동기화, 버킷을 통한 탐색, 경쟁 조건 체크, 및 옵션으로서 룩업 동작 전체의 재시작(경쟁이 검출된다면)과 같은 추가적인 동작들이 이 단계 동안 수행될 수 있다.

만약, 대신에 룩업 요청이 리해싱되지 않은 버킷에 대한 것이라고 결정되면, 제어는 블록 320으로 진행한다. 블록 320에서 페어런트 버킷을 위한 인덱스 및 주소가 계산될 수 있다. 위에서 논의된 것과 같이, 일부 구현들에서 그러한 인덱스는 수학식 2에 따라 계산될 수 있다. 인덱스가 계산되면, 그것은 페어런트 버킷에 액세스하기 위해 사용될 수 있다. 이 액세스된 버킷은 그것이 리해시되었는지 또는 요청된 데이터 쌍을 포함하는지의 여부를 결정하기 위해 체크될 수 있다(다이아몬드 330). 이 결정은 버킷의 리해시 상태에 부분적으로 기초할 수 있다. 리해싱된 버킷이 발견되면, 버킷들이 동기화(블록 340)될 수 있고, 데이터 쌍이 요청자로 반환(블록 350)될 수 있다. 그렇지 않다면, 이 루프의 추가적인 반복을 위해 제어는 블록 320으로 돌아간다. 블록 340에서의 동기화는 임의의 탐색 또는 리해시 동작을 수행하기 전에 관심 버킷들을 잠그는 것을 포함할 수 있다. 블록 350에서, 리해시할지의 여부의 결정은, 주문형 리해싱, 부분 리해싱, 또는 전용 스레드에 의한 리해싱을 제공할 수 있는 주어진 알고리즘에 의존할 수 있다. 리해싱이 수행된다면, 하나 또는 그 이상의 버킷들의 리해시 상태는 리해싱이 수행될 때 업데이트될 수 있다. 일 대 다 접근법에 대해, 페어런트 및 모든 새로운 버킷들의 상태가 변경된다. 리해싱 후 이 시점에서, 일부 쌍들을 후계자들로 이동하기 위해 페어런트 버킷에서 일부 쌍들이 제거될 수 있다(그리고 일 대 다 접근법에 대하여 상태가 변경된다).

버킷들은 결코 할당 해제되거나 동시에 이동되지 않으므로, 버킷들 및 내장된 데이터에 액세스하기 위해 일부 논 블로킹 또는 잠금 없는(lock-free) 알고리즘들이 사용될 수 있다. 이 방식으로, 해시 테이블들을 사용한 어플리케이션들의 성능 및 확장성이 증가될 수 있다.

복수의 스레드들이 공유 자원으로서 해시 테이블에 액세스한다면, 리해싱 룩업 경쟁 조건이 일어날 수 있다는 것이 가능하다. 키가 발견되지 않는다면, 그것은 버킷을 리해싱하는 동안 동시에 이동되었다는 것이 또한 가능하다. 키가 존재하지 않는다는 것을 확인하기 위해, 현재의 용량이 버킷 인덱스를 계산하기 위해 사용된 초기의 용량과 비교될 수 있다. 그들이 같지 않다면, 다음으로 이러한 값들을 사용하여 계산된 버킷 인덱스들이 서로 다른지의 여부가 결정될 수 있다(비교들 양쪽 모두는 마지막 것으로 축소될 수 있다). 그렇다면, 및 가장 가까운 후계자 버킷이 리해시되었거나 리해싱되고 있다면, (키가 존재하지 않는다는 것을 확인하기 위해) 룩업은 재시작되어야 한다. 용량이 2보다 큰 수로 곱해졌다면, 유일한 후계자만이 존재할 수 없다는 것을 유념한다. 경쟁 조건의 하나의 예로서, 동시 환경에서 가능한 다음 시퀀스를 고려하라.

[표 1]

1. 스레드 1: 룩업 동작을 위해 현재의 용량을 입수하고 버킷 인덱스(X)를 계산함.

2. 스레드 2: 새로운 버킷들의 할당을 완료하고 새로운 용량을 발표함.

3. 스레드 3: 새로운 용량 값을 얻고, 새로운 공간(Y)으로의 버킷(X)의 리해싱을 시작함.

4. 스레드 1: 항목을 찾아서 버킷(X)을 탐색하는 것을 계속하지만 발견할 수 없음. 그러나, 동시의 성장(2) 및 리해싱(3) 때문에 항목이 (Y로) 이동될 수 있으므로, 이는 항목이 테이블 전체에 존재하지 않는다는 것을 의미하지는 않는다.

이제 표 2를 참조하여, 본 발명의 실시예에 따른 경쟁 조건의 존재를 결정하기 위한 의사 코드(pseudo-code)의 예, 즉, 리해시 충돌이 일어날 수 있는지의 여부를 체크하기 위한 알고리즘의 예가 도시되었다.

[표 2]

일 실시예에서, 3개의 함수들, 즉 룩업 함수, 동기화를 수행하며, 제3 함수, 즉 리해싱 함수를 호출하는 버킷 입수(get bucket) 함수를 갖는 2상태 순환적인 리해싱 알고리즘이 사용될 수 있다. 이제 표 3을 참조하여, 그러한 2상태 순환적인 리해싱 알고리즘을 위한 의사 코드가 도시되었다.

[표 3]

룩업(Lookup):

1. 주어진 키에 대한 해시 값 계산

2. 현재의 용량 값을 얻고 버킷 인덱스를 계산(해시 및 용량을 사용하여)

3. 호출: 판독을 위한 버킷 입수(Get bucket)

4. 키를 위한 버킷 탐색

a. 발견된다면: 버킷을 릴리스하고 수행될 데이터를 반환

5. 발견되지 않으면: 리해싱 경쟁 체크(예컨대, 표 2에 따라)

a. 경쟁이 일어나지 않았다면: (삽입 동작이 수행되거나, 또는) 버킷을 릴리스하고 반환

b. 경쟁이 검출된다면: 버킷을 릴리스하고 (2)로 이동

버킷 입수(Get bucket)(판독-기입 잠금을 위한 구현):

1. 버킷 주소를 계산/입수

2. 버킷의 상태를 입수

a. NEW 라면(리해싱되지 않음): 버킷으로의 배타적인 액세스 획득 시도(일부 스레드는 성공해야 함)

실패하면: (3)으로 이동

b. 획득한다면: 버킷 상태가 여전히 NEW 라면(두번 체크), 호출:버킷 리해싱(Rehash bucket) 및 반환

3. 버킷으로의 특정 액세스 획득

버킷 입수(Get bucket)(상호 배타적인 잠금만을 위한 구현):

1. 해시 및 용량 값들을 사용하여 버킷 주소 계산

2. 버킷으로의 (배타적인) 액세스 획득

3. 버킷의 상태 입수

a. NEW 라면(리해싱되지 않음): 호출: 버킷 리해싱

버킷 리해싱(Rehash bucket): "버킷 입수" 알고리즘 때문에 배타적인 잠금 하에서 수행됨)

1. 새로운 버킷을 리해싱된 것으로 표시

2. 페어런트 버킷의 인덱스 계산

3. 호출: 판독을 위한 페어런트 버킷 입수

4. 페어런트 버킷의 각각의 데이터 항목에 대해:

a. 해시 값 계산

b. 항목이 새로운 버킷으로 이동되어야 할지 체크, 만약 그렇다면:

i. 필요하다면, 페어런트 버킷을 배타적인 액세스로 업그레이드

(업그레이드를 위해 잠금이 중단되었다면, (4)로부터 재시작)

ii. 페어런트 버킷에서 새로운 버킷으로 항목 이동

버킷 리해싱과 버킷 입수 함수들 사이의 상호 참조는 이 알고리즘이 순환적이라는 것을 의미한다. 또한, 본 발명의 실시예에 따른 동시 리해싱 알고리즘은 특정한 잠금 알고리즘들을 요구하지 않는다는 것을 유념하라(대신 그것은 동기화 레벨을 지정할 뿐이므로). 예컨대, "판독을 위한 버킷 입수"는 배타적인 잠금, 공용(판독자) 잠금을 획득하는 것, 또는 (블로킹하지 않는 판독 동작들을 위해) 버전 카운터만을 사용하는 것의 임의의 실제 사용을 의미할 수 있다. 또다른 실시예에서, 일 대 다 접근법이 사용될 수 있다. 표 4는 일 대 다 알고리즘에 대한 의사 코드 표현이다.

[표 4]

룩업(Lookup):

1. 주어진 키에 대한 해시 값 계산

2. 현재의 용량 값을 얻고 버킷 인덱스(해시 및 용량을 사용하여) 및 주소를 계산

3. 버킷의 상태 입수, 그것이 리해싱되지 않았다면(새로운):

a. 가장 근접한 리해싱된 루트(페어런트/그랜드페어런트 등) 버킷 찾기

b. 루트 버킷으로의 배타적인 액세스 획득 시도(획득될 때까지 또는 새로운 버킷의 상태가 "리해싱된"으로 바뀔 때까지)

상태가 변경된다면: 필요하다면 잠금을 릴리스하고 (4)로 이동

c. 호출: 버킷 리해싱

4. 버킷으로의 특정 액세스 획득

5. 키를 위한 버킷 탐색

d. 발견된다면: 버킷을 릴리스하고 수행될 데이터를 반환

6. 발견되지 않으면: 리해싱 경쟁 체크(예컨대, 표 2에 따라)

e. 경쟁이 일어나지 않는다면: [삽입 동작이 수행되거나,] 버킷을 릴리스하고 반환

f. 경쟁이 검출된다면: 버킷을 릴리스하고 (2)로 이동

버킷 리해싱(Rehash bucket): (배타적인 잠금 하에서 수행됨)

1. 루트 버킷 및 그것의 모든 후계자 버킷들 각각에 대해:

a. 레벨 필드를 리해싱하기 위한 용량 값 저장(및 버킷들을 리해싱된 것으로 표시)

2. 루트 버킷의 각각의 데이터 항목에 대해:

b. 해시 값 계산

c. 항목이 새로운 버킷으로 이동되어야 할지 체크, 만약 그렇다면:

i. 페어런트 버킷에서 적당한 새로운 버킷으로 항목 이동

라이브러리의 결합적인 컨테이너를 위해 실시예가 코드 내에 구현될 수 있다. 그러므로, 다양한 실시예들에서, 업데이트를 위해 컨테이너 전체(또는 컨테이너의 일부분)를 잠그는 것 대신에, 할당이 이미 존재하는 것 만큼의 버킷들을 할당하고 이전의 버킷들을 유지함으로써 버킷들의 수를 두배로 만들 수 있다. 각각의 새로운 버킷은 리해싱되지 않은 것으로 표시되며, 동일한 인덱스를 갖는 기존의 버킷(페어런트)에 논리적으로 맵핑된다. 일부 실시예들에서, 할당들은 또한 하나의 발표에 조합될 수 있으며, 하나의 메모리 요청이 사용될 수 있다. 그러므로, 본 발명의 실시예에 따른 리사이징은 기존의 버킷들을 무효화하지도 잠그지도 않으므로 동시성을 훼손하지 않는다.

실시예들은 많은 다른 시스템 종류들 내에 구현될 수 있다. 이제 도 4를 참조하여, 본 발명의 실시예에 따른 시스템의 블록도가 도시되었다. 도 4에 도시된 것과 같이, 멀티 프로세서 시스템(500)은 점 대 점(point-to-point) 상호 연결 시스템이며, 점간 상호 연결(550)을 통해 결합된 제1 프로세서(570) 및 제2 프로세서(580)를 포함한다. 도 4에 도시된 것과 같이, 프로세서들(570 및 580) 각각은 제1 및 제2 프로세서 코어들(즉, 프로세서 코어들(574a 및 574b), 및 프로세서 코어들(584a 및 584b))을 포함하는 멀티 코어 프로세서들일 수 있지만, 상기 프로세서들 내에 더 많은 코어들이 존재할 수 있다. 프로세서 코어들은, 상기 설명한 본 발명의 실시예에 따른 시스템 메모리에 저장된 해시 테이블들에 액세스할 수 있는 다양한 스레드들을 실행할 수 있다.

여전히 도 4를 참조하여, 제1 프로세서(570)는 메모리 컨트롤러 허브(MCH)(572) 및 점간(P-P) 인터페이스들(576 및 578)을 더 포함한다. 유사하게, 제2 프로세서(580)는 MCH(582) 및 P-P 인터페이스들(586 및 588)을 포함한다. 도 4에 도시된 것과 같이, MCH들(572 및 582)는 프로세서들을 각각의 메모리들, 즉, 각각의 프로세서들에 로컬로 연결된 메인 메모리(예컨대, DRAM)의 부분일 수 있으며, 본 발명의 실시예에 따라 동시적으로 리해싱될 수 있는 하나 또는 그 이상의 해시 테이블들을 저장할 수 있는 메모리(532) 및 메모리(534)에 결합한다. 제1 프로세서(570) 및 제2 프로세서(580)는 각각 P-P 상호 연결들(552 및 554)를 통해 칩셋(590)에 결합될 수 있다. 도 4에 도시된 것과 같이, 칩셋(590)은 P-P 인터페이스들(594 및 598)을 포함한다.

더욱이, 칩셋(590)은 P-P 상호 연결(539)에 의해 칩셋(590)을 고성능 그래픽 엔진(538)과 결합하기 위한 인터페이스(592)를 포함한다. 차례로, 칩셋(590)은 인터페이스(596)을 통해 제1 버스(516)에 결합될 수 있다. 도 3에 도시된 것과 같이, 다양한 입력/출력(I/O) 장치들(514)이 제1 버스(516)를 제2 버스(520)에 결합하는 버스 브리지(518)와 함께 제1 버스(516)에 결합될 수 있다. 일 실시예에서, 예컨대 키보드/마우스(522), 통신 장치들(526), 및 코드(530)를 포함할 수 있는 디스크 드라이브 또는 다른 대용량 저장 장치와 같은 데이터 저장 유닛(528)을 포함하는 다양한 장치들이 제2 버스(520)에 결합될 수 있다. 더욱이, 오디오 I/O(524)가 제2 버스(520)에 결합될 수 있다.

실시예들은 코드 내에 구현될 수 있으며, 명령들을 수행하도록 시스템을 프로그램하기 위해 사용될 수 있는 명령들이 저장된 저장 매체에 저장될 수 있다. 저장 매체는 플로피 디스크, 광 디스크, CD-ROM(compact disk read-only memory), CD-RW(compact disk rewritable), 자기 광 디스크, ROM(read-only memory), DRAM(dynamic random access memory), SRAM(static random access memory)과 같은 RAM(random access memory), EPROM(erasable programmable read-only memory), 플래시 메모리, EEPROM(electrically erasable programmable read-only memory)와 같은 반도체 장치, 자기 또는 광 카드, 또는 전자 명령들을 저장하기에 적합한 임의의 다른 종류의 매체를 포함하는 임의의 종류의 디스크를 포함할 수 있으나, 이들에 제한되지 않는다.

본 발명은 제한된 수의 실시예들에 관하여 설명되었으나, 본 기술분야의 당업자들은 그들로부터의 다수의 변형들 및 변경들을 인식할 것이다. 첨부된 청구항들은 본 발명의 진의 및 범위 내에 있는 모든 그러한 변형들 및 변경들을 포함하도록 의도되었다.

Claims

복수의 스레드들에 의해 동시에 공유되는 해시 테이블에 대한 제2 수의 버킷(bucket)들을 할당하는 단계 - 상기 해시 테이블은 제1 수의 버킷들을 가지며, 상기 제2 수의 버킷들은 상기 제1 수의 버킷들과 적어도 같으며, 상기 제2 수의 버킷들 각각은 상기 제1 또는 제2 수의 버킷들 중 대응하는 페어런트(parent) 버킷에 논리적으로 맵핑됨 -; 및
상기 제1 및 제2 수의 버킷들을 포함하는 상기 해시 테이블의 업데이트된 용량(capacity)을 발표하는 단계 - 상기 할당하는 단계는 상기 업데이트된 용량을 발표하는 것에 의해, 및 상기 제1 수의 버킷들의 콘텐츠의 리해싱(rehashing)을 수행하지 않고 완료됨 -
를 포함하는 방법.
제1항에 있어서,
리해싱이 필요한지의 여부를 결정하기 위해 버킷을 잠그지 않고 체크를 수행하는 단계를 더 포함하는 방법.
제1항에 있어서,
상기 해시 테이블의 업데이트된 용량을 발표하는 단계 후에 상기 제1 버킷 내에 존재하는 데이터 쌍에 대한 룩업(lookup) 동작을 수행할 때, 상기 제1 수의 버킷들 중 제1 버킷의 콘텐츠를 상기 제2 수의 버킷들 중 제2 버킷으로 리해싱하는 단계를 더 포함하는 방법.
제1항에 있어서,
상기 업데이트된 용량을 사용하여 버킷 인덱스를 계산하고, 상기 버킷 인덱스를 사용하여 버킷에 액세스하고, 상기 버킷이 리해싱되지 않았음을 결정하고, 상기 업데이트된 용량을 사용하여 상기 버킷이 논리적으로 맵핑되는 리해싱된 루트 버킷이 발견될 때까지, 페어런트 버킷에 대한 페어런트 버킷 인덱스를 순환적으로(recursively) 계산하는 단계를 더 포함하는 방법.
제4항에 있어서,
룩업 요청의 데이터 쌍을 탐색할 때 또는 그 전에, 상기 리해싱된 루트 버킷의 콘텐츠의 적어도 일부를 상기 버킷으로 리해싱하는 단계를 더 포함하는 방법.
제5항에 있어서,
상기 루트 버킷의 상기 콘텐츠 중 단지 일부만이 리해싱된 경우, 부분 리해시 지시자를 설정하는 단계를 더 포함하는 방법.
제4항에 있어서,
룩업 요청의 데이터 쌍을 찾아서 상기 버킷들을 탐색하고 상기 데이터 쌍을 반환하며, 상기 버킷들의 콘텐츠를 리해싱하지 않는 단계를 더 포함하는 방법.
제1항에 있어서,
제1 스레드에 의한 룩업 동작에 응답하여,
상기 제1 수의 버킷들 중 제1 버킷에서 요청된 데이터 쌍을 찾지 않으며, 상기 해시 테이블 용량의 현재 값을 상기 룩업 동작을 위한 버킷 인덱스를 결정하는 데 사용된 해시 테이블 용량의 값과 비교하며, 상기 현재 값과 상기 값이 다르다면, 가장 근접한 후계자 버킷의 인덱스를 계산하고, 상기 가장 근접한 후계자 버킷에 액세스하고 상기 가장 근접한 후계자 버킷에 대한 리해시 상태를 결정하는 단계를 더 포함하는 방법.
제8항에 있어서,
상기 리해시 상태가 새로운(리해싱되지 않은) 상태를 나타내지 않는다면, 상기 룩업 동작을 재시작하는 단계를 더 포함하는 방법.
제1항에 있어서,
제2 수의 버킷들에 대해 복수의 할당들을 하나의 할당으로 결합하는 단계를 더 포함하는 방법.
제1항에 있어서,
복수의 할당들을 발표하고 상기 복수의 할당들에 대해 상기 업데이트된 용량을 한번 발표하는 단계를 더 포함하는 방법.
명령들을 포함하는 컴퓨터 판독 가능한 저장 매체로서,
상기 명령들은, 컴퓨터에 의해 실행될 때, 상기 컴퓨터가
복수의 스레드들에 의해 동시에 공유되는 해시 테이블에 대해 룩업 동작을 수행하는 단계 - 상기 해시 테이블에 대한 제1 용량 값을 사용하여 상기 해시 테이블의 제1 버킷에 대한 버킷 인덱스를 계산하고, 상기 버킷 인덱스를 사용하여 상기 제1 버킷에 액세스하고, 상기 제1 버킷이 상기 룩업 동작의 데이터 쌍을 포함하지 않는다는 것을 결정하는 단계를 포함함 -;
상기 해시 테이블 용량의 현재의 용량 값을 상기 제1 용량 값과 비교하고, 상기 현재의 용량 값과 상기 제1 용량 값이 서로 다르다면, 상기 현재의 용량 값을 사용하여 업데이트된 버킷 인덱스를 계산하는 단계; 및
상기 업데이트된 버킷 인덱스와 상기 버킷 인덱스가 다르다면, 다음 버킷 인덱스를 계산하고, 상기 업데이트된 버킷 인덱스에 대응하는 다음 버킷에 액세스하고, 상기 다음 버킷에 대한 리해시 상태를 결정하는 단계
를 포함하는 방법을 수행할 수 있게 하는 컴퓨터 판독 가능한 저장 매체.
제12항에 있어서,
상기 방법은 상기 리해시 상태가 새로운 상태를 나타내지 않는다면 상기 룩업 동작을 재시작하는 단계를 더 포함하는 컴퓨터 판독 가능한 저장 매체.
제12항에 있어서,
상기 방법은 상기 룩업 동작 동안 상기 버킷에 액세스하면서 상기 해시 테이블의 버킷을 리해싱하는 단계를 더 포함하는 컴퓨터 판독 가능한 저장 매체.
제12항에 있어서,
상기 룩업 동작은 제1 스레드에 의해 수행되며, 상기 해시 테이블은 상기 제1 스레드가 상기 계산을 위한 상기 제1 용량 값을 얻은 후 제2 스레드에 의해 확장되고 상기 제1 스레드가 상기 제1 버킷에 액세스하기 전에 제3 스레드가 상기 제1 버킷을 리해싱하기 시작하는 컴퓨터 판독 가능한 저장 매체.
각각 하나 또는 그 이상의 스레드들을 실행하기 위한 제1 코어 및 제2 코어를 포함하는 마이크로프로세서 - 제1 스레드는 복수의 스레드들에 의해 동시에 공유되는 해시 테이블에 대한 제2 수의 버킷들을 할당하는 것이며, 상기 해시 테이블은 이전에 제1 수의 버킷들을 가지며, 상기 제2 수의 버킷들은 상기 제1 수의 버킷들과 적어도 같으며, 상기 제2 수의 버킷들 각각은 상기 제1 수의 버킷들 중 대응하는 페어런트 버킷 또는 상기 제2 수의 버킷들 중 대응하는 페어런트 버킷에 논리적으로 맵핑되며, 상기 제1 및 제2 수의 버킷들을 포함하는 상기 해시 테이블의 업데이트된 용량을 발표하며, 상기 제1 스레드는 상기 업데이트된 용량을 발표함으로써, 및 상기 제1 수의 버킷들의 콘텐츠의 리해싱을 수행하지 않고 상기 할당을 완료하는 것이며, 제2 스레드는 리해싱이 필요한지의 여부를 결정하기 위해 잠금 변수를 체크하지 않고 상기 제1 수의 버킷들 중 제1 버킷에 대해 룩업 동작을 수행하는 것임 -; 및
상기 해시 테이블을 저장하기 위해 상기 마이크로프로세서에 결합된 공유 메모리 - 상기 해시 테이블은 상기 복수의 스레드들 중 적어도 일부에 의해 동시에 액세스됨 -
를 포함하는 시스템.
제16항에 있어서,
제3 스레드는 상기 제1 버킷 내에 존재하는 데이터 쌍에 대한 룩업 동작을 수행할 때 상기 제1 수의 버킷들 중 상기 제1 버킷의 콘텐츠를 상기 제2 수의 버킷들 중 제2 버킷으로 리해싱하기 위한 것인 시스템.
제16항에 있어서,
상기 제2 스레드는 상기 업데이트된 용량을 사용하여 상기 제2 수의 버킷들 중의 버킷에 대한 버킷 인덱스를 계산하고, 상기 버킷 인덱스를 사용하여 상기 버킷에 액세스하고, 상기 버킷이 리해시되지 않았다는 것을 결정하고, 리해싱된 루트 버킷이 발견될 때까지, 상기 버킷이 논리적으로 맵핑되는 페어런트 버킷에 대한 페어런트 버킷 인덱스를 순환적으로 계산하기 위한 것인 시스템.
제18항에 있어서,
상기 제2 스레드는 룩업 요청의 데이터 쌍을 탐색할 때 또는 그 전에 상기 리해싱된 루트 버킷의 콘텐츠의 적어도 일부를 상기 버킷으로 리해싱하기 위한 것인 시스템.
제19항에 있어서,
상기 제2 스레드는 상기 루트 버킷의 상기 콘텐츠의 단지 일부만이 리해싱된 경우, 상기 루트 버킷의 부분 리해시 지시자를 설정하기 위한 것인 시스템.