KR20140138586A - 트랜잭셔널 메모리 시스템에서의 적응성 스레드 스케줄링을 위한 방법, 장치 및 시스템 - Google Patents

Abstract

본 명세서에서는 트랜잭셔널 메모리 환경에서의 적응적 스레드 스케줄링을 위한 장치 및 방법이 기술된다. 시간에 걸친 스레드에서의 충돌들의 수가 추적된다. 그리고, 충돌들이 임계값을 초과한다면, 경쟁하는 스레드들 사이의 충돌들을 피하기 위해 스레드가 지연(적응적으로 스케줄링)될 수 있다. 더욱이, 보다 복잡한 버젼은 기간에 걸쳐 제2 스레드에 의해 초래되는 제1 스레드 내에서의 트랜잭션 중단들의 수 뿐만 아니라, 기간에 걸쳐 제1 스레드에 의해 실행된 트랜잭션들의 전체 수를 추적할 수 있다. 추적으로부터, 제2 스레드에 대한 제1 스레드의 충돌률이 결정된다. 그리고, 제1 스레드가 스케줄링될 때, 만약 제2 스레드가 실행중이고, 충돌률이 충돌률 임계값을 초과한다면, 그것은 지연될 수 있다.

Description

트랜잭셔널 메모리 시스템에서의 적응성 스레드 스케줄링을 위한 방법, 장치 및 시스템{METHOD, APPARATUS, AND SYSTEM FOR ADAPTIVE THREAD SCHEDULING IN TRANSACTIONAL MEMORY SYSTEMS}

본 발명은 집적 회로 분야에 관한 것으로서, 구체적으로는 프로세서에서의 병렬 실행에 관한 것이다.

반도체 가공 및 로직 설계의 진보는 집적 회로 디바이스 상에 존재할 수 있는 로직의 양의 증가를 가능하게 하였다. 결과적으로, 컴퓨터 시스템 구성은 시스템 내의 단일 또는 다수의 집적 회로로부터 개별 집적 회로 상에 존재하는 다수의 코어 및 다수의 로직 프로세서로 진화하였다. 통상적으로 프로세서 또는 집적 회로는 단일 프로세서 다이를 포함하며, 프로세서 다이는 임의 수의 코어 또는 로직 프로세서를 포함할 수 있다.

집적 회로 상의 점점 더 많은 수의 코어 및 로직 프로세서는 더 많은 소프트웨어 스레드가 동시에 실행되는 것을 가능하게 한다. 그러나, 동시에 실행될 수 있는 소프트웨어 스레드들의 수의 증가는 소프트웨어 스레드들 사이에 공유되는 데이터의 동기화에 관한 문제들을 발생시켰다. 다중 코어 또는 다중 로직 프로세서 시스템에서의 공유 데이터 액세스에 대한 하나의 일반적인 솔루션은 공유 데이터에 대한 다수의 액세스 간의 상호 배제를 보증하기 위해 록(lock)을 사용하는 것을 포함한다. 그러나, 다수의 소프트웨어 스레드를 실행하기 위한 점점 증가하는 능력은 거짓 경합 및 실행 직렬화를 유발할 수 있다.

예를 들어, 공유 데이터를 유지하는 해시 테이블을 고려한다. 프로그래머는 록 시스템을 이용하여 전체 해시 테이블을 록킹하여, 하나의 스레드가 전체 해시 테이블에 액세스하게 할 수 있다. 그러나, 다른 스레드들의 처리량 및 성능은 악영향을 받을 수 있는데, 이는 그들이 록 해제시까지 해시 테이블 내의 어떠한 엔트리에도 액세스할 수 없기 때문이다. 대안으로서, 해시 테이블 내의 각각의 엔트리가 록킹될 수 있다. 어느 경우에나, 이러한 간단한 예를 큰 확장 가능 프로그램 내에 외삽(extrapolate)한 후, 록 경합, 직렬화, 세밀한 동기화 및 데드록 방지의 복잡성은 프로그래머에게 매우 성가신 짐이 된다.

다른 최신 데이터 동기화 기술은 트랜잭셔널 메모리(TM)의 사용을 포함한다. 종종, 트랜잭셔널 실행은 복수의 마이크로 연산, 연산 또는 명령어의 그룹을 원자적으로(atomically) 실행하는 것을 포함한다. 위의 예에서, 양 스레드는 해시 테이블 내에서 실행되며, 그들의 메모리 액세스들은 모니터링/추적된다. 양 스레드가 동일 엔트리를 액세스/변경하는 경우, 데이터 유효성을 보증하기 위해 충돌 해결이 수행될 수 있다. 일 타입의 트랜잭셔널 실행은 메모리 액세스의 추적, 충돌 해결, 작업 중단 및 기타 트랜잭셔널 작업들을 종종 하드웨어의 지원 없이 소프트웨어에서 수행하는 소프트웨어 트랜잭셔널 메모리(STM)를 포함한다. 다른 타입의 트랜잭셔널 실행은 액세스 추적, 충돌 해결 및 기타 트랜잭셔널 작업들을 지원하기 위한 하드웨어를 포함하는 하드웨어 트랜잭셔널 메모리(HTM) 시스템을 포함한다.

알 수 있듯이, TM은 다수의 스레드 간에 보다 양호한 성능을 제공하는 잠재력을 갖는다. 그러나, 스레드들 간의 데이터 충돌로 인해 너무 많은 스레드가 중단되는 경우에는 성능이 저하될 수 있다. 즉, 트랜잭션 중단(즉, 아키텍처 및 메모리 상태의 트랜잭션 전의 포인트로의 롤백)의 비용은 잠재적으로 시간 소모적이다. 그리고, 종종 일부 중단들은 가능한 최고 병렬 성능을 달성하는 것의 일부이지만, 너무 많은 중단은 록 없이 실행하는 것의 이익보다 트랜잭션 중단에 더 많은 시간을 소비하는 결과를 낳을 수 있다. 전통적으로, 트랜잭션이 너무 많이 중단되는 경우, 실행은 록 기반 실행으로 복귀한다. 그럼에도, 병렬 스레드들 간의 충돌을 최소화(또는 일부 예들에서는 방지)하기 위해 스레드들을 효율적으로 스케줄링하고자 하는 시도는 없었다.

본 발명은 예시적으로 도시되며, 첨부 도면들에 의해 한정되는 것을 의도하지 않는다.
도 1은 다수의 처리 요소(2개의 코어 및 4개의 스레드 슬롯)를 갖는 프로세서를 포함하는 시스템의 논리적 표현의 일 실시예를 도시한다.
도 2는 소프트웨어 트랜잭셔널 메모리 시스템 및 그의 실행을 지원하기 위한 하드웨어 구조들의 논리적 표현의 일 실시예를 도시한다.
도 3은 스레드 충돌들에 기초하여 스레드들을 적응적으로 스케줄링하기 위한 모듈들의 논리적 표현의 일 실시예를 도시한다.
도 4는 스레드 충돌들에 기초하여 스레드들을 적응적으로 스케줄링하기 위한 모듈들의 논리적 표현의 일 실시예를 도시한다.
도 5는 현재 실행중인 스레드들과의 충돌들에 기초하여 스레드의 스케줄링을 연기하는 방법을 위한 흐름도의 일 실시예를 도시한다.
도 6은 스레드 충돌들에 기초하여 스레드들을 적응적으로 스케줄링하는 방법을 위한 흐름도의 일 실시예를 도시한다.
도 7은 스레드 충돌들에 기초하여 스레드들을 적응적으로 스케줄링하는 방법을 위한 흐름도의 다른 실시예를 도시한다.

아래의 설명에서는, 본 발명의 충분한 이해를 제공하기 위해, 특정 타입의 특정 프로세서 구성, 특정 하드웨어 구조, 특정 아키텍처 및 마이크로 아키텍처 상세, 특정 레지스터 구성, 특정 충돌 공식, 특정 타입의 제어 소프트웨어 등과 같은 다양한 특정 상세들이 설명된다. 그러나, 이러한 특정 상세들은 본 발명의 실시에 이용될 필요는 없다는 것이 이 분야의 기술자에게 명백할 것이다. 다른 예들에서는, 본 발명을 불필요하게 불명확하게 하지 않기 위해, 공지 컴포넌트들 또는 방법들, 예를 들어 특정한 그리고 대안적인 프로세서 아키텍처, 설명되는 알고리즘들을 위한 특정 로직 회로/코드, 특정 전력 유닛 구현 상세, 디코더의 특정 동작, 명령어들의 특정 포맷 및 프로세서들의 다른 특정 동작 상세는 상세히 설명되지 않는다.

아래의 실시예들은 프로세서와 관련하여 설명되지만, 다른 실시예들은 다른 타입의 집적 회로들 및 로직 디바이스들에 적용될 수 있다. 본 명세서에서 설명되는 실시예들의 유사한 기술들 및 가르침들이 더 높은 파이프라인 처리량 및 향상된 성능으로부터 이익을 얻을 수 있는 다른 타입의 회로들 또는 반도체 디바이스들에 적용될 수 있다. 예를 들어, 개시되는 실시예들은 컴퓨터 시스템으로 한정되지 않는다. 그리고 다른 디바이스들, 예를 들어 핸드헬드 디바이스들 및 내장 애플리케이션들에서도 사용될 수 있다. 핸드헬드 디바이스들의 일부 예들은 셀룰러 폰, 인터넷 프로토콜 디바이스, 디지털 카메라, 개인 휴대 단말기(PDA) 및 핸드헬드 PC를 포함한다. 내장 애플리케이션들은 마이크로컨트롤러, 디지털 신호 프로세서(DSP), 시스템 온 칩, 네트워크 컴퓨터(NetPC), 셋톱 박스, 네트워크 허브, 광역 네트워크(WAN) 스위치, 또는 후술하는 기능들 및 동작들을 수행할 수 있는 임의의 다른 시스템을 포함한다.

본 명세서에서 설명되는 방법 및 장치는 스레드들을 적응적으로 스케줄링하여 충돌을 최소화한다. 구체적으로, 프로세서(100)와 같은 마이크로프로세서를 이용하는 트랜잭셔널 실행과 관련하여 적응성 스레드 스케줄링이 설명된다. 그러나, 본 명세서에서 설명되는 장치들 및 방법들은 그에 한정되지 않는데, 이는 그들이 대안적인 프로세서 아키텍처들은 물론, 다수의 처리 요소를 포함하는 임의의 디바이스와 관련하여 구현될 수 있기 때문이다. 예를 들어, 적응성 스레드 스케줄링은 다른 타입의 집적 회로들 및 로직 디바이스들에서 구현될 수 있다. 또는 이것은 작은 폼-팩터 디바이스들, 핸드헬드 디바이스들 또는 내장 애플리케이션들에서 이용될 수 있다. 게다가, 적응성 스레드 스케줄링은 트랜잭셔널 실행과 관련되지 않은 스레드들의 스케줄링을 위해서도 구현될 수 있다. 일례로서, 스레드들은 후술하는 것과 유사한 방식으로 캐시들 또는 다른 공유 자원들에서의 충돌을 최소화하도록 스케줄링된다.

도 1을 참조하면, 다수의 코어를 포함하는 프로세서의 일 실시예가 도시된다. 프로세서(100)는 임의의 프로세서 또는 처리 디바이스, 예를 들어 마이크로프로세서, 내장 프로세서, 디지털 신호 프로세서(DSP), 네트워크 프로세서, 핸드헬드 프로세서, 또는 코드를 실행하기 위한 다른 디바이스를 포함한다. 일 실시예에서, 프로세서(100)는 비대칭 코어들 또는 대칭 코어들(도시된 실시예)을 포함할 수 있는 적어도 2개의 코어 - (코어(101 및 102)) -를 포함한다. 그러나, 프로세서(100)는 대칭 또는 비대칭일 수 있는 임의의 수의 처리 요소를 포함할 수 있다.

일 실시예에서, 처리 요소는 소프트웨어 스레드를 지원하기 위한 하드웨어 또는 로직을 지칭한다. 하드웨어 처리 요소들의 예들은 스레드 유닛, 스레드 슬롯, 스레드, 프로세스 유닛, 컨텍스트(context), 컨텍스트 유닛, 로직 프로세서, 하드웨어 스레드, 코어, 및/또는 프로세서에 대한 상태, 예를 들어 실행 상태 또는 아키텍처 상태를 유지할 수 있는 임의의 다른 요소를 포함한다. 즉, 일 실시예에서, 처리 요소는 코드, 예를 들어 소프트웨어 스레드, 운영 체제, 애플리케이션 또는 다른 코드와 독립적으로 연관될 수 있는 임의의 하드웨어를 지칭한다. 통상적으로 물리 프로세서는 임의 수의 다른 처리 요소들, 예를 들어 코어들 또는 하드웨어 스레드들을 잠재적으로 포함하는 집적 회로를 지칭한다.

종종 코어는 독립적인 아키텍처 상태를 유지할 수 있는 집적 회로 상에 배치된 로직을 지칭하며, 여기서 각각의 독립적으로 유지되는 아키텍처 상태는 적어도 일부 전용 실행 자원들과 연관된다. 코어들과 달리, 하드웨어 스레드는 통상적으로 독립적인 아키텍처 상태를 유지할 수 있는 집적 회로 상에 배치된 임의의 로직을 지칭하며, 여기서 독립적으로 유지되는 아키텍처 상태들은 실행 자원들에 대한 액세스를 공유한다. 알 수 있듯이, 소정의 자원들이 공유되고, 다른 자원들이 하나의 아키텍처 상태에 전용화될 때, 하드웨어 스레드와 코어의 명칭 간의 선은 오버랩된다. 그러나 종종 코어와 하드웨어 스레드는 운영 체제에 의해 개별적인 로직 프로세서들로서 간주되며, 운영 체제는 각각의 로직 프로세서 상에 동작들을 개별적으로 스케줄링할 수 있다.

도 1에 도시된 바와 같이, 물리 프로세서(100)는 2개의 코어, 즉 코어(101 및 102)를 포함한다. 여기서, 코어(101 및 102)는 대칭 코어들, 즉 동일한 구성들, 기능 유닛들 및/또는 로직을 갖는 코어들로서 간주된다. 다른 실시예에서, 코어(101)는 비순차적 프로세서 코어를 포함하며, 코어(102)는 순차적 프로세서 코어를 포함한다. 그러나, 코어들(101, 102)은 고유 코어, 소프트웨어 관리 코어, 고유 명령어 세트 아키텍처(ISA)를 실행하도록 적응되는 코어, 변환된 명령어 세트 아키텍처(ISA)를 실행하도록 적응되는 코어, 공동 설계 코어, 또는 다른 공지 코어와 같은 임의의 타입의 코어로부터 개별적으로 선택될 수 있다. 그러나, 설명을 촉진하기 위해, 코어(101) 내에 도시된 기능 유닛들이 아래에 더 상세히 설명되며, 이는 코어(102) 내의 유닛들이 유사한 방식으로 동작하기 때문이다.

도시된 바와 같이, 코어(101)는 2개의 하드웨어 스레드(101a, 101b)를 포함하며, 이들은 하드웨어 스레드 슬롯들(101a, 101b)로도 지칭될 수 있다. 따라서, 일 실시예에서, 운영 체제와 같은 소프트웨어 엔티티들은 잠재적으로 프로세서(100)를 4개의 개별 프로세서, 즉 4개의 소프트웨어 스레드를 동시에 실행할 수 있는 4개의 로직 프로세서 또는 처리 요소로서 간주한다. 전술한 바와 같이, 제1 스레드는 아키텍처 상태 레지스터들(101a)과 연관되고, 제2 스레드는 아키텍처 상태 레지스터들(101b)과 연관되고, 제3 스레드는 아키텍처 상태 레지스터들(102a)과 연관될 수 있으며, 제4 스레드는 아키텍처 상태 레지스터들(102b)과 연관될 수 있다. 여기서, 아키텍처 상태 레지스터들(101a, 101b, 102a, 102b) 각각은 전술한 바와 같은 처리 요소들, 스레드 슬롯들 또는 스레드 유닛들로서 지칭될 수 있다. 도시된 바와 같이, 아키텍처 상태 레지스터들(101a)은 아키텍처 상태 레지스터들(101b) 내에 복제되며, 따라서 개별 아키텍처 상태들/컨텍스트들은 로직 프로세서(101a) 및 로직 프로세서(101b)를 위해 저장될 수 있다. 코어(101)에서, 명령어 포인터들 및 리네임 할당기 로직(130) 내의 리네임 로직과 같은 다른 더 작은 자원들도 스레드들(101a, 101b)을 위해 복제될 수 있다. 리오더/퇴거 유닛(135) 내의 리오더 버퍼들, ILTB(120), 로드/저장 버퍼들 및 큐들과 같은 일부 자원들은 분할을 통해 공유될 수 있다. 범용 내부 레지스터들, 페이지-테이블 베이스 레지스터, 하위 레벨 데이터 캐시 및 데이터 TLB(115), 실행 유닛(들)(140) 및 비순차적 유닛(135)의 부분들과 같은 다른 자원들은 잠재적으로 완전히 공유된다.

프로세서(100)는 종종 처리 요소들에 의해 완전히 공유되거나, 분할을 통해 공유되거나, 처리 요소들에 전용화될 수 있는 다른 자원들을 포함한다. 도 1에는, 순전히 예시적인 프로세서의 일 실시예가 프로세서의 예시적인 로직 유닛들/자원들과 함께 도시된다. 프로세서는 임의의 이러한 기능 유닛을 포함하거나 배제할 수 있는 것은 물론, 도시되지 않은 임의의 다른 공지된 기능 유닛, 로직 또는 펌웨어도 포함할 수 있다는 점에 유의한다. 도시된 바와 같이, 코어(101)는 간소화된 대표적인 비순차(out-of-order; OOO) 프로세서 코어를 포함한다. 그러나 다른 실시예들에서는 순차 프로세서가 사용될 수 있다. OOO 코어는 실행될/취해질 분기들을 예측하기 위한 분기 타겟 버퍼(120) 및 명령어들에 대한 어드레스 변환 엔트리들을 저장하기 위한 명령어 변환 버퍼(I-TLB)(120)를 포함한다.

코어(101)는 인출된 요소들을 디코딩하기 위해 인출 유닛(120)에 결합된 디코드 모듈(125)을 더 포함한다. 일 실시예에서, 인출 로직은 스레드 슬롯들(101a, 101b)과 각각 관련된 개별 시퀀서들을 포함한다. 통상적으로 코어(101)는 프로세서(100) 상에서 실행 가능한 명령어들을 정의/지정하는 제1 명령어 세트 아키텍처(ISA)와 연관된다. 종종, 제1 ISA의 일부인 기계 코드 명령어들은 실행될 명령어 또는 동작을 참조/지정하는 (옵코드(opcode)로서 지칭되는) 명령어의 일부를 포함한다. 디코드 로직(125)은 이러한 명령어들을 그들의 옵코드들로부터 인식하고, 디코딩된 명령어들을 제1 ISA에 의해 정의되는 바와 같은 처리를 위해 파이프라인 내로 전달하는 회로를 포함한다. 예를 들어, 아래에 더 상세히 설명되는 바와 같이, 일 실시예에서, 디코더들(125)은 트랜잭셔널 명령어와 같은 특정 명령어들을 인식하도록 설계 또는 적응되는 로직을 포함한다. 디코더들(125)에 의한 인식의 결과로서, 아키텍처 또는 코어(101)는 적절한 명령어와 관련된 작업들을 수행하기 위해 특정한 사전 정의된 액션들을 취한다. 본 명세서에서 설명되는 임의의 작업, 블록, 동작 및 방법은 단일 또는 다수의 명령어에 응답하여 수행될 수 있으며, 그러한 명령어들 중 일부는 새로운 또는 오래된 명령어일 수 있다는 점에 유의하는 것이 중요하다.

일례에서, 할당기 및 리네이머 블록(130)은 명령어 처리 결과들을 저장하기 위한 레지스터 파일들과 같은 자원들을 예약하기 위한 할당기를 포함한다. 그러나, 스레드들(101a, 101b)은 잠재적으로 비순차 실행이 가능하며, 할당기 및 리네이머 블록(130)은 명령어 결과들을 추적하기 위한 리오더 버퍼들과 같은 다른 자원들도 예약한다. 유닛(130)은 프로그램/명령어 참조 레지스터들을 프로세서(100) 내부의 다른 레지스터들로 리네임하기 위한 레지스터 리네이머도 포함할 수 있다. 리오더/퇴거 유닛(135)은 비순차적 실행, 및 비순차적으로 실행된 명령어들의 후속적인 순차적 퇴거를 지원하기 위해, 전술한 리오더 버퍼들, 로드 버퍼들 및 저장 버퍼들과 같은 컴포넌트들을 포함한다. 일 실시예에서, 적응성 스레드 스케줄링은 로드 또는 저장 버퍼와 같은 버퍼로부터의 스레드의 명령어의 디스패치(dispatch)를 연기하는 것을 포함하며, 이는 스레드가 현재 실행중인 스레드들과 최근에 너무 자주 충돌한 때 스케줄링이 후속적으로 지연되게 한다.

일 실시예에서, 스케줄러 및 실행 유닛(들)(140)은 실행 유닛들 상에 명령어들/동작을 스케줄링하기 위한 스케줄러 유닛을 포함한다. 예를 들어, 부동 소수점 명령어는 이용 가능한 부동 소수점 실행 유닛을 갖는 실행 유닛의 포트 상에 스케줄링된다. 아래에 더 상세히 설명되는 일 실시예에서, 스케줄러(140)는 이미 실행 중인/스케줄링된 스레드들과 너무 많이 충돌하는 실행할 스레드들을 적응적으로 스케줄링 및/또는 연기하도록 구성된다. 정보 명령어 처리 결과들을 저장하기 위해, 실행 유닛들과 관련된 레지스터 파일들도 포함된다. 예시적인 실행 유닛들은 부동 소수점 실행 유닛, 정수 실행 유닛, 점프 실행 유닛, 로드 실행 유닛, 저장 실행 유닛, 및 기타 공지된 실행 유닛들을 포함한다.

하위 레벨 데이터 캐시 및 데이터 변환 버퍼(D-TLB)(150)는 실행 유닛(들)(140)에 결합된다. 데이터 캐시는 메모리 일관성 상태들 내에 잠재적으로 유지되는 데이터 피연산자들과 같은, 최근에 사용/조작된 요소들을 저장한다. D-TLB는 최근의 가상/선형 대 물리 어드레스 변환들을 저장한다. 특정 예로서, 프로세서는 물리 메모리를 복수의 가상 페이지로 분해하기 위한 페이지 테이블 구조를 포함할 수 있다.

여기서, 코어들(101, 102)은 최근 인출된 요소들을 캐싱하는 상위 레벨 또는 퍼더-아웃(further-out) 캐시(110)에 대한 액세스를 공유한다. 상위 레벨 또는 퍼더-아웃은 실행 유닛(들)으로부터 상승하거나 더 멀리 떨어진 캐시 레벨들을 지칭한다는 점에 유의한다. 일 실시예에서, 상위 레벨 캐시(110)는 제2 또는 제3 레벨 데이터 캐시와 같은 최종 레벨 데이터 캐시 - 프로세서(100) 상의 메모리 계층 구조 내의 최종 캐시 -이다. 그러나, 상위 레벨 캐시(110)는 명령어 캐시와 연관되거나 이를 포함할 수 있으므로 그에 한정되지 않는다. 최근에 디코딩된 트레이스들을 저장하기 위해 디코더(125) 뒤에 트레이스 캐시 - 일 타입의 명령어 캐시 -가 대신 결합될 수 있다.

도시된 구성에서, 프로세서(100)는 프로세서(100) 외부의 디바이스들, 예를 들어 시스템 메모리(175), (종종, 메모리(175)에 접속하기 위한 메모리 제어기 허브 및 주변 디바이스들을 접속하기 위한 I/O 제어기 허브를 포함하는) 칩셋, 메모리 제어기 허브, 노스브리지 또는 다른 집적 회로와 통신하기 위한 버스 인터페이스 모듈(105)도 포함한다. 버스(105)는 임의의 공지된 상호접속, 예를 들어 멀티-드롭 버스, 점대점 상호접속, 직렬 상호접속, 병렬 버스, 일관성(예를 들어, 캐시 일관성) 버스, 계층화된 프로토콜 아키텍처, 차동 버스 및 GTL 버스를 포함할 수 있다. 메모리(175)는 프로세서(100)에 전용화되거나 시스템 내의 다른 디바이스들과 공유될 수 있다. 메모리(175)의 타입들의 일반적인 예들은 동적 랜덤 액세스 메모리(DRAM), 정적 RAM(SRAM), 비휘발성 메모리(NV 메모리) 및 다른 공지된 저장 디바이스들을 포함한다. 디바이스(180)는 그래픽 가속기, 메모리 제어기 허브에 결합된 프로세서 또는 카드, I/O 제어기 허브에 결합된 데이터 저장소, 무선 송수신기, 플래시 디바이스, 오디오 제어기, 네트워크 제어기 또는 다른 공지된 디바이스를 포함할 수 있다는 점에 유의한다.

도시된 실시예에서 제어기 허브 및 메모리는 프로세서(100)의 밖에 도시된다는 점에 유의한다. 그러나, 본 명세서에서 설명되는 방법들 및 장치들의 구현들은 그에 한정되지 않는다. 실제로, 더 많은 로직 및 디바이스들이 시스템 온 칩(SOC)과 같은 단일 다이 상에 집적되고 있으므로, 이러한 디바이스들 각각은 프로세서(100) 상에 통합될 수 있다. 예를 들어, 일 실시예에서, 메모리 제어기 허브는 프로세서(100)와 동일한 패키지 및/또는 다이 상에 위치한다. 여기서, 코어의 일부(온-코어 부분)는 제어기 허브와 같은 다른 디바이스들과 인터페이스하기 위한 제어기 허브를 포함한다. SOC 환경에서는, 네트워크 인터페이스, 코프로세서들 및 임의의 다른 공지된 컴퓨터 디바이스들/인터페이스와 같은 훨씬 더 많은 디바이스가 단일 다이 또는 집적 회로 상에 집적되어, 높은 기능성 및 낮은 전력 소비를 갖는 작은 폼 팩터를 제공할 수 있다.

일 실시예에서, 프로세서(100)는 하드웨어 트랜잭셔널 실행, 소프트웨어 트랜잭셔널 실행 또는 이들의 조합/하이브리드를 행할 수 있다. 코드의 임계 또는 원자 섹션/영역의 실행으로도 지칭될 수 있는 트랜잭션은 원자 그룹으로서 실행될 명령어들 또는 동작들의 그룹핑을 포함한다. 예를 들어, 명령어들 또는 동작들은 트랜잭션 또는 임계 섹션을 구분하는 데 사용될 수 있다. 아래에 더 상세히 설명되는 일 실시예에서, 이러한 명령어들은 전술한 디코더들과 같은 프로세서(100)의 하드웨어에 의해 인식될 수 있는 명령어 세트 아키텍처(ISA)와 같은 명령어들의 세트의 일부이다. 종종, 이러한 명령어들은, 고레벨 언어로부터 하드웨어 인식 가능 어셈블리 언어로 컴파일되면, 디코더들이 디코드 단계 동안 인식하는 명령어들의 연산 코드들(옵코드들) 또는 다른 부분들을 포함한다.

통상적으로, 트랜잭션의 실행 동안, 메모리에 대한 갱신들은 트랜잭션이 커미트될 때까지 전역적으로 보이지 않게 된다. 일례로서, 하나의 위치에 대한 트랜잭셔널 기입은 잠재적으로 로컬 스레드에 보이지만, 트랜잭셔널 기입을 포함하는 트랜잭션이 커미트될 때까지는 다른 스레드로부터의 판독에 응답하여 기입 데이터가 전달되지 않는다. 아래에 더 상세히 설명되는 바와 같이, 트랜잭션이 아직 미결인 동안, 메모리로부터 로딩되고 그 안에 기입되는 데이터 아이템들/요소들이 추적된다. 트랜잭션이 커미트 포인트에 도달하면, 트랜잭션에 대해 충돌이 검출되지 않은 경우, 트랜잭션이 커미트되며, 트랜잭션 동안 행해진 갱신들이 전역적으로 보이게 된다. 그러나, 트랜잭션이 그의 미결 동안 무효화되는 경우, 트랜잭션은 중단되며, 갱신들이 전역적으로 보이게 되지 않고 잠재적으로 재개된다. 결과적으로, 본 명세서에서 사용될 때, 트랜잭션의 미결은 실행을 시작하였으나 커미트되지 않거나 중단된, 즉 미결 상태인 트랜잭션을 지칭한다.

소프트웨어 트랜잭셔널 메모리(STM) 시스템은 종종 소프트웨어 또는 코드의 실행 내에서 또는 적어도 주로 그를 통해 액세스 추적, 충돌 해결 또는 다른 트랜잭셔널 메모리 작업들을 수행하는 것을 지칭한다. 일 실시예에서, 프로세서(100)는 하드웨어/로직을 이용하여, 즉 하드웨어 트랜잭셔널 메모리(HTM) 시스템 내에서 트랜잭션들을 실행할 수 있다. HTM을 구현할 때 아키텍처 및 마이크로아키텍처의 양 관점에서 다양한 특정 구현 상세들이 존재하며; 이들 중 대부분은 설명을 불필요하게 불명확하게 하지 않기 위해 여기서는 설명되지 않는다. 그러나, 일부 구조들, 자원들 및 구현들은 예시의 목적을 위해 개시된다. 그러나, 이러한 구조들 및 구현들은 요구되지는 않으며, 상이한 구현 상세들을 갖는 다른 구현들로 증대 및/또는 대체될 수 있다는 점에 유의해야 한다. 트랜잭셔널 메모리와 밀접하게 관련된 다른 실행 기술은 (종종 하드웨어 록 생략(HLE)으로 지칭되는) 록 생략을 포함한다. 이러한 시나리오에서, 록 명령어 쌍들(록 및 록 해제)은 (사용자, 소프트웨어 또는 하드웨어에 의해) 원자 시작 및 종료 구분기(delineator)들로 대체된다. 그리고, 록 명령어 쌍들 간의 코드의 섹션은 트랜잭션처럼 실행된다.

하나의 조합으로서, 프로세서(100)는 하이브리드 접근법(하드웨어 및 소프트웨어 양자)을 이용하여, 예를 들어 STM 및 HTM 시스템들 둘다의 이점들을 이용하려고 시도하는 무제한 트랜잭셔널 메모리(UTM) 시스템 내에서 트랜잭션들을 실행할 수 있다. 예를 들어, HTM은 작은 트랜잭션들을 매우 빠르고 효율적으로 실행하는데, 그 이유는 그가 액세스 추적, 충돌 검출, 검증 및 트랜잭션들의 커미트 모두를 수행하기 위해 소프트웨어에 의존하지 않기 때문이다. 그러나, HTM들은 통상적으로 더 작은 트랜잭션들만을 처리할 수 있는 반면, STM들은 무제한 크기의 트랜잭션들로 종종 지칭되는 더 큰 크기의 트랜잭션들을 처리할 수 있다. 따라서, 일 실시예에서, UTM 시스템은 하드웨어를 이용하여 더 작은 트랜잭션들을 실행하고, 소프트웨어를 이용하여, 하드웨어에 대해서는 너무 큰 트랜잭션들을 실행한다. 아래의 설명으로부터 알 수 있듯이, 소프트웨어가 트랜잭션들을 처리하고 있을 때에도, 하드웨어는 소프트웨어를 지원하고 가속화하는 데 사용될 수 있으며, 이러한 하이브리드 접근법은 통상적으로 하드웨어 가속 STM으로 지칭되는데, 그 이유는 주요 트랜잭셔널 메모리 시스템(부기 등)이 소프트웨어 내에 상주하지만 하드웨어 훅들을 이용하여 가속화되기 때문이다.

도 2를 간단히 참조하면, STM 시스템의 간소 실시예가 도시된다. 도 2의 설명은 주로 낙관적 판독 STM 시스템을 참조한다. 이와 관련하여, 트랜잭셔널 메모리 시스템을 구현할 때 이루어질 수 있는 몇 가지 설계 선택을 예시하기 위해, 직접 대 간접 참조, 낙관적 대 비관적 병행성 제어 및 업데이트 인 플레이스(update in-place) 대 기입 버퍼링과 같은 소정의 트랜잭셔널 메모리 구현 상세들의 설명이 제공된다. 그러나, 본 명세서에서 설명되는 방법들 및 장치들은 임의의 트랜잭셔널 메모리 시스템, 예를 들어 HTM, 하드웨어 가속 STM, 하이브리드 STM, 비관적 STM 또는 다른 공지된 트랜잭셔널 메모리 시스템을 위해서는 물론, 임의의 공지된 구현 상세들과 관련해서도 구현될 수 있다.

STM의 일 실시예에서, 메모리 위치들(어드레스들), 데이터 아이템들 및/또는 데이터 요소들, 예를 들어 캐시 라인(215) 내에 유지될 데이터 요소(201)는 어레이(240) 내의 메타데이터 위치(250)와 같은 메타데이터 위치들과 연관된다. 일례로서, 데이터 요소(201) 및/또는 캐시 메모리(205)의 라인(215)과 관련된 어드레스 또는 그의 일부는 어레이(240) 내의 위치(250)를 인덱싱하기 위해 해싱된다. 종종, 트랜잭셔널 메모리와 관련하여, 메타데이터 위치(250)는 트랜잭션 레코드로서 지칭되는 반면, 어레이(240)는 트랜잭션 레코드들의 어레이로서 지칭된다. 그러나, 전체 트랜잭션에 대한 메타데이터는 트랜잭션 자체에 대한 정보, 예를 들어 아래에 더 상세히 설명되는 트랜잭션 서술자(280), 판독 세트(265) 및 기입 세트(270)를 포함할 수 있다. 트랜잭션 레코드(250)는 도시된 바와 같이 단일 캐시 라인과 연관되지만, 트랜잭션 레코드는 캐시 라인(215)보다 작거나 클 수 있는 데이터 요소(201)의 크기와 같은 임의의 데이터 입도 레벨로 제공될 수 있는 것은 물론, 피연산자, 객체, 클래스, 타입, 데이터 구조 또는 임의의 다른 데이터 요소도 포함할 수 있다.

데이터 아이템(201)과 같은 데이터 아이템, 데이터 객체 또는 데이터 요소는 하드웨어, 소프트웨어 또는 이들의 조합에 의해 정의되는 바와 같은 임의의 입도 레벨의 데이터를 포함할 수 있다. 데이터, 데이터 요소들, 데이터 아이템들 또는 이들에 대한 참조들의 예들의 비포괄적인 리스트는 메모리 어드레스, 메모리 객체, 클래스, 일 타입의 동적 언어 코드의 필드, 일 타입의 동적 언어 코드, 변수, 피연산자, 데이터 구조, 및 메모리 어드레스에 대한 간접 참조를 포함한다. 그러나, 임의의 공지된 데이터 그룹핑이 데이터 요소 또는 데이터 아이템으로서 지칭될 수 있다. 일 타입의 동적 언어 코드의 필드 및 일 타입의 동적 언어 코드와 같은 위의 몇 가지 예는 동적 언어 코드의 데이터 구조들을 지칭한다. 예를 들어, 선 마이크로시스템즈 사로부터의 자바(상표)와 같은 동적 언어 코드는 강하게 타입화된 언어이다. 각각의 변수는 컴파일 시에 알려지는 타입을 갖는다. 타입들은 2개의 카테고리 - 원시함수 타입들(부울(boolean) 및 수, 예를 들어 정수, 부동) 및 참조 타입들(클래스, 인터페이스 및 어레이 -로 분류된다. 참조 타입들의 값들은 객체들에 대한 참조들이다. 자바(상표)에서, 필드들로 구성되는 객체는 클래스 인스턴스 또는 어레이일 수 있다. 클래스 A의 객체가 주어지면, 표기법 A::x를 이용하여 타입 A의 필드 x를 나타내고, a.x를 이용하여 클래스 A의 객체 a의 필드 x를 나타내는 것이 관례적이다. 예를 들어, 식이 a.x = a.y + a.z로서 표현될 수 있다. 여기서, 필드 y 및 필드 z가 로딩되어 추가되며, 그 결과는 필드 x에 기입된다.

따라서, 데이터 아이템들에 대한 메모리 액세스들의 모니터링/버퍼링은 임의의 데이터 레벨 입도에서 수행될 수 있다. 예를 들어 일 실시예에서, 데이터에 대한 메모리 액세스들은 타입 레벨에서 모니터링된다. 여기에서, 필드 A::x에 대한 트랜잭셔널 기입 및 필드 A::y의 비 트랜잭셔널 로드가 동일한 데이터 아이템, 즉, 타입 A에 대한 액세스들로서 모니터링될 수 있다. 또 다른 실시예에서, 메모리 액세스 모니터링/버퍼링은 필드 레벨 입도에서 수행된다. 여기에서, A::x에 대한 트랜잭셔널 기입 및 A::y의 비 트랜잭셔널 로드는, 그것들이 분리된 필드들에 대한 참조들이기 때문에, 동일한 데이터 아이템에 대한 액세스들로서 모니터링되지 않는다. 그외의 데이터 구조들 또는 프로그래밍 기법들이 데이터 아이템들에 대한 메모리 액세스들을 추적하는 데 있어서 고려될 수 있다는 것을 유념하라. 예시로서, 클래스 A의 객체의 필드들 x 및 y(즉, A::x 및 A::y)가 클래스 B의 객체들을 가리킨다고 가정하면, 새롭게 할당된 객체들로 초기화되고, 초기화 이후 절대 기입되지 않는다. 일 실시예에서, A::x가 가리키는 객체의 필드 B::z에 대한 트랜잭셔널 기입은 A::y가 가리키는 객체의 필드 B::z의 비 트랜잭셔널 로드에 관한 동일한 데이터 아이템에 대한 메모리 액세스로서 모니터링되지 않는다. 이러한 예시들로부터 추정하면, 모니터들이 임의의 데이터 입도 레벨에서 모니터링/버퍼링을 수행할 수 있다는 것을 결정하는 것이 가능하다.

종종 STM에서, 트랜잭션 기록(TR)(250)(또한 트랜잭셔널 락(lock)으로서 지칭됨)은, 데이터 요소(201)와 같은, 연관된 메모리 어드레드들에 대한 액세스 및 그의 소유권의 상이한 레벨들을 제공하도록 이용된다. 일 실시예에서, TR(250)은 언락된(unlocked) 또는 소유되지 않은 상태를 표현하는 제1 값을 유지하고 락된(locked) 또는 소유된 상태를 표현하는 제2 값을 유지한다. 일부 구현들에서, TR(250)은, 배타적 소유권을 단일 소유자에게 제공하기 위한 기입 락/배타적 락 상태, 판독기(들)이 데이터 요소(201)를 판독하며 그외의 것들이 데이터 요소(201)를 여전히 판독하는 것을 허용하지만 기입하는 것을 허용하지 않는 판독 락, 및 잠재적 기입기가 배타적 기입 락을 획득하기를 원하지만 현재 판독기들이 데이터 요소(201)를 릴리즈하는 것을 기다리고 있는 기입/배타적 락 상태로 업그레이드할 목적의 판독 락과 같은, 락된 또는 소유된 상태들의 다수의 상이한 레벨이 가능할 수 있다.

TR(250)에서 언락된 상태들 및 락된 상태들을 표현하는 데 이용되는 값들은 구현에 기초하여 변한다. 예를 들어, 낙관적 병행성 제어 STM의 일 실시예에서, TR(250)은 언락된 상태를 표시하기 위한 버전 또는 타임스탬프 값(예를 들어, 데이터 요소(201)를 업데이트한 가장 최근에 커밋된 트랜잭션을 표현하는 값)을 유지한다. 그리고 TR(250)은 락된 상태를 표현하기 위한, 트랜잭션 서술자(280)와 같은, 트랜잭션 서술자에 대한, 포인터와 같은, 참조를 유지한다. 일반적으로, 트랜잭션 서술자(280)는 트랜잭션 ID(281) 및 트랜잭션 상태(282)와 같은, 트랜잭션을 서술하는 정보를 유지한다. 트랜잭션 서술자(280)에 대한 포인터를 이용하는 전술한 예시는 직접 참조 STM으로서 종종 지칭될 수 있고, 여기에서 트랜잭션 기록(250)은 소유하는 트랜잭션(281)에 대한 직접 참조를 유지한다.

또 다른 실시예에서, 소유된 또는 락된 값은, 기입 세트(270)의 기입 엔트리(271)와 같은, 기입 세트 엔트리에 대한 참조를 포함한다. 일 실시예에서, 기입 엔트리(271)는 락이 획득되기 이전의 트랜잭션 기록(250)으로부터 로그된 버전 번호; 트랜잭션(281)이 기입 엔트리(271)와 연관된다는 것을 표시하는 트랜잭션 서술자(280)에 대한 포인터; 및 트랜잭션 기록(250)에 대한 백(back) 포인터를 유지하기 위한 것이다. 이러한 예시는 종종 간접 참조 STM으로서 지칭되고, 여기에서 TR(250)은 소유하는 트랜잭션을 간접적으로, 즉, 기입 엔트리(271)를 통해 참조한다.

TR(250)에서의 버전 또는 포인터 값과는 대조적으로, 비관적 병행성 제어 STM의 일 실시예에서, TR(250)은 비트 벡터/맵을 유지하고, 여기에서 더 상위 비트들은 실행하는 트랜잭션들(또는 트랜잭션들을 실행하는 스레드들)을 표현하며, LSB(251) 및 제2 LSB(252)는 기입 락 상태, 언락된 상태, 및 기입 락 상태로의 판독 업그레이드를 표현한다. 언락된 상태에서, 설정된 상위 비트들은 데이터 요소(201)를 판독한 대응하는 트랜잭션들을 표현한다. 락된 상태에서, 상위 비트들 중 하나는 트랜잭션들 중 어느 것이 기입 락된 데이터 요소(201)를 갖는지를 표시하도록 설정된다.

일 실시예에서, 액세스 배리어는 적합한 액세스 및 데이터 유효성을 보장하기 위해 데이터 요소(201)에 대한 메모리 액세스 시에 실행된다. 여기에서, TR(250)의 소유권 상태를 결정하기 위한 소유권 테스트가 종종 수행된다. 일 실시예에서, LSB(251) 및/또는 제2 LSB(252)와 같은, TR(250)의 일부분이 데이터 요소(201)의 가용성을 표시하도록 이용된다. 예시를 위하여, LSB(251)가, 로직 0과 같은, 제1 값을 유지하는 경우, TR(250)은 언락되고, LSB(251)가, 로직 1과 같은, 제2 값을 유지하는 경우, TR(250)은 락된다. 이러한 예시에서, 제2 LSB(252)는 판독 소유자가 배타적 기입 락으로의 업그레이드를 의도하는 경우 표시하도록 이용될 수 있다. 대안으로, 비트들(251-252)의 조합뿐만 아니라 그외의 비트들이, 전술한 다수의 락 상태와 같은, 상이한 소유권 상태들을 인코딩하는 데 이용될 수 있다.

일 실시예에서, 메모리 액세스들에서의 배리어들은 전술한 소유권 테스트들과 함께 부기(bookkeeping)를 수행한다. 예를 들어, 데이터 요소(201)의 판독 시, TR(250) 상에서 소유권 테스트가 수행된다. 언락되면, 즉, 낙관적 병행성 제어 STM에서 버전 값을 유지하면, 그 버전 값은 판독 세트(266)의 판독 엔트리(265)에 로그된다. 이후, 트랜잭션의 미결 동안 또는 트랜잭션의 커밋(commit)에서 온-디맨드일 수 있는, 검증 시, TR(250)의 현재 값은 엔트리(266)에 로그된 값과 비교된다. 그 값들이 상이하면, 또 다른 소유자가 TR(250)을 락했거나 및/또는 데이터 요소(201)를 수정한 것인데, 이는 잠재적 데이터 충돌을 야기한다. 부가적으로, 기입 배리어는, 소유권 테스트를 수행하는 것, 락을 획득하는 것, 락을 업그레이드하기 위한 의도를 표시하는 것, 기입 세트(270)를 관리하는 것 등과 같은, 데이터 요소(201)에 대한 기입을 위한 유사한 부기 동작들을 수행할 수 있다.

사전에, 트랜잭션의 끝에서, 트랜잭션의 커밋이 시도된다. 예시로서, 트랜잭션의 미결 동안 판독된 위치들이 유효하다는 것을 보장하도록 판독 세트가 검증된다. 다시 말해서, 판독 엔트리(266)에서 유지되는 로그된 버전 값은 트랜잭션 기록(250)에서 유지되는 현재 값과 비교된다. 현재 값이 로그된 버전과 같으면, 데이터 요소(201)를 업데이트한 그외의 액세스는 없다. 따라서, 엔트리(266)와 연관된 판독이 유효한 것으로 결정된다. 모든 메모리 액세스들이 유효한 것으로 결정되면, 트랜잭션은 커밋 및/또는 퇴거된다.

그러나, 버전들이 상이하고 현재 트랜잭션이 판독 및 이후 데이터 요소에 기입하지 않았으면, 또 다른 트랜잭션이 TR(250)의 락을 획득하거나 및/또는 데이터 요소(201)를 수정한다. 결과적으로, 트랜잭션은 이후 중단될 수 있다. 다시 한번, STM의 구현에 따라, 커밋 및 중단 기능들에 의해 수행된 동작들은 교환가능할 수 있다. 예를 들어, 기입 버퍼링 STM에서, 트랜잭션의 미결 동안 기입들은 버퍼링되고, 커밋 시 그것들은 대응하는 메모리 위치들에 복사된다. 여기에서, 트랜잭션이 중단되는 경우, 기입 버퍼 내의 새로운 값들은 폐기된다. 반대로, 업데이트 인 플레이스(update-in-place) STM에서, 새로운 값들은 대응하는 메모리 위치들에서 유지되고, 오래된 값들은 기입 로그에 로그된다. 여기에서, 중단 시, 오래된 값들은 메모리 위치들에 다시 복사되고, 커밋 시, 기입 로그 내의 오래된 값들은 폐기된다.

기입 버퍼링 STM에서 또는 업데이트 인 플레이스 STM에서, 업데이트된 메모리 위치들의 롤 백이 필요한 경우, 언두(undo) 로그(290)와 같은, 언두 로그가 종종 이용된다. 예시로서, 언두 로그(290)는, 트랜잭션 동안 메모리에 대한 업데이트들을 추적하기 위한, 엔트리(291)와 같은 엔트리들을 포함한다. 예시하면, 업데이트 인 플레이스 STM에서, 메모리 위치들은 직접 업데이트된다. 그러나, 중단 시, 업데이트들은 언두 로그(290)에 기초하여 폐기된다. 일 실시예에서, 언두 로그(290)는 네스팅된(nested) 트랜잭션들을 롤 백할 수 있다. 여기에서, 언두 로그(290)는, 네스팅된 트랜잭션의 시작 바로 직전의 체크포인트로 롤 백하는 것과 같이, 더 높은/외부 레벨 트랜잭션들을 무효화하지 않고 네스팅된 트랜잭션을 잠재적으로 롤백한다.

전술한 바와 같이, 트랜잭션들은 로컬 프로세싱 요소들에 의해서뿐만 아니라 잠재적으로 그외의 프로세싱 요소들에 의한 데이터 아이템들에 대한 트랜잭셔널 메모리 액세스들을 포함한다. 트랜잭셔널 메모리 시스템 내의 안전 메커니즘들 없이는, 이러한 액세스들의 일부는 무효한 데이터 및 실행, 즉, 판독을 무효화하는 데이터에 대한 기입, 또는 무효한 데이터의 판독을 야기할 수 있다. 순수한 STM 시스템에서, 이러한 안전 메커니즘들은 전술한 소프트웨어 배리어들의 구성을 통해 존재한다. HTM 또는 하이브리드 HTM/STM에서, (기존의 캐시 코히어런시 프로토콜들과 같은) 프로토콜들과 함께 하드웨어 모니터들 및/또는 소프트웨어 배리어들이 그러한 안전 메커니즘들을 제공한다.

도 2는 주로 STM 환경을 도시하지만, 그것은 또한 STM에 대한 하드웨어 가속을 논의하는 데 있어서 유용하다. 예를 들어, 캐시 라인들(210-230)은, 일 실시예에서, 트랜잭셔널 속성들과 연관된다. 이러한 속성들은 메모리(즉, 메모리 계층 전체에 걸쳐 존재하는 캐시 라인들(215)의 일부)를 통해 지속될 수 있거나 또는 지속되지 않을(즉, 캐시(205) 내에서 로컬 및 캐시 라인(215)의 축출 시 손실) 수 있다. 부가적으로, 이러한 속성들은, 데이터 어레이(205)에 대한 상태 어레이 내의 부가적인 비트들과 같이, 라인들(215)의 일부일 수 있거나 또는 라인(215)와 연관될 수 있다. 또는, 일 실시예에서, 속성들은 가속을 고정(tack)하기 위한 소프트웨어 명령어들에 의해 동작되도록 구성된 비트들을 포함한다. 예를 들어, 트랜잭셔널 판독 비트 및 트랜잭셔널 기입 비트는, 각각, 트랜잭셔널 판독 및 기입 시 설정되도록 제공된다. 여기에서, 소프트웨어는 트랜잭셔널 판독 비트의 상태를 체크하여 현재 트랜잭션이 캐시 라인(215)을 이미 판독하였는지를 결정할 수 있다. 그리고 비트가 (캐시 라인(215)이 이미 액세스되었다는 것을 표시하는) 설정되면, 소프트웨어는, 트랜잭션 기록(250)을 체크하는 것, 판독 세트(265)에 트랜잭션 기록 값(250)을 로그하는 것 등과 같은, 판독 배리어 동작들을 생략한다. 여기에서, 트랜잭션 내의 동일한 메모리 어드레스에 대한 후속하는 소프트웨어 트랜잭셔널 액세스들은, 하드웨어 속성들 - 소프트웨어는 그에 따라 액세스, 해석, 및 행동할 수 있음 - 을 이용하여 가속화된다.

도 1의 논의로 돌아가면, 일 실시예에서, 프로세서(100)는, 데이터 아이템들과 연관된, 액세스들, 및 잠재적인 후속하는 충돌들을 검출 또는 추적하는 모니터들을 포함한다. 이러한 모니터들은, 일 실시예에서, STM의 가속에 대해 전술한 속성들과 동일한 (또는 포함된) 속성들이라는 것을 유념하라. 이러한 시나리오에서, 모니터들은 하드웨어 추적 및 소프트웨어 가속 지원으로서의 기능을 겸할 수 있다. 예를 들어, 프로세서(100)의 하드웨어는 로드 및 저장을 추적하는 판독 모니터들 및 기입 모니터들을 포함하고, 로드 및 저장은 그에 따라 모니터링되도록 결정된다. 하드웨어 판독 모니터들 및 기입 모니터들은 기저 저장 구조들의 입도에도 불구하고 데이터 아이템들의 입도에서 데이터 아이템들을 모니터링할 수 있다. 또는 대안으로, 그것들은 저장 구조 입도에서 모니터링할 수 있다. 일 실시예에서, 데이터 아이템은 적어도 전체 데이터 아이템이 적절하게 모니터링되는 것을 보장하기 위해 저장 구조들의 입도에서 연관된 추적 메커니즘들에 의해 제한된다.

특정 예시적인 예시로서, 판독 및 기입 모니터들은, (추론적 캐시를 포함할 수 있는) 하위 레벨 데이터 캐시(150) 내의 위치들과 같은, 캐시 위치들과 연관된 속성들을 포함하여, 이러한 위치과 연관된 어드레스들로부터의 로드들 및 그들로의 저장들을 모니터링한다. 여기에서, 데이터 캐시(150)의 캐시 위치에 대한 판독 속성은 동일한 어드레스에 대해 잠재적 충돌하는 기입들에 대해 모니터링하도록 캐시 위치와 연관된 어드레스에 대한 판독 이벤트 시 설정된다. 이러한 경우에, 기입 속성들은 동일한 어드레스에 대한 잠재적 충돌하는 판독들 및 기입들에 대해 모니터링하도록 기입 이벤트들에 대해 유사한 방식으로 동작한다. 이러한 예시에 더하여, 하드웨어는 캐시 위치들이 모니터링된다는 것을 표시하도록 설정된 판독 및/또는 기입 속성들을 갖는 캐시 위치들에 대한 판독들 및 기입들에 대한 스누프(snoop)들에 기초하여 충돌들을 검출하는 것이 가능하다. 반대로, 판독 및 기입 모니터들을 설정하는 것, 또는 버퍼링된 상태로 캐시 위치를 업데이트하는 것은, 일 실시예에서, 그외의 캐시들에서 모니터링된 어드레스들을 갖는 충돌들이 검출되는 것을 허용하는, 판독 요청들 또는 소유권 요청들에 대한 판독들과 같은, 스누프들을 야기한다.

따라서, 설계에 기초하여, 캐시 라인들의 모니터링된 코히어런시 상태들 및 캐시 코히어런시 요청들의 상이한 조합들이, 공유된 판독 모니터링된 상태에서 데이터 아이템을 유지하는 캐시 라인 및 그 데이터 아이템에 대한 기입 요청을 표시하는 스누프와 같은, 잠재적 충돌들을 야기한다. 반대로, 버퍼링된 기입 상태에 있는 데이터 아이템을 유지하는 캐시 라인 및 그 데이터 아이템에 대한 판독 요청을 표시하는 스누프는 잠재적으로 충돌하는 것으로 고려될 수 있다. 일 실시예에서, 속성 상태들 및 액세스 요청들의 그러한 조합들을 검출하기 위해 스누프 로직은 충돌 검출/보고를 위한 모니터들 및/또는 로직과 같은, 충돌 검출/보고 로직뿐만 아니라 충돌들을 보고하기 위한 상태 레지스터들에 결합된다.

그러나, 조건들 및 시나리오들의 임의의 조합이 트랜잭션에 대해 무효화하는 것으로 고려될 수 있다. 트랜잭션의 비 커밋에 대해 고려될 수 있는, 인자들의 예시들은 트랜잭션하게 액세스된 데이터 아이템과 연관된 트랜잭션하게 액세스된 메모리 위치, 손실되는 모니터 정보, 손실되는 버퍼링된 데이터, 손실되는 메타데이터에 대한 충돌을 검출하는 것, 및 간섭, 링(ring) 천이, 또는 명백한 사용자 명령어와 같은, 그외의 무효화하는 이벤트를 검출하는 것을 포함한다.

일 실시예에서, 프로세서(100)의 하드웨어는 버퍼링된 방식으로 트랜잭셔널 업데이트들을 유지한다. 전술한 바와 같이, 트랜잭셔널 기입들은 트랜잭션의 커밋 전까지 전역적으로 알아볼 수 있게 되지 않는다. 그러나, 트랜잭셔널 기입들과 연관된 로컬 소프트웨어 스레드는 후속하는 트랜잭셔널 액세스들에 대한 트랜잭셔널 업데이트들에 액세스하는 것이 가능하다. 제1 예시로서, 업데이트들을 로컬 스레드들에 제공하고 그외의 외부 스레드들에 제공하지 않는 것이 가능한, 버퍼링된 업데이트들을 유지하기 위해 프로세서(100)에서 분리된 버퍼 구조가 제공된다.

대조적으로, 또 다른 예시로서, 데이터 캐시(150)와 같은, 캐시 메모리가, 동일한 트랜잭셔널 기능성을 제공하면서, 업데이트들을 버퍼링하는 데 이용된다. 여기에서, 캐시(150)는 버퍼링된 코히어런시 상태에서 데이터 아이템들을 유지하는 것이 가능하다; 하나의 경우에서, 새로운 버퍼링된 코히어런시 상태가, MESIB 프로토콜을 형성하기 위해 MESI(Modified Exclusive Shared Invalid) 프로토콜과 같은, 캐시 코히어런시 프로토콜에 추가된다. 버퍼링된 데이터 아이템 - 데이터 아이템은 버퍼링된 코히어런시 상태에서 유지됨 - 에 대한 로컬 요청들에 응답하여, 캐시(150)는 내부 트랜잭셔널 시퀀셜 오더링을 보장하기 위해 데이터 아이템을 로컬 프로세싱 요소에 제공한다. 그러나, 외부 액세스 요청들에 응답하여, 트랜잭션하게 업데이트된 데이터 아이템이 커밋까지 전역적으로 알아볼 수 있게 되지 않는 것을 보장하기 위해 오류 응답이 제공된다. 또한, 캐시(150)의 라인이 버퍼링된 코히어런시 상태에서 유지되고 축출을 위해 선택되는 경우, 버퍼링된 업데이트는 상위 레벨 캐시 메모리들에 되기입(write back)되지 않는다 - 버퍼링된 업데이트는, 커밋 이후까지, 메모리 시스템을 통해 확산, 즉, 전역적으로 알아볼 수 있게 되지 않는다. 대신, 트랜잭션이 중단될 수 있거나 또는 축출된 라인은 희생 캐시와 같은, 데이터 캐시와 상위 레벨 캐시 메모리들과 사이의 추론적 구조에 저장될 수 있다. 커밋 시, 버퍼링된 라인들은 데이터 아이템을 전역적으로 알아볼 수 있게 하기 위해 수정된 상태로 천이된다.

용어들 내부 및 외부는 캐시를 공유하는 프로세싱 요소들 또는 트랜잭션의 실행과 연관된 스레드의 관점에 대해 종종 상대적이라는 것을 유념하라. 예를 들어, 트랜잭션의 실행과 연관된 소프트웨어 스레드를 실행하기 위한 제1 프로세싱 요소는 로컬 스레드로 지칭된다. 따라서, 전술한 곳에서, 어드레스에 대한 캐시 라인이 버퍼링된 코히어런시 상태에서 유지되게 하는 제1 스레드에 의해 미리 기입된 어드레스에 대한 저장 또는 그로부터의 로드가 수신되면, 이후 캐시 라인의 버퍼링된 버전이, 제1 스레드가 로컬 스레드이기 때문에 그것에 제공되게 한다. 대조적으로, 제2 스레드는 동일한 프로세서 내의 또 다른 프로세싱 요소 상에서 실행되고 있을 수 있지만, 버퍼링된 상태에서 유지되는 캐시 라인을 책임지는 트랜잭션의 실행과 연관되지 않는다 - 외부 스레드; 따라서, 어드레스에 대한 제2 스레드로부터의 로드 또는 저장은 캐시 라인의 버퍼링된 버전을 놓치고, 정상 캐시 대체가 상위 레벨 메모리로부터 캐시 라인의 버퍼링되지 않은 버전을 검색하는 데 이용된다.

일 실시예에서, 프로세서(100)는 트랜잭셔널 실행을 지원하기 위한 애플리케이션 코드(176)를 컴파일하기 위해서 뿐만이 아니라, 애플리케이션 코드(176)를 잠재적으로 최적화하기 위한 컴파일러/최적화 코드(177)를 실행할 수 있다. 여기에서, 컴파일러는 트랜잭션들의 실행을 가능하게 하는 동작들, 호출들, 기능들, 및 그외의 코드를 삽입할 수 있다.

컴파일러는 종종 소스 텍스트/코드를 타깃 텍스트/코드로 변환하는 프로그램 또는 프로그램들의 세트를 포함한다. 보통, 컴파일러를 이용한 프로그램/애플리케이션 코드의 컴파일은 고레벨 프로그래밍 언어 코드를 하위 레벨 기계 또는 어셈플리 언어 코드로 변환하도록 다수의 페이즈 및 패스에서 행해진다. 아직, 단순한 컴파일을 위해 단일 패스 컴파일러들이 여전히 이용될 수 있다. 컴파일러는 임의의 공지된 컴파일 기법들을 이용할 수 있고, 어휘(lexical) 분석, 전처리(preprocessing), 파싱(parsing), 시맨틱(semantic) 분석, 코드 생성, 코드 변환, 및 코드 최적화와 같은, 임의의 공지된 컴파일러 동작들을 수행할 수 있다. 트랜잭셔널 실행과 동적 코드 컴파일의 교차점은, 필요한 메모리 오더링 세이프가드들을 유지하며, 더 공격적인 최적화를 잠재적으로 가능하게 한다.

더 큰 컴파일러들은 종종 다수의 페이즈들을 포함하지만, 대체로 이러한 페이즈들은 두 개의 일반적인 페이즈들 내에 포함된다: (1) 프론트-엔드, 즉, 일반적으로 여기에서 구문 처리(syntactic processing), 시맨틱 처리(semantic processing), 및 일부 변환/최적화가 행해질 수 있음, 및 (2) 백-엔드, 즉, 일반적으로 여기에서 분석, 변환, 최적화, 및 코드 생성이 행해짐. 일부 컴파일러들은 컴파일러의 프론트-엔드와 백-엔드 사이의 윤곽의 흐려짐을 나타내는, 미들(middle)을 참조한다. 그 결과, 삽입, 연관, 생성 및, 컴파일러의 그외의 동작에 대한 참조는 전술한 페이즈들 또는 패스들뿐만 아니라, 컴파일러의 임의의 그외의 알려진 페이즈들 또는 패스들에서 행해질 수 있다. 예시적인 예로서, 컴파일러는, 컴필레이션의 프론트-엔드 페이즈에서의 호출들/동작들의 삽입 및 그 이후 트랜잭셔널 메모리 변환 페이즈 동안 하위 레벨(lower-level) 코드들로의 호출들/동작들의 변환과 같은, 컴필레이션의 하나 이상의 페이즈에서 트랜잭셔널 동작들, 호출들, 함수들, 등을 잠재적으로 삽입한다. 동적 컴필레이션 동안, 컴파일러 코드 또는 동작 최적화 코드가 그러한 동작들/호출들을 삽입할 뿐만 아니라, 런타임 동안 실행을 위한 코드를 최적화할 수 있다는 것에 유의한다. 특정한 예시적인 예로서, (이미 컴파일된 코드인) 이진 코드는 런타임 동안 동적으로 최적화될 수 있다. 여기에서, 프로그램 코드는 동적 최적화 코드, 이진 코드, 또는 그의 조합을 포함할 수 있다.

그럼에도, 실행 환경 및 컴파일러의 동적 또는 정적 성질에도 불구하고, 컴파일러는, 일 실시예에서, 트랜잭셔널 실행을 가능하게 하고/하거나 프로그램 코드의 섹션들을 최적화하도록 프로그램 코드를 컴파일한다. 따라서, 프로그램 코드의 실행 또는 STM 환경에 대한 참조는, 일 실시예에서: (1) 동적으로 또는 정적으로, 프로그램 코드를 컴파일하거나, 트랜잭셔널 구조들을 유지하거나, 그외의 트랜잭션 관련 동작들을 수행하거나, 또는 코드를 최적화하기 위한 컴파일러 프로그램(들) 또는 최적화 코드 옵티마이저(optimizer)의 실행; (2) 최적화된/컴파일된 애플리케이션 코드와 같은, 트랜잭셔널 동작들/호출들을 포함하는 메인 프로그램 코드의 실행; (3) 트랜잭셔널 구조들을 유지하거나, 그외의 트랜잭션 관련 동작들을 수행하거나, 또는 코드를 최적화하기 위해 메인 프로그램 코드와 연관된, 라이브러리들과 같은, 그외의 프로그램 코드의 실행; 또는 (4) 그의 조합을 지칭한다.

STM(software transactional memory) 시스템들 내에서 종종, 컴파 일러는 컴파일될 애플리케이션 코드에 따라 일부 동작들, 호출들, 및 그외의 코드를 삽입하는 데 이용될 것이고, 그외의 동작들, 호출들, 함수들, 및 코드가 라이브러리들 내에서 별개로 제공된다. 이것은 잠재적으로 애플리케이션 코드를 재컴파일하지 않고 라이브러리들을 최적화하고 업데이트하는 라이브러리 배포자들의 능력을 제공한다. 특정 예로서, 커밋 함수에 대한 호출은 트랜잭션의 커밋 포인트에서 애플리케이션 코드 내에서 인라인으로 삽입될 수 있지만, 커밋 함수는 업데이트가능한 라이브러리에 별개로 제공된다. 추가적으로, 특정 동작들 및 호출들을 어디에 위치시킬지에 대한 선택은 잠재적으로 애플리케이션 코드의 효율에 영향을 준다.

일 실시예에서, 프로세서(100)는 충돌을 최소화하기 위해 스레드들의 적응형 스케줄링을 지원하도록 구성된다. 그 결과, 경험적(empirical) 피드백이 스레드들 사이의 충돌을 최소화하기 위해 스레드 스케줄링에 도움을 주는 데에 이용될 수 있다. 그래서, 하나의 스레드의 트랜잭션들이 너무 자주 중단된 것을 야기하는 것과 같이, 스레드가 충돌 이력을 갖는 경우, 그 스레드들은 그들이 병렬로 실행하는 시간을 최소화하도록 적응형으로 스케줄된다. 또한, 일부 실시예들에서, 적응형 스케줄링의 목표는 경쟁 스레드들 사이의 충돌을 감소시키거나 최소화하는 것이다. 그러나, 서로로부터 경쟁을 격리하는 것은 유익하지 않을 수 있다. 따라서, 실행 병렬 처리를 유지하면서, 충돌을 감소시키는 것 사이의 균형은 잠재적으로 설계에서 구해진다. 대안으로, 설계자는 적응형 스케줄링 기법들을 사용하여 충돌을 회피하는 것을 선택할 수 있다. 적응형 스레딩은 트랜잭션을 포함하는 스레드를 적응형으로 스케줄링하는 것에 관하여 주로 논의된다는 것에 유의한다. 따라서, 논의되는 충돌은 스레드들 사이의 충돌로 인하여 중단된 트랜잭션들에 관한 것이다. 그러나, 스레드들 사이의 임의의 알려진 충돌이 이용될 수 있는데, 예를 들면, 캐시에서의 스레싱(thrashing), 공유된 자원의 독점 등이다. 그 결과, 스케줄될 스레드를 지연시키는 것과 같은, 적응형 스레드 스케줄링이 스레드들 사이의 임의의 알려진 충돌에 기초하여 수행될 수 있다.

예시적인 실시예로서, STM 구현/환경은 스레드들 사이의 스케줄링 결정들을 행한다. 예를 들면, 제1 스레드가 시작 트랜잭션 호출을 행하면, TM 시스템은 충돌하는 제2 스레드가 이미 실행되고 있는지를 결정한다. 제2 스레드가 충돌하고 있고 현재 실행 중이면, 제1 스레드는, 제1 스레드와 제2 스레드가 병렬로 실행하는 시간을 최소화하도록 적응형으로 스케줄된다. 일 실시예에서, 그러한 적응형 스케줄링은 제1 스레드의 지연 스케줄링을 통해 수행되고, 이는 충돌하는 스레드들(제1 및 제2 스레드들)의 동시 실행을 효과적으로 상쇄한다.

스레드의 적응형 스케줄링이 다른 스레드들과 관계없이 스레드 자신 내의 중단된 트랜잭션의 제한된, 자기 관점에 기초하여 수행될 수 있지만, 이러한 접근 방법은 잠재적으로 너무 신중한 것이다. 본원에서 이용될 예시적인 예시로서, 각각, 스레드 슬롯들(101a, 101b, 101c, 및 101d) 상에서 실행되는 스레드들 A, B, C, D를 가정하자. 또한, 스레드 A가 스레드 D와 자주 충돌된다(스레드 A 내의 트랜잭션들 중 많은 수가 스레드 D와의 데이터 충돌로 인하여 중단된다)는 것을 가정하자. 스레드 A 내의 트랜잭션을 시작하는 호출과 같은, 스레드 A를 스케줄하기 위한 다음 시도를 할 때, 적응형 스레드 스케줄링이 수행될 수 있다. (스레드 A가 어떤 스레드와 충돌을 일으키는지 고려하지 않고 스레드 A의 관점으로부터의 충돌들만을 신경 쓰는) 제노포빅(xenophobic) 관점에서, 스레드 A는, 그것이 자주 충돌에 직면하기 때문에 지연될 수 있다. 그러나, 스레드 D가 프로세서(100) 상에서 더 이상 실행되고 있지 않으면, 충돌에 직면하는 스레드 A의 이유가 제거된다. 그 결과, 프로세서(100) 상에서 실행되고 있지 않은 스레드 D에 의한 충돌에 대한 잠재성이 이미 감소하였기 때문에, 충돌을 회피하기 위해 스레드 A를 스케줄링함에 있어서의 지연은 낭비적이다.

따라서, 일 실시예에서, 스레드에 대한 스레드 스케줄링 결정들은 다른 스레드들과의 실제 충돌 이력에 기초하여 행해질 수 있다. 상기한 예시를 계속하면, 스레드 A가 스케줄링될 때, 스레드 D와의 그것의 충돌 레이트가 검사 또는 결정된다. 이 예시에서, 잦은 충돌들(스레드 D와의 데이터 충돌에 기인한 스레드 A에서의 트랜잭션의 중단들)은 스레드들 A 및 D가 충돌하고 있다는 것을 나타낸다. 그 결과, 스레드 A의 스케줄링은 스레드 D가 현재 실행중이면 지연된다. 그러나, 스레드 D가 현재 실행중이 아니고 스레드 A가 실행중인 스레드들 B 및 C와는 잦은 충돌을 하지 않는 경우에, 스레드 A는 정상적으로 스케줄링될 수 있다. 결과적으로, 충돌하는 스레드들이 더 이상 실행되고 있지 않은 경우에도 스레드 A가 지연되는 시나리오가 잠재적으로 회피되고, 이는 더 효율적인 스케줄링을 야기한다. 동시에, 스레드 D가 이미 실행중일 때의 스레드 A의 지연은 스레드들 A 및 D의 겹침을 최소화하고, 이는 잠재적으로 경쟁하는 스레드들 사이의 데이터 충돌에 대한 기회를 최소화한다.

트랜잭션들의 중단들과 같은, 스레드들 사이의 충돌들은 임의의 방식으로 측정/결정될 수 있다. 일 실시예에서, 충돌들은 시간에 걸쳐 결정된다. 여기에서, 충돌률이 결정된다. 미리 정해진 시간량 또는 두 개의 정의된 이벤트들 사이의 시간 기간일 수 있는 시간 기간 동안, 실행된(또는 시작된) 트랜잭션들의 총 수가 중단된 트랜잭션의 수와 함께 결정된다. 실행된 트랜잭션들의 수가 관심있는 스레드의 관점으로부터 결정된다(즉, 그 시간 기간 동안 스레드 A에서 실행된 트랜잭션들의 수). 그리고, 중단된 트랜잭션들의 수가 다른 스레드들에 관계없이 스레드 A에 대해, 또는 디자인 구현에 기초하여, 스레드들 B, C 및 D와 같은, 하나 이상의 잠재적 경쟁 스레드에 관해 스레드 A에 대하여 결정될 수 있다. 그 후, 충돌률(중단된 트랜잭션들의 수를 실행된 트랜잭션의 총 수로 나눈 것)이 계산된다. 일부 실시예들에서, 충돌률(CR)은 각각의 잠재적 경쟁 스레드들에 대해 존재할 수 있다{즉, 스레드 B와의 스레드 A에 대한 CR 또는 CR(A,B); CR(A,C); 및 CR(A,D)}는 것에 유의한다.

상기한 충돌률을 결정하는 실시예가 스레드들 사이의 충돌 레이트가 결정될 수 있는 유일한 방법은 아니다. 일 실시예에서, 충돌 레이트는 감쇠 충돌률 공식을 이용하여 결정된다. 예로서, 충돌률은 각 시간 기간 동안에 회귀적으로 결정된다. 그리고 그 충돌률은 하나 이상의 측정 기간을 이용하여 시간에 걸쳐 평균된다. 예를 들면, 수학식 1은 평균된 또는 가중화된 충돌률을 결정함에 있어서 현재 충돌률 및 이전 충돌률을 이용한다.

[수학식 1]

수학식 1에서, CR(A,D)는 평균된 또는 가중화된 충돌률이고, CR1(A,D)는 현재 기간에 대한 충돌률이고, CR'(A,D)는 이전 기간에 대한 이전 충돌률이고, P는 0 이상, 1 이하의 상수이다. P가 1에 가깝게 될수록, 수학식은 가장 최근의 충돌률을 향하여 더욱 편중된다. 그 결과, P는 미리 결정되거나 또는 동적으로 조절가능할 수 있다. 또한, 현재 충돌률이 0이거나 또는 이전 충돌률이 0이면, CR(A,D)는 비제로(non-zero) 충돌률을 향하여 가중화된다. CR1(A,D)가 0인 경우, CR'(A,D)의 이전 충돌률을 향한 가중화는 계속 감쇠한다(시간이 지남에 따라 감소한다). 예를 들면, P가 .5라고 가정하자. 그래서, CR1(A,D)가 0이면, CRA(A,D)는

가 된다. 즉, CRA(A,D)는 이전 충돌률의 절반과 같다. 더욱이, 일정 기간 동안 어떠한 트랜잭션도 실행되지 않으면, 디폴트에 의한 그 충돌률은 0에 의한 나누기 시나리오를 피하기 위해 0으로 설정될 수 있다.

그 결과, 스레드 A가 상기 예시에서 스케줄될 때, 예시로부터의 CR(A,D)의 충돌률은 너무 간격이 짧다(즉, CR(A,D)가 충돌률 임계치보다 크다). 그러나, CR(A,B) 및 CR(A,C)는 충돌률 임계치 아래이다. 충돌률 임계치는 임의의 방식, 예컨대 미리 결정된 방식 또는 동적으로 선택될 수 있다. 일 실시예에서, 충돌률 임계치는 지연 측정 기간에 걸쳐 스레드 A가 지연된 횟수에 기초하여 조절가능하다. 예를 들면, 스레드 A가 잇따라 4회 이상 지연되면, 충돌률 임계치가 증가될 수 있어, 또 다른 지연을 야기하기 위해 더 높은 충돌률이 스레드 A에 필요하게 된다. 마찬가지로, 지연이 존재하지 않고 너무 많은 트랜잭션 중단이 존재하면, 충돌률 임계치는 동적으로 낮아질 수 있다. 즉, 임계치는, 단일 스레드 또는 모든 실행 중인 스레드 전체에서, 수용가능한 수의 트랜잭션을 중단하는 것을 허용하도록 선택될 수 있다. 상기한 바와 같이, 일 실시예에서, 병렬로 실행 중인 경쟁 스레드들의 완전한 회피는 목적이 아닐 수 있다. 오히려, 이러한 실시예에서, 동시에 상이한 스레드들을 실행하는 것을 허용하고, 실행을 직렬화하지 않음으로써 병행성을 향상시키기 위해 충돌하는 스레드들의 동시 실행을 제거하는 것이 아니라 감소시킨다는 것이 중요하다.

임계치의 설정에 관계없이, CR(A,D)가 그 임계치를 넘었는지가 결정된다. 그 후, 스레드 A에서 트랜잭션을 시작하라는 호출이 행해지면, 스레드 D가 실행 중에 있는 지가 결정된다. 스레드 D가 실행 중이면, 트랜잭션을 시작하라는 호출은 지연된다. 예를 들면, 애플리케이션 인터페이스에 대한 호출은 TM(transactional memory) 런타임 환경에 의해 지연된다. 이 예시에서, 지연은 TM 시스템에 의해 수행되어서, 운영 체제(OS) 또는 하이퍼바이저(hypervisor)와 같은 제어 소프트웨어는 변경되지 않는다. 그러나, 그러한 지연은 제어 소프트웨어뿐만 아니라, 하드웨어, 펌웨어, 코드 또는 임의의 그의 조합으로 구현될 수 있다. 일 실시예에서, 이력상 충돌하는 스레드들은, 스레드들이 계속 경쟁하고 있는지를 결정하기 위해 충돌률을 재산출하기 위해 동일한 시간 동안 때때로 및/또는 주기적으로 의도적으로 스케줄된다. 즉, 스레드 D가 실행하고 있을 때마다, 스레드 A가 지연되면, 스레드들 A 및 D는 다시 병렬로 실행되지 않는 것이 가능하다. 그러나, 스레드들 A 및 D가 더 이상 충돌하지 않으면, 스레드들 A 및 D가 실제로 계속 경쟁하고 있는지를 결정하도록 가끔 본질적으로 검사하는 것이 잠재적으로 유리할 수 있다.

추가적으로, 도 1이 상이한 모듈들, 유닛들 및/또는 로직의 표현으로 예시적인 프로세서의 추상화된, 논리적 도면을 예시한다는 것에 유의해야 한다. 그러나, 본원에 개시된 방법들 및 장치들을 이용한 프로세서가 예시된 유닛들을 포함할 필요가 없다는 것에 유의해야 한다. 그리고, 프로세서는 도시된 유닛들 중 일부 또는 전부를 생략할 수 있다. 또한, 도 1은 2 개의 코어만을 도시하지만, 프로세서는 동일한 타입의 다수의 코어들과 같은 임의의 수의 코어들뿐만아니라, 각각 타입이 상이한 셋 이상의 코어를 포함할 수 있다.

도 1은 외부 메모리 컨트롤러(컨트롤러 허브(170))에 대한 인터페이스를 갖는 점대점 방식으로 결합된 프로세서의 실시예를 예시한다. 그러나, 전술한 바와 같이, 많은 현재의 프로세서는, 다수의 코어들을 상호접속하기 위한 링 구성과 같은, 상이한 상호접속 아키텍처들뿐만 아니라 공유형 캐시들 및 그외의 인터페이스들을 갖는 온-프로세서 메모리 인터페이스 모듈 - 온-칩 모듈 - 을 포함하기 시작했다. 예시되지는 않았지만, 일 실시예에서, 프로세서(100)는 링 상호접속 커플링 코어, 캐시 및 메모리 컨트롤러 컴포넌트를 포함한다.

여기에서, 캐싱 에이전트(caching agent)들이 물리적으로 분산된 캐시의 한 조각(slice)을 관리하는 데에 이용된다. 예시로서, 각 캐시 컴포넌트는 함께 위치한 코어 - 캐시의 분산된 조각을 관리하기 위한 목적으로 캐시 에이전트가 연관되는 코어 - 에 대한 캐시의 한 조각을 관리하는 것이다. 캐시 에이전트들이 링 상호접속 상의 트래픽을 핸들링하고 캐시 조각들과 인터페이스하는 것과 마찬가지로, 코어 에이전트들/컴포넌트들은 트래픽을 핸들링하고 코어들과 인터페이스한다. 추가적으로, 링 상호접속은 MCIL(Memory Controller Interface Logic) 및/또는 그외의 모듈들, 예컨대 메모리 및/또는 그래픽 프로세서와 인터페이스하는 그외의 컨트롤러들을 결합한다.

또한, 더 많은 모듈들 및 디바이스들이, 예를 들면, SOC(System On-Chip) 설계로, 단일 집적 회로, 다이, 또는 패키지 상에 통합될 수 있다. 예를 들면, 적응형 스레드 스케줄링을 지원하는 프로세서는 그래픽 가속기, 컨트롤러 허브, 코-프로세서, 신호 프로세서, 네트워크 프로세서, 데이터 저장소, 메모리, 무선 송수신기, 플래시 디바이스, 오디오 컨트롤러, 네트워크 컨트롤러, 또는 그외의 공지된 컴퓨터 시스템 디바이스와 같은 그외의 디바이스들과 통합될 수 있다.

도 3을 참조하면, 스레드 충돌들에 기초하여 스레드들을 적응형으로 스케줄하는 모듈들의 논리적 표현의 실시예가 도시된다. 스레드들(301 및 302)은 잠재적 경쟁 또는 충돌 스레드들로서 예시된다. 그들이 간단히 스레드들로서 이하에 지칭되지만, 스레드들(301 및 302)은 소프트웨어 스레드들 또는 소프트웨어 스레드들을 실행하는 물리적 스레드 슬롯들을 지칭할 수 있다. 단 두 개의 스레드들이 예시되었지만, 적응형 스케줄링은 임의의 수의 스레드들을 갖는 시스템에 적용되도록 크기조절될 수 있다. 적응형 스케줄링이 스레드(301)를 참조하여 이하에 설명되는 경우, 스레드(301)는 물리적 스레드 슬롯에서 활성, 비활성, 정지, 또는 리턴을 기다리고 있을 수 있다는 것에 유의한다. 각 경우에, 프로세서(300)는 스레드(301)를 적응형으로 스케줄하도록 동일한 또는 상이한 액션들을 취할 수 있다.

일 실시예에서, 충돌 모듈(310)은 제2 스레드(302)와의 제1 스레드(301)의 충돌 레이트를 결정한다. (후술될 바와 같은) 두 개의 스레드들 사이의 충돌 레이트를 결정하는 것은 순전히 예시적이며, 그것은 마찬가지로 컴퓨터 시스템의 (활성이든지 또는 비활성이든지 간에) 그외의 스레드들에 회귀적으로 적용될 수 있다는 것에 유의한다. 예를 들면, 두 개는 활성이고, 두 개는 비활성인 네 개의 스레드가 존재한다고 가정하자. 충돌 레이트 결정 및 추적은 그외의 세 개의 스레드들 각각에 관하여 제1 스레드에 대해 행해질 수 있고, 이는 세 개의 충돌 레이트 또는 충돌률을 야기한다. 또는, 트래킹은 두 개의 활성 스레드 중에서만 행해질 수 있고, 비활성 스레드들은 그들의 환경의 일부분으로서 그 시간에서 그외의 활성 스레드들과의 그들의 이전 충돌률들을 유지한다. 전술한 바와 같이, 적응형 스레드 스케줄링은 스레드들 사이의 충돌 레이트에 제한되지 않는다. 대신에, 충돌 레이트는 특정한, 그외의 스레드들과는 상관없이 관심있는 스레드들에 대해 결정될 수 있다(즉, 그외의 스레드 중 어느 것이 충돌을 야기했는지와 무관한 스레드들 내의 충돌의 수).

하나의 예시로서, 충돌 레이트는 시간에 걸친 스레드들 사이의 임의의 측정가능한 충돌(즉, 충돌의 레이트)을 포함한다. 예시를 위해, 데이터 아이템(305)이 스레드들(301 및 302)에 의해 공유된, 공유된 데이터 위치(예를 들면, 캐시 라인)에 유지된다고 가정하자. 그리고 캐시 컨트롤 로직(도시되지 않음)은 스레드(302)로부터의 요청들에 의해 스레드(301)에 대한 캐시 라인의 축출의 수를 결정한다. 여기에서, 충돌 레이트는 시간에 걸친 스레드(302)에 의한 스레드(301)의 캐시 라인들의 축출들의 수를 포함할 수 있다. 도 1을 참조하여 전술한 그러한 자원들과 같은, 스레드 자원들 사이의 유사한 충돌들이 충돌 레이트에 대해 추적될 수 있다는 것에 유의한다.

일 실시예에서, 스레드(302)와의 스레드(301)의 충돌 레이트는 시간량에 걸친 스레드(302)와의 충돌들에 기인하여 스레드(301)에서 중단된 트랜잭션들의 수를 포함한다. 또 다른 실시예에서, 스레드(302)와의 스레드(301)의 충돌 레이트는 시간량에 걸친 스레드(302)와의 충돌들에 기인하여 스레드(301)에서 중단된 트랜잭션들의 수를 시간량에 걸친 스레드(301)에서 실행된 트랜잭션들의 총 수로 나눈 충돌률을 포함한다. 예를 들면, 그 기간 동안 실행된 트랜잭션들의 총 수가 10이고, 중단된 수가 4이면, 충돌률은 .4 또는 40%이다.

시간에 대한 충돌률에 관하여 바로 위에서의 논의는 단일 양자 시간에 관한 것이라는 점에 주목한다. 그러나, 충돌률은 다수의 시간 기간(예를 들어, 1보다 큰 임의의 정수의 기간)에 걸쳐 평균화될 수 있다. 일 예에서, 다수의 기간들에 대한 충돌률들의 평균은 동등하게 가중될 수 있다. 그러나, 다른 실시예에서, 다수의 기간들에 대한 충돌률들은 바이어싱되거나 가중될 수 있다. 예를 들어, 위에서의 수학식 1이 아래에 재복사된다.

[수학식 1]

여기서, CR1(301, 302)은 전술한 현재의 충돌률을 포함한다. 그리고 이전의 충돌률 CR'(301, 302)은 이전 시간량 동안 제2 스레드(302)와의 충돌들로 인하여 스레드(301)에서 중단된 이전 수의 트랜잭션들을 이전 시간량 동안 제1 스레드(301)에서 실행된 이전 수의 트랜잭션들로 나눈 것을 포함한다. 또한, P는 0 이상 및 1 이하인 상수이다. 상수 P는 최종 (또는 평균화된) 충돌률을 얻기 위해 2개의 충돌률들 사이에 가중치를 제공한다. 예를 들어, P가 .5면, 충돌률들 {CR1(301, 302) 및 CR'(301, 302)}는 동일하게 가중된다. P가 .5보다 크면, 가중된/평균화된 충돌률은 현재의 충돌률, CR1(301, 302) 쪽으로 바이어싱된다. 그리고 P가 .5보다 작으면, 가중된/평균화된 충돌률은 이전의 충돌률, CR'(301, 302) 쪽으로 바이어싱된다. 일 실시예에서 P는 정적인 미리결정된 상수이다. 대안적으로, P는 런타임 동안에, 제1 스레드의 스케줄링이 실제로 지연되는 횟수에 기초하는 등으로, 동적으로 조정가능하다.

바이어스 공식(수학식 1)이 충돌률들의 2개의 기간에 대한 것이지만, 충돌률은 2개보다 많은 기간에 대하여 평균화되거나 가중될 수 있다. 또한, 위에서 언급한 바와 같이, 새로운 트랜잭션이 스레드(301)에서 실행되지 않으면 수학식 1이 시간에 대해 감쇠한다는 것을 주목할 필요가 있다. 여기서, 기간 또는 시간량에서 전체 트랜잭션의 수가 0이면, CR1(301, 302)는 0으로 나누는 경우를 피하기 위해 0으로 설정된다. 그리고 수학식 1은 이전의 충돌률, (1-P_)*CR'(301, 302)에만 기초하게 된다. 그 결과, P가 0이 아닌 한, CR'(310, 302)은 1보다 작은 부분에 의해 곱해지고, 이것은 이전의 CR'(301, 302)에 비하여 CR(301, 302)을 작게 만든다. 또한, CR(301, 302)의 후속하는 재계산에 의해, 새로운 CR'(301, 302)이 완전하게 재계산될 수 있거나, 이전의 기간으로부터의 평균화된 충돌률, CR(301, 302)일 수 있거나, 또는 계산된 충돌률의 이전 기간으로부터의 현재의 충돌률, CR1(301, 302)일 수 있다는 것에 주목한다.

전술한 바와 같이, 충돌률들은 중단된 다수의 트랜잭션 및 시간량(기간) 동안에 실행된 전체 수의 트랜잭션을 이용하여 충돌 모드(310)에 의해 계산될 수 있다. 가장 직접적인 예시로서, 시작되거나 실행된 다수의 트랜잭션뿐만 아니라 중단된 다수의 트랜잭션을 추적(또는 카운트)하기 위해 카운터들이 사용된다. 여기서, 이러한 카운터들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합으로 구현될 수 있다. 하드웨어 예시에서, 하드웨어 트랜잭션 카운터는 트랜잭션이 시작, 커밋, 실행, 또는 퇴거될 때마다 증분된다. 그리고 트랜잭션의 중단이 발생하면(즉, 일관성 프로토콜들 및 추적 메커니즘으로 인해 캐시에서 충돌이 검출되면), 중단 카운터가 증분된다. 각각의 카운터는 기간의 시작 시에 리셋되고, 최종 카운트(전체 트랜잭션 및 중단들 각각)를 유지한다.

소프트웨어 구현에서, 코드는 시간에 대해 실행되고 중단된 트랜잭션들의 가변 카운트 등의 카운트를 유지하기 위해 실행된다. 예를 들어, 시작 트랜잭션 명령어가 컴파일되거나, 인카운터되거나, 또는 실행되면, 트랜잭션 카운트 변수가 증분된다(즉, 소프트웨어 트랜잭션 카운트 변수에 대해 지정된 하드웨어 위치가 STM 환경 등의 소프트웨어 환경으로부터 코드의 실행에 응답하여 증분된다). 마찬가지로, 충돌 핸들러 또는 중단에 대한 호출이 소프트웨어에 의해 검출되면, 그것은 마찬가지로 소프트웨어 중단 카운트를 증분한다. 여기서, 트랜잭셔널 메모리 시스템은, 런타임 동안에 실행될 때, 올바른 카운터들(즉, 올바른 스레드에 대한 중단 카운터)이 증분되도록, 어느 스레드가 충돌을 야기했는지를 나타내기 위한 메타데이터를 유지할 수 있다. 예를 들어, 4개의 스레드가 실행 중이고, 제1 및 제4 스레드 간에 충돌이 있으면, 트랜잭셔널 메모리 시스템은 그러한 정보를 보유한다. 이 경우, 중단된 트랜잭션들에 대한 3개의 카운트 변수들(스레드 1 대 스레드 2, 스레드 1 대 스레드 3, 스레드 1 대 스레드 4)이 스레드 1에 대해 유지될 수 있다. 트랜잭셔널 메모리 시스템 정보의 결과로서, 스레드 1 대 스레드 4에 대한 카운트는 트랜잭셔널 메모리 시스템 메타데이터 정보에 기초하여 올바르게 증분될 수 있다.

따라서, 일 실시예에서, 충돌 모듈(310)은 (전술한 바와 같은) 하나 이상의 소프트웨어 카운터들 및 코드를 보유하는 저장 매체를 포함하고, 코드는 실행될 때, 소프트웨어 카운터가 시간량에 걸쳐 제2 스레드와의 충돌들로 인해 제1 스레드에서 중단된 다수의 트랜잭션들을 추적하게 한다. 전술한 바와 같이, 코드는 트랜잭션 라이브러리의 일부와 같은 STM 환경의 일부일 수 있고, 이것은 런타임 동안에 실행되면 '카운터' 갱신들을 제공한다. 용어 '소프트웨어 카운터'의 사용은, 하드웨어에 의해 실행될 때 하드웨어로 하여금 소프트웨어에 의해 나타낸 값들(즉, 트랜잭션의 중단 시에 소프트웨어에 응답하여 1의 값만큼 증분되는 중단 카운트에 대한 중단 메모리 위치)을 저장하게 하는 코드를 지칭한다는 것에 주목한다. 따라서, 용어 '소프트웨어 카운터'의 균등한 사용은 소프트웨어의 의해 지시된 카운트를 유지하기 위한 저장 매체와 같은 실재하는 장치의 변형을 지칭한다.

위에서는 시간량에 대한 또는 기간 동안의 충돌들을 참조하여 충돌 레이트가 논의되었다. 그러나, 레이트의 임의의 측정이 사용될 수 있다. 제1 예로서, 시간량은 일시적인 값(즉, 특정 또는 미리결정된 시간량)을 포함할 수 있다. 그러나, 용어 "시간량"의 사용은 또한 특정 이벤트들 간의 시간의 변화를 지칭할 수 있다. (특정 시간량을 사용하는) 제1 시나리오에서 측정 지속기간들은 주기적이고, (이벤트들 간의) 제2 시나리오에서 기간들은 달라질 수 있지만 변하는 것이 요구되지는 않는다는 것에 주목한다. 이벤트들은 동기식이거나(명령어에 얽매이거나 명령어에 응답함) 또는 비동기식(명령어에 직접 관련될 수 없음)일 수 있다. 예를 들어, 계산 시간 임계값이 미리 결정된다. 그리고 트랜잭션의 각 시작 시에, 현재 시간 기간이 임계값에 대해 검사된다. 현재 시간 기간이 임계값보다 작으면, 이전에 계산된 충돌률이 사용된다. 그러나, 현재 시간 기간이 임계값보다 크면, 충돌률이 재계산된다.

예시적인 예로서, 충돌 재계산의 기간이 1초라고 가정한다. 계산의 제1 기간은 실제로 1초에서 발생할 수 있다. 제1 트랜잭션(T1)의 실행 시에, 충돌률이 계산된다. 1초 임계값의 100ms 전에, 제2 트랜잭션(T2)이 실행된다. 여기서, 임계값이 초과되지 않았고, 그래서 이전에 계산된 충돌률이 사용된다. 그 후, 또 하나의 트랜잭션(T3)이 T1으로부터의 계산 후 1.5초까지 실행되지 않았다고 가정한다. 1초 임계값을 초과하는 기간의 결과로서, 새로운 충돌률이 계산된다. 본 예로부터 알 수 있는 바와 같이, 계산 기간들(시간량)은 항상 주기적이거나 동일하지는 않다(즉, 상기 예에서 계산에 대한 제1 지속기간은 1초였고, 제2 기간은 1초였다).

따라서, 충돌 레이트 결정을 위한 기간의 실제 측정에도 불구하고, 일 실시예에서 충돌 레이트는 충돌 모듈(310)에 의해 매 기간마다 결정된다. 대안적으로, 로우 데이터(raw data)(트랜잭션들 및 중단들)가 현재로 유지되고 충돌 레이트가 충돌 모듈(310)에 의해 요청에 따라 계산된다. 예를 들어, 시작 트랜잭션에 대한 호출이 이루어지면, 충돌 레이트가 시작 트랜잭션 호출에 응답하여 계산된다. 그러나, 모든 기간에서의 계산은 충돌 레이트가 용이하게 이용가능하게 되는 것을 허용하고, 이는 충돌률이 너무 높지 않으면 계산을 대기할 필요 없이 즉각적인 스케줄링을 잠재적으로 가능하게 한다.

충돌 레이트가 너무 높은지의 여부를 충돌 모듈(310)을 이용하여 결정하는 임의의 공지된 방법이 사용될 수 있다. 일 실시예에서, 충돌 모듈(310)은 충돌 레이트가 충돌 레이트 임계값보다 큰지 결정한다. 예를 들어, 충돌률이 사용되면, 충돌률은 충돌률 임계값과 비교된다. 충돌률은 통상 1 이하의 수(또는 변환되면 퍼센트)로 되기 때문에, 충돌 임계값은 마찬가지로 1 이하의 수, 퍼센트, 또는 다른 공지된 분수 또는 비율의 표현을 포함할 수 있다. 그 결과, 충돌률이 충돌 임계값보다 크면(또는 일부 실시예에서 같으면), 충돌 레이트는 '너무 높다'라고 생각된다. 알 수 있는 바와 같이, 용어 '너무 높다'는 임계값에 관한 것이다. 따라서, 정적 임계값에 대한 하나의 대안적인 실시예에서, 충돌 임계값은 런타임 동안에 동적으로 변경가능/조정가능하다. 임의의 공지된 효율/인자가 임계값의 조정을 기반으로 하는데 사용될 수 있다. 예를 들어, 스레드가 너무 많은 횟수 지연되었다면(기간에 대해 또는 연속하여), 임계값이 조정될 수 있다. 일 실시예에서, 조정의 목적은, 경쟁하는 또는 충돌하는 스레드들 간의 병행성은 없애지 않으면서, 충돌하는 스레드들을 지연시킴으로써 충돌들을 감소시키는 것이다.

일 실시예에서, 스레드 스케줄링 모듈(315)은 스레드(301)를 스케줄링하기 전에 스레드(302)가 실행되고 있는지 결정하고 스레드(301)와 스레드(302)의 충돌 레이트가 너무 높고 스레드(302)가 실행 중이라고 충돌 모듈(310)이 결정하는 것에 응답하여 스레드(301)의 스케줄링을 지연시키도록 적응된다. 예시적인 예로서, 스레드(302)가 트랜잭션을 시작하라는 호출을 하는 것을 가정한다. 이 시점에서, 스레드 스케줄링 모듈(315)은 충돌 모듈(310)과 함께 임의의 스레드가 스레드(301)와 충돌하는지 결정한다. 즉, 이들은 스레드(302) 등의 스레드와의 충돌 레이트가 충돌률보다 높은지를 결정한다. 여기서, 충돌 모듈(310)은 모든 기간의 충돌 레이트 계산에 비교를 행하고 결과들의 표현을 저장했을 수 있다. 예를 들어, 각각의 다른 스레드에 대응하는 스레드(301)에 대한 비트맵은 스레드(301)와 충돌하는(너무 높은 레이트를 갖는) 스레드들을 나타내기 위하여 충돌 값으로 업데이트될 수 있다. 대안적으로, 충돌 모듈(310)은 요구 시에 계산, 임계값 비교, 또는 양자를 수행할 수 있다.

어느 쪽이든, 스레드(302)에 대한 스레드(301)와의 충돌 레이트가 충돌 임계값을 넘었다고 가정하면, 스레드 스케줄링 모듈(315)은 충돌하는 스레드(스레드(302))가 현재 실행중인지를 결정한다. 대안적인 구현에서, 어느 스레드들이 실행 중이거나 또는 스케줄링되는지가 결정된다는 것에 주목한다. 그리고 그 후 이들 스레드들은 그들이 충돌하고 있는지를 결정하기 위해 검사된다. 구현의 선택은 모든 스레드 중 어느 것이 먼저 충돌하는지 또는 어느 스레드들이 먼저 실행 중인지를 결정하는 것이 더 빠를 것인지에 기초하여 가장 빠른 결정을 달성하기 위해 정적 또는 동적일 수 있다.

스레드가 실행 중인지를 결정하는 것은 임의의 공지된 방식으로 행해질 수 있다. 일 실시예에서, 스레드의 상태는 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합으로 유지될 수 있다. 스레드 스케줄링 모듈(315)은 이 정보를 이들 구조들의 임의의 것으로부터 모을 수 있다. 스레드 '실행'은 다수의 상이한 의미를 가질 수 있다. 그러나, 일 실시예에서, 스레드 실행은 관심 대상인 스레드 상에서 실행 중인 트랜잭션과의 데이터 충돌을 잠재적으로 야기할 수 있는 임의의 상태를 포함한다. 그러한 상태의 예들은 활동 중, 스케줄링될 준비가 된, 실행 중, 트랜잭션을 실행 중 등을 포함한다.

스레드(302)가 실행 중이고 또한 충돌하는 스레드라고 결정되면, 스레드 스케줄링 모듈(315)은 스레드(301)를 적응적으로 스케줄링한다. 일 실시예에서, 적응적 스케줄링은 명시된 시간량 또는 임의의 시간량, 또는 명시된 이벤트가 발생할 때까지(캐시 누락, 스레드(302)가 비활동으로 됨, 명시된 위치에의 액세스, 타이머 경과 등) 스레드(301)를 지연시키는 것을 포함한다. 용어 "스케줄링을 지연시킴"의 사용은, 일 실시예에서, 구체적으로 명령어, 스레드, 또는 동작(또는 지연 기간 동안 스케줄링하는 것을 생략)에 대한 스케줄링 프로세스의 실제 지연을 지칭하는 것임을 주목한다. 다른 실시예에서, 스케줄링의 지연은 도입된 지연에 응답하여 명령어, 스레드, 또는 동작의 스케줄링을 효과적으로 지연시키는, 파이프라인 어딘가에 도입된 지연을 지칭한다. 예를 들어, 스케줄링의 지연은 스레드의 컨텍스트 스위치가 스케줄링되는 것을 지연시키는 것을 포함할 수 있다. 스케줄링 프로세스가 직접 지연되는 것은 아니지만, 컨텍스트 스위치에서의 지연은 컨텍스트 스위치에서의 도입된 지연이 없었다면, 더 일찍 발생했을 수 있을 스레드로부터의 명령어들의 스케줄링을 지연시키는 것으로 효과적으로 번역된다.

일 실시예에서, 스레드 스케줄링 모듈(315)은 트랜잭셔널 메모리 라이브러리를 보유하는 저장 매체를 포함하며, 이 라이브러리는 실행될 때, 스레드(301)의 스레드(302)와의 충돌 레이트가 너무 높고 스레드(302)가 실행 중이라는 결정에 응답하여 특권을 가진, 제어 소프트웨어에 대한 애플리케이션 인터페이스로의 스레드(301)에 대한 호출을 지연시킨다. 예로서, 시작 트랜잭션 호출은, 실행될 때, 트랜잭셔널 메모리 라이브러리에 시작 트랜잭션 루틴/함수를 호출한다. 트랜잭셔널 메모리 라이브러리 코드는, 실행될 때, 전술한 바와 같이, 충돌 모듈(310)의 정보를 확인하여, 스레드(302)가 스레드(301)와 충돌하는지를 결정한다. 그리고 트랜잭셔널 메모리 런타임 스케줄러는, 스레드(302)가 실행 중이고 스레드(301)와 너무 자주 충돌한다는 결정에 응답하여, 소프트웨어(예컨대, 운영 체제, 하이퍼바이저, 커널 등)를 제어하기 위한 애플리케이션 프로그램 인터페이스(API)에 대한 스레드(301)로부터의 트랜잭션에 대한 호출을 지연시킨다. 이러한 시나리오에서, 트랜잭션 런타임 환경은 지연을 제공하고, 지연은 잠재적으로 OS 또는 하드웨어에 대한 임의의 변경을 포함하지 않는다. 즉, 적응적 스레드 스케줄링이 소프트웨어 또는 하드웨어를 제어하는 데 있어서도 구현될 수 있지만, 적응적 스케줄링의 효율은 OS 공급자들 또는 하드웨어 공급자들이 그들의 제품을 변경하는 것을 요구하지 않고, 트랜잭션 런타임 환경 그 자체에 의해 제공될 수 있다.

다른 실시예에서, 하드웨어는 스레드, 스레드로부터의 명령어, 동작 등의 스케줄링을 지연시키도록 구성된다. 제1 예로서, 하드웨어 스케줄러는, 충돌 모듈이 스레드(301)의 스레드(302)와의 충돌 레이트가 너무 높다고 결정하고 스레드 스케줄링 모듈(315)이 스레드(302)가 실행 중이라고 결정하는 것에 응답하여 스레드(301)로부터의 명령어를 스케줄링하는 것을 지연시키도록 구성된다. 여기서, 명령어의 실행 유닛으로의 디스패치는 시간량 동안 지연될 수 있다. 예를 들어, 트랜잭션의 시작이 지연되고, 지연 후에 시작될 때까지 스레드(302)와의 충돌로부터 중단될 수 없도록, 트랜잭션을 시작하라는 명령어 또는 동작이 지연된다. 그러나, 스레드(301)가 충돌할 명령어들 또는 동작들을 실행하는 것을 효과적으로 지연시키는, 파이프라인에서의 임의의 지연이 삽입될 수 있다.

일 예로서, 컨텍스트 스위치 로직은, 충돌 모듈(310)이 스레드(301)의 스레드(302)와의 충돌 레이트가 너무 높다고 결정하고 스레드 스케줄링 유닛(315)이 스레드(302)가 실행 중이라고 결정하는 것에 응답하여 스레드(302)의 스위치를 물리 스레드 유닛 내로 지연시키도록 구성된다. 여기서, 스레드(302)는 비활동적이다. 그리고, 물리 스레드 유닛 내로 스위칭되어야 할 때, 스레드(302)(경쟁 스레드)가 물리 스레드 유닛 내에서 활동적인지가 결정된다. 스레드(302)가 활동적이라면, 컨텍스트 스위치는 지연되고, 이는 필연적으로 시작 트랜잭션 명령어들과 같은 명령어들의 스케줄링을 지연시킨다.

그러나, 충돌들을 최소화하기 위한 적응적 스레드 스케줄링은 하드웨어만 또는 소프트웨어만으로 배타적으로 구현될 필요는 없다. 대신에, 하이브리드 구현이 사용될 수 있다. 예를 들어, 하드웨어 카운터들이 시간량에 대해 스레드(302)와의 충돌들로 인해 스레드(301)에서 중단된 다수의 트랜잭션들 및 시간량에 대해 스레드(301)에서 실행된 전체 수의 트랜잭션들을 추적하도록 구성된다. 실행될 때, 실행 로직으로 하여금 중단된 트랜잭션들의 수 및 카운터들에 보유된 트랜잭션들의 전체 수로부터 충돌률을 결정하게 하는 트랜잭셔널 런타임 코드를 포함하는 저장 매체가 있다. 추가로, 트랜잭셔널 런타임 코드는, 실행될 때, 스레드(301)의 스레드(302)와의 충돌 레이트가 너무 높다고 결정하고, 스레드 스케줄링 모듈이 스레드(302)가 실행 중이라고 결정하는 것에 응답하여, 특권을 가진 제어 소프트웨어에 대한 애플리케이션 인터페이스로의 호출을 지연시킨다.

도 4를 참조하면, 스레드 충돌들에 기초하여 스레드들을 적응적으로 스케줄링하도록 구성된 로직의 논리적 재현의 실시예가 도시된다. 일 실시예에서, 프로세서(400)는 하드웨어 트랜잭션들을 실행할 수 있다. 스레드들(401 및 402)은 캐시 메모리 등의 트랜잭셔널 메모리(410)에 대한 액세스를 공유한다. 그리고, 도 1 및 2를 참조하여 전술된 것과 같은 일관성 프로토콜과 함께 추적 메커니즘은 충돌들을 검출할 수 있고 트랜잭션들이 중단되게 할 수 있다.

여기서, 시작 트랜잭션 명령어(403)는 스레드(401)가 트랜잭션을 시작하도록 페치된다고 가정한다. 디코더들(405)은 명령어를 디코딩하고, 다른 파이프라인 로직(430)은 구체적으로 디코더(들)(405)를 갖는 그의 연산 코드(opcode)에 의한 명령어(403)의 식별에 기초하여 트랜잭션 명령어(403)를 시작하는 것에 응답하여 미리결정된 동작들을 수행한다. 트랜잭션 스레드(401 및 402)는 캐시 메모리(410) 등의 하드웨어에 의해 검출될 때 충돌 할 수 있다(즉, 기입 후 판독, 판독 후 기입, 또는 스레드들 간의 기입 후 기입). 그리고 스레드(401)의 트랜잭션은 중단될 수 있다.

전술한 바와 유사하게 그들의 이러한 트랜잭션들 및 중단들은 트랙킹된다. 일 실시예에서, 하드웨어 카운터들(415, 420)은 트랙킹 기간의 시작에서 리셋된다. 트랜잭션 카운트(415)는 시간 기간동안 스레드(401)에 의해 실행되는 각각의 트랜잭션에 대해 증가된다. 트랜잭션 카운터(415)는, 개시 트랜잭션 명령어(403)의 디코드, 종료 트랜잭션 명령어의 디코드, 이 명령어들 중 하나의 퇴거 등과 같이, 파이프라인의 임의의 스테이지에서 증가될 수 있다는 점을 주의해야된다. 유사하게, 스레드(401)의 트랜잭션의 중단이 시간 기간 동안 검출될 때마다 중단 카운트(420)는 증가된다. 예를 들면, 하드웨어가 스레드(401)에서 실행되는 트랜잭션에 대한 충돌을 검출할 때, 하드웨어 카운터(415)는 증가되도록 구성된다. 다른 실시예에서, 트랜잭션 카운터(415)는 다수의, 잠재적 경쟁 스레드들을 위해 복제된다. 결과적으로, 이러한 시나리오에서의 트랜잭션 카운터(415)는 스레드(401)와 스레드(402) 사이에서의 충돌/중단을 트랙킹하도록 전용된다. 따라서, 스레드(402) 외의 스레드 때문에 스레드(401)의 트랜잭션의 중단이 있다면, 이러한 경우의 카운터(415)는 증가되지 않는다. 카운터들(415, 420)이 카운터 대신에 누적기로도 구현될 수 있다는 점에 주의하자. 카운트를 직접적으로 사용하는 것 대신에, 계산 기간의 개시와 계산 기간의 종료에서의 카운트 사이에서 델타가 이용된다(예를 들면, 실행되는 10개의 트랜잭션의 트랜잭션 카운트를 사용하는 대신에, 계산 기간의 종료에서 30개의 트랜잭션의 누적기 카운트에서 기간의 시작에서 20의 누적기 카운트를 빼면 동일한 실행되는 10개의 트랜잭션이 된다).

충돌 로직(425)은 시간량 동안 제1 스레드(401) 및 스레드(402)에 대한 충돌 메트릭을 결정하도록 구성된다. 예를 들면, 충돌 메트릭은 스레드(402)에 대한 스레드(401)의 충돌률을 포함한다. 여기서, 충돌 로직은 트랜잭셔널 충돌률을 결정하도록 구성된다. 전술한 바와 같이, 일 실시예에서, 충돌률은 스레드(402)와의 충돌에 기초하여 스레드(401)에서 중단된 트랜잭션들의 수(카운터 값(420))를 시간량 동안 스레드(401)에서 실행된 트랜잭션들의 총 수(카운터 값(415))로 나눈 것을 포함한다. 기간 또는 시간량은 개시 트랜잭션 명령어의 이전 실행 및 개시 트랜잭션 명령어의 현재 실행과 같은, 시간 기간의 각각의 사이드 상에 배치된 이벤트들에 의해 정의될 수 있는 임의의 시간량을 포함할 수 있다는 점을 주의하자.

스레드(402)가 현재 구동, 실행, 및/또는 활성이고 충돌 메트릭이 충돌 임계값보다 클 때 스레드(401)로부터 스케줄 요청이 수신되면, 스케줄러 로직(440)은 실행 유닛들(445) 상의 실행을 위한 스레드(401)로부터 또는 그의 스케줄링을 지연시키도록 구성된다. 예를 들면, 충돌률이 충돌률 임계값보다 높은 동안, 하드웨어 스케줄러(440)는 개시 트랜잭션 명령어(403)가 스케줄링을 위해 사용 가능하고 스레드(402)가 실행을 위해 현재 활성인 것에 응답하여 스레드(401)로부터의 개시 트랜잭션 명령어(403)를 스케줄링하는 것을 지연시킨다. 전술한 논의로부터 일부 실시예들에서 스케줄러 로직(440)이 지연 시간 프레임에 걸쳐 지연 임계값보다 많은 실행에 대해 스레드(401)의 스케줄링을 지연시키는 것에 응답하여 충돌 스레드가 동적으로 증가된다는 것을 주의하자. 여기서, 충돌률 측정보다 긴 시간 기간은 얼마나 많은 스레드(401)가 지연되는지 관찰하는 데에 이용될 수 있다. 이러한 예시에서, 충돌률 임계값은 스레드(401)가 지연되는 시간을 증가 또는 감소시키도록 조정될 수 있다. 전술한 바와 같이, 스레드(401)의 지연은 충돌하는/경쟁하는 스레드들을 동시에 의도적으로 스케줄링하여 그들이 실제로 여전히 충돌하고 있는지 보장하기 위해 의도적으로 무시될 수 있다.

도 5로 옮겨가서, 현재 구동되는 스레드들과의 충돌에 기초하여 스레드의 스케줄링을 지연시키는 방법에 대한 흐름도의 실시예가 도시된다. 도 5-7의 흐름도에 대한 플로우들은 플로우들의 배열된 순서로 실질적으로 순차적인(serial) 방식으로 도시되었다. 그러나, 이러한 플로우들의 순차성뿐 아니라 도시된 순서도 필수사항은 아니다. 예를 들면, 도 5를 참조하여, 설계 구현에 기초하여, 설계자는 스레드가 현재 구동중인지 결정(플로우 510)하기 전에 플로우(515)(스레드에 대한 트랜잭션의 수가 너무 많은가?)를 수행하기를 선택할 수 있다. 또한, 플로우들(605 및 610)은 선형 또는 순차적인 방식으로 도시된다. 그러나, 실행되거나 중단되는 트랜잭션들을 결정하는 것은 동일한 시간 기간 동안 병렬적으로 종종 수행된다. 부가적으로, 도시되는 플로우들 중 임의의 것은 하드웨어, 소프트웨어, 펌웨어, 또는 그들의 조합 내에서 수행될 수 있다. 게다가, 수행될 때, 하나 이상의 명령어들 또는 동작들의 형식의 임의의 프로그램 코드는 머신으로 하여금 도시되고 후술되는 플로우들을 수행하게 할 수 있다.

플로우(505)에서, 제2 스레드와의 충돌때문에 제1 스레드에서 시간의 기간 동안 중단되는 트랜잭션들의 제1 수가 결정된다. 제1 예시로서, 제2 스레드에 대한 제1 스레드를 위한 중단 카운트는 트랜잭션의 중단에 응답하여 (소프트웨어, 하드웨어, 펌웨어, 또는 그들의 조합에 의해) 증가되고, 이는 제1 스레드의 트랜잭션과 제2 스레드에 의한 액세스 사이에서의 충돌에 응답하는 것이다.

플로우(510)에서, 제2 스레드가 구동되는 지가 결정된다. 전술한 바와 같이, 이는 하드웨어에 대한 소프트웨어 질의, 스레드에 대한 상태의 하드웨어 체킹, 스레드가 스케줄링을 위한 아웃스탠딩 명령어들/동작들을 갖는지 또는 퇴거되지 않았는지 보기 위한 체크, 스레드의 소프트웨어 유지 상태, 또는 그들의 조합을 통해 행해질 수 있다. 스레드가 현재 구동되고 있는지 결정하는 것이 플로우(515) 전에 수행되는 경우, 시스템은 (즉, 관심의 스레드와 잠재적으로 충돌할 수 있는 모든 스케줄링될 스레드들) 현재의 활성인 또는 구동되는 스레드 세트를 필수적으로 결정한다.

스레드 세트의 플로우(515)에서, 스레드 세트에서 그들 스레드들의 각각에 대한 충돌 때문에 중단되는 트랜잭션들의 수가 너무 높은지의 여부가 결정된다(즉, 중단 임계값보다 높음). 본원의 논의가 특정 스레드들 사이에서의 중단들을 참조로 하였지만, 중단들의 수는 어떠한 스레드가 충돌을 유발하는 지와 관련되지 않은 스레드에서의 중단들을 포함할 수 있다. 또는 중단들은 프로세서의 특정 코어 상에 실행되는 스레드들의 그룹과 같은, 스레드들의 그룹에 대하여 결정될 수 있다.

각각의 플로우(510 또는 515)에서, 잠재적 충돌 스레드가 구동되지 않거나 충돌 스레드에 부여되는 중단들의 수가 임계값보다 크지 않으면, 제1 스레드에 대한 스케줄링 또는 실행은 정상적으로 계속된다. 그러나, 기간들 동안 또는 가장 최근 기간 동안 평균화되는 충돌률에 의해 지시되는 바와 같이, 제2 스레드가 구동되고 너무 많은 중단들을 유발한다면, 제1 스레드의 스케줄링이 플로우(520)에서 지연된다. 일 실시예에서, 제1 스레드의 스케줄링을 지연시키는 것은 제1 스레드 내의 트랜잭션의 개시에 응답하여 제어 소프트웨어 스케줄러에 의해 수행된다. 이 예시에서, 제1 스레드의 스케줄링을 지연시키는 것은, 제1 스레드 내의 트랜잭션의 개시에 응답하여 제어 소프트웨어에 대해 API(Application Program Interface)와 같은 애플리케이션 인터페이스로의 호출을 지연시키는 것을 포함한다. 그러나, 본원에 기재된 방법들 및 장치들 중 임의의 것이 중단들의 제노포빅 뷰(xenophobic view); 현재의, 가장 최근의 충돌률; 평균화되거나 가중화된 충돌률; 또는 스레드들 사이에서의 충돌을 결정하는 다른 공지의 방법에 기초하여 스레드를 지연시키기 위해 이용될 수 있다.

도 6을 참조하여, 스레드 충돌들에 기초하여 스레드들을 적응적으로 스케줄링하는 방법에 대한 흐름도의 실시예가 도시된다. 플로우(605)에서 시간 기간 동안 제1 스레드에서 실행되는 트랜잭션들의 제1 수가 결정된다. 그리고 플로우(610)에서, 제2 스레드의 충돌들에 응답하여 중단되는 시간 기간 동안 실행되는 트랜잭션들의 제1 수의 트랜잭션들의 제2 수가 결정된다. 이들 '카운트'는 하드웨어 자체, 소프트웨어(예를 들면, STM(Software Transactional Memory) 런타임 코드), 펌웨어, 또는 그들의 조합의 지시에 하드웨어(카운터들, 레지스터들 등)에서 유지된다.

플로우(615)에서, 트랜잭션들의 제1 수(605) 및 트랜잭션들의 제2 수(610)에 기초하여 충돌률이 결정된다. 예를 들면, 충돌률은 M/N을 포함하는 공식으로부터 결정되고, 여기서 N은 트랜잭션들의 제1 수를 포함하고 M은 트랜잭션들의 제2 수를 포함한다. 다른 실시예에서, 충돌률 공식은 P*M/N + (1-p)*X/Y 를 포함하고, 여기서 N은 트랜잭션들의 제1 수를 포함하고, M은 트랜잭션들의 제2 수를 포함하고, Y는 이전 시간 기간 동안 실행되는 제1 스레드에서의 트랜잭션의 제3 수를 포함하고, X는 이전 시간의 기간 동안 중단되는 제1 스레드의 트랜잭션들의 제4 수를 포함하고, p는 0 이상 1 이하의 상수를 포함한다. 전술한 바와 같이, P는 정적 상수 또는 시간에 따라 변화하는 동적 상수일 수 있다.

플로우(620)에서, 충돌률이 충돌 임계값보다 큰지 결정된다. 그리고 그렇다면, 플로우(625)에서 제1 스레드의 스케줄링이 지연된다. 그 결과, 현재 구동되는 제2 스레드 및 충돌률이 충돌 임계값보다 큰 것에 응답하여 제1 스레드의 스케줄링이 지연된다고 말할 수 있다. 제1 예시로서, 스레드의 스케줄링을 지연하는 것은 제1 스레드로의 리턴을 지연시키는 것을 포함한다. 다른 도시적인 예로서, 스레드의 스케줄링을 지연시키는 것은 제1 스레드에 대한 애플리케이션 인터페이스 호출을 지연시키는 것을 포함한다. 또 다른 예시로서, 스레드의 스케줄링을 지연시키는 것은 지연을 프로세서 파이프라인으로 도입하는 것 또는 제1 스레드에 대해 콘텍스트 스위치를 지연시키는 것을 포함한다.

도 7에 대하여, 스레드 충돌들에 기초하여 스레드들을 적응적으로 스케줄링하는 방법에 대한 흐름도의 실시예가 도시된다. 플로우(705)에서, 트랜잭션이 시작 트랜잭션 명령어의 실행을 통해서와 같이, 제1 스레드(T1)에서 개시된다. 플로우(710)에서, 마지막 충돌률 계산으로부터의 시간이 결정된다. 시간이 임계값보다 크다면, 플로우들(715 및 720)에서 충돌률이 계산된다. 이러한 예시의 충돌률 계산에 대한 시간량 또는 (연속적 기간을 포함하는) 기간들은 동일하지 않을 수 있는 것을 주의하자. 대신에, 마지막 계산으로부터의 시간이 할당된 시간량(임계값)을 초과하는 경우, 트랜잭션들의 시작에서 새로운 충돌률들이 계산된다.

플로우(715)에서 현재의 충돌률이 결정된다. 예를 들어, T2와 같은 다른 스레드 때문에 T1에서 중단된 트랜잭션들의 수는 마지막 충돌률 계산으로부터 T1에서 실행되는 트랜잭션들의 총 수에 의해 나눠진다. 그 후, 평균화되거나 가중화된 충돌률이 아래에 재복사된 수학식 1을 통해 플로우(720)에서 결정된다.

[수학식 1]

(플로우(720)로부터 수신된) 평균화된 충돌률이 재계산되거나 (흐름(710)으로부터 직접 수신된) 계산 임계값을 초과하지 않은 과거에서 이전에 계산되었던 현재의 평균화된 충돌률이 일정 시간동안 계산되면, T2가 플로우(725)에서 구동되는지가 결정된다. T2가 구동되지 않으면, 플로우(727)에서 T1이 정상적으로 스케줄링된다. 그러나, T2가 구동되면, 플로우(730)에서 평균화된 충돌률이 충돌률 임계값보다 큰지 결정된다. 충돌률이 임계값을 초과하지 않는다면, 플로우(727)에서 T1이 정상적으로 스케줄링된다. 그러나, 충동률이 임계값보다 크다면, 플로우(735)에서 제1 스레드가 일정 시간동안 지연된다.

그러므로, 상기한 바와 같이, 스레드들은 다른 스레드들과의 충돌들에 기초하여 적응적으로 스케줄링되고, 이는 동시적인 실행 이점을 유지하면서 스레드들 간의 충돌들을 잠재적으로 최소화한다. 게다가, 스레드들의 지연은 특정한, 개별 스레드들과의 충돌에 기초할 수 있다. 관심 스레드가 스케줄링 되고 관심 스레드와 너무 자주 충돌하지 않는 스레드들만이 구동될 때, 관심 스레드는 정상적으로 스케줄링될 수 있다. 게다가, 특정한 경쟁 스레드들 사이에서조차, 그들은 스레드들이 여전히 충돌하는지 재-체크하도록 의도적이고 동시적으로 실행되기 위해 주기적으로 스케줄링될 수 있다.

본원에서 사용되는 모듈은 임의의 하드웨어, 소프트웨어, 펌웨어, 또는 그들의 조합을 지칭한다. 종종 개별적으로 도시된 모듈 경계들은 공통적으로 변화하고 잠재적으로 오버랩된다. 예를 들어, 제1 및 제2 모듈은 하드웨어, 소프트웨어, 펌웨어, 또는 그들의 조합을 공유할 수 있고, 일부 독립적인 하드웨어, 소프트웨어, 또는 펌웨어를 잠재적으로 유지할 수 있다. 일 실시예에서, 로직이라는 용어의 사용은 트랜지스터, 레지스터, 또는 프로그램가능한 로직 디바이스와 같은 다른 하드웨어와 같은 하드웨어를 포함한다. 그러나, 다른 실시예에서, 로직은 펌웨어 또는 마이크로-코드와 같은 하드웨어로 통합된 소프트웨어 또는 코드를 또한 포함한다.

본원에서 사용되는 값은 수치, 상태, 논리적 상태, 또는 이진 논리적 상태의 임의의 공지의 표시를 포함한다. 종종, 로직 레벨들의 사용, 로직 값들, 또는 로직 값들은 1 및 0으로 지칭되고, 이는 단순히 이진 로직 상태들을 나타낸다. 예를 들면, 1은 하이 로직 레벨을 가리키고 0은 로우 로직 레벨을 가리킨다. 일 실시예에서, 트랜지스터 또는 플래시 셀과 같은 저장소 셀은 단일 논리적 값 또는 복수의 논리적 값을 유지할 수 있다. 그러나, 컴퓨터 시스템들의 값들의 다른 표시들이 사용된다. 예를 들어 십진수 10은 이진수 값 1010 및 16진수 값 A로 나타내질 수도 있다. 그러므로, 값은 컴퓨터 시스템에서 유지될 수 있는 정보의 임의의 표현을 포함한다.

게다가, 상태들은 값들 또는 값들의 일부를 나타낼 수 있다. 예로서, 논리적 1과 같은 제1 값은 디폴트 또는 초기 상태를 나타낼 수 있고, 논리적 0와 같은 제2 값은 논-디폴트 상태를 나타낼 수 있다. 또한, 리셋 및 세트라는 용어는, 일 실시예에서, 디폴트 및 업데이트된 값 또는 상태를 각각이 가리킨다. 예를 들어, 디폴트 값은 높은 논리적 값, 즉, 리셋을 포함하고, 업데이트된 값은 낮은 논리적 값, 즉, 세트를 잠재적으로 포함한다. 값들의 조합은 임의의 수의 상태들을 나타내도록 이용될 수 있다.

전술된 방법들, 하드웨어, 소프트웨어, 펌웨어 또는 코드 세트들의 실시예들은 프로세싱 요소에 의해 실행될 수 있는 머신-액세스 가능한, 머신 판독가능한, 컴퓨터 액세스가능한, 또는 컴퓨터 판독가능한 대체 상에 저장된 명령어들 또는 코드에 의해 구현될 수 있다. 비-일시적 머신-액세스가능한/판독가능한 매체는 컴퓨터 또는 전자 시스템과 같은, 머신에 의해 판독가능한 형태로 정보를 제공하는(즉, 저장 및/또는 전송하는) 임의의 메커니즘을 포함한다. 예를 들어, 비-일시적 머신-액세스가능한 매체는 정적 RAM(SRAM) 또는 동적 RAM(DRAM)과 같은 랜덤-액세스 메모리(RAM); ROM; 자기 또는 광 저장 매체; 플래시 메모리 디바이스; 전기적 저장 디바이스; 광 저장 디바이스; 음향 저장 디바이스; 일시적인 (전파되는) 신호들(예를 들면, 반송파, 적외 신호, 디지털 신호)로부터 수신된 정보를 유지하기 위한 저장 디바이스들의 다른 형식; 등을 포함하고, 이는 그들로부터 정보를 수신할 수 있는 비-일시적 매체들로부터 구별된다.

본원에서 "일 실시예" 또는 "실시예"에 대한 지칭은 실시예와 연관되어 기재되는 특정한 피처, 구조체, 또는 특징이 본원 발명의 적어도 일 실시예에 포함된다는 것을 의미한다. 따라서, 본원 명세서에서 다양한 위치에서의 "일 실시예에서" 또는 "실시예에서"라는 구절의 등장은 반드시 동일한 실시예를 가리키는 것은 아니다. 또한, 특정한 피처들, 구조체들, 또는 특징들은 하나 이상의 실시예들에서 임의의 적절한 방식으로 조합될 수 있다.

상기의 명세서에서, 구체적인 설명이 특정한 예시적인 실시예들을 참고로 하여 주어졌다. 그러나, 다양한 수정 및 변경이 청구범위에 기재된 바와 같이 본원 발명의 더 넓은 사상 및 범위로부터 벗어나지 않고 행해질 수 있음이 명백할 것이다. 따라서, 명세서 및 도면들은 제한적인 방식보다는 예시적인 방식으로 간주되어야 한다. 또한, 실시예의 전술한 사용 및 다른 예시적인 언어가 반드시 동일한 실시예 또는 동일한 예시를 가리키지는 않지만, 상이한 그리고 구별되는 실시예들 뿐 아니라 잠재적으로 동일한 실시예를 가리킬 수도 있다.

Claims (29)

1. 제1 스레드의 제2 스레드와의 충돌 레이트(conflict rate)가 너무 높다고 결정하도록 적응된 충돌 모듈; 및
   스레드 스케줄링 모듈을 포함하고,
   상기 스레드 스케줄링 모듈은,
   상기 제1 스레드를 스케줄링하기 전에 상기 제2 스레드가 실행중인지 여부를 결정하고,
   상기 충돌 모듈이 상기 제1 스레드의 상기 제2 스레드와의 충돌 레이트가 너무 높다고 결정하고, 상기 스레드 스케줄링 모듈이 상기 제2 스레드가 실행중이라고 결정하는 것에 응답하여, 상기 제1 스레드의 스케줄링을 지연하도록 적응되는 장치.
2. 제1항에 있어서
   상기 제1 스레드의 상기 제2 스레드와의 충돌 레이트는, 시간량에 걸친 상기 제2 스레드와의 충돌들로 인해 상기 제1 스레드에서 중단된 트랜잭션들의 수를 상기 시간량에 걸쳐 상기 제1 스레드에서 실행된 트랜잭션들의 전체 수로 나눈 충돌률(conflict ratio)을 포함하는 장치.
3. 제2항에 있어서,
   상기 시간량은 미리결정된 시간량, 동기적 이벤트들 사이의 시간량, 비동기적 이벤트들 사이의 시간량, 및 미리결정된 이벤트들 사이의 시간량으로 구성되는 그룹으로부터 선택된 시간 기간을 포함하는 장치.
4. 제2항에 있어서,
   상기 충돌 모듈은 소프트웨어 카운터, 및 충돌 핸들러 코드(conflict handler code)를 보유하는 저장 매체를 포함하고, 상기 충돌 핸들러 코드는, 실행될 때, 상기 소프트웨어 카운터로 하여금 상기 시간량에 걸친 상기 제2 스레드와의 충돌들로 인해 상기 제1 스레드에서 중단된 트랜잭션들의 수를 추적하도록 하는 장치.
5. 제2항에 있어서,
   이전의 충돌률은 이전의 시간량 동안 상기 제1 스레드에서의 트랜잭션들의 이전의 수에 대한, 상기 이전의 시간량 동안 상기 제2 스레드와의 충돌들로 인해 상기 제1 스레드에서 중단된 트랜잭션들의 이전의 수를 포함하고, 상기 충돌 레이트는 "P * 충돌률 + (1-P) * 이전의 충돌률"을 더 포함하고, 여기서 P는 0 이상 및 1 이하의 상수인 장치.
6. 제5항에 있어서,
   P는 상기 제1 스레드의 스케줄링이 지연되는 횟수에 기초하여 런타임 동안 동적으로 조절가능한 장치.
7. 제2항에 있어서,
   상기 제1 스레드의 제2 스레드와의 충돌 레이트가 너무 높다고 결정하도록 적응된 충돌 모듈은, 상기 충돌률이 충돌률 임계값보다 크다고 결정하도록 적응되는 충돌 모듈을 포함하는 장치.
8. 제7항에 있어서,
   상기 충돌률 임계값은 런타임 동안 동적으로 조절가능한 장치.
9. 제1항에 있어서,
   상기 충돌 모듈이 상기 제1 스레드의 상기 제2 스레드와의 충돌 레이트가 너무 높다고 결정하고, 상기 스레드 스케줄링 모듈이 상기 제2 스레드가 실행중이라고 결정하는 것에 응답하여, 상기 제1 스레드의 스케줄링을 지연하도록 적응되는 상기 스레드 스케줄링 모듈은, 실행될 때, 상기 제1 스레드의 상기 제2 스레드와의 충돌 레이트가 너무 높다고 결정하고, 상기 스레드 스케줄링 모듈이 상기 제2 스레드가 실행중이라고 결정하는 것에 응답하여, 특권을 갖는(privileged) 제어 소프트웨어에 대한 애플리케이션 인터페이스에 대한 호출을 지연하는 트랜잭셔널 메모리 라이브러리(transactional memory library)를 보유하는 저장 매체를 포함하는 스레드 스케줄링 모듈을 포함하는 장치.
10. 제1항에 있어서,
    상기 충돌 모듈이 상기 제1 스레드의 상기 제2 스레드와의 충돌 레이트가 너무 높다고 결정하고, 상기 스레드 스케줄링 모듈이 상기 제2 스레드가 실행중이라고 결정하는 것에 응답하여, 상기 제1 스레드의 스케줄링을 지연하도록 적응되는 상기 스레드 스케줄링 모듈은, 상기 충돌 모듈이 상기 제1 스레드의 상기 제2 스레드와의 충돌 레이트가 너무 높다고 결정하고, 상기 스레드 스케줄링 모듈이 상기 제2 스레드가 실행중이라고 결정하는 것에 응답하여, 상기 제1 스레드로부터의 명령어의 스케줄링을 지연하도록 구성된 하드웨어 스케줄러를 포함하는 장치.
11. 제1항에 있어서,
    상기 충돌 모듈이 상기 제1 스레드의 상기 제2 스레드와의 충돌 레이트가 너무 높다고 결정하고, 상기 스레드 스케줄링 모듈이 상기 제2 스레드가 실행중이라고 결정하는 것에 응답하여, 상기 제1 스레드의 스케줄링을 지연하도록 적응되는 상기 스레드 스케줄링 모듈은, 상기 충돌 모듈이 상기 제1 스레드의 상기 제2 스레드와의 충돌 레이트가 너무 높다고 결정하고, 상기 스레드 스케줄링 모듈이 상기 제2 스레드가 실행중이라고 결정하는 것에 응답하여, 상기 제1 스레드의 물리적 스레드 유닛으로의 스위치를 지연하도록 구성된 컨텍스트 스위치 로직(context switch logic)을 포함하는 장치.
12. 제2항에 있어서,
    상기 제1 스레드의 상기 제2 스레드와의 충돌 레이트가 너무 높다고 결정하도록 적응된 상기 충돌 모듈은, 상기 시간량에 걸친 상기 제2 스레드와의 충돌들로 인해 상기 제1 스레드에서 중단된 트랜잭션들의 수 및 상기 시간량에 걸쳐 상기 제1 스레드에서 실행된 트랜잭션들의 전체 수를 추적하도록 구성된 하드웨어 카운터들과, 실행될 때, 실행 로직으로 하여금 중단된 상기 트랜잭션들의 수 및 상기 트랜잭션들의 전체 수로부터 상기 충돌률을 결정하도록 하는 트랜잭셔널 런타임 코드(transactional runtime code)를 포함하는 저장 매체를 포함하고, 상기 스레드 스케줄링 모듈은, 실행될 때, 상기 제1 스레드의 상기 제2 스레드와의 충돌 레이트가 너무 높다고 결정하고, 상기 스레드 스케줄링 모듈이 상기 제2 스레드가 실행중이라고 결정하는 것에 응답하여, 특권을 갖는 제어 소프트웨어에 대한 애플리케이션 인터페이스에 대한 호출을 지연하는 상기 트랜잭셔널 런타임 코드를 포함하는 상기 저장 매체를 포함하는 장치.
13. 시간량에 걸친 제1 스레드에 대한 제2 스레드와의 충돌 매트릭(conflict metric)을 결정하도록 구성된 충돌 로직; 및
    상기 제2 스레드가 현재 실행중이고, 상기 충돌 매트릭이 충돌 임계값보다 클 때, 상기 제1 스레드를 스케줄링하라는 요청에 응답하여, 실행을 위해 상기 제1 스레드를 스케줄링하는 것을 지연하도록 구성된 스케줄러 로직을 포함하는 장치.
14. 제13항에 있어서,
    시간량에 걸친 제1 스레드에 대한 제2 스레드와의 충돌 매트릭을 결정하도록 구성된 충돌 로직은, 상기 시간량에 걸친 제1 스레드에 대한 제2 스레드와의 트랜잭셔널 충돌률을 결정하도록 구성되는 상기 충돌 로직을 포함하고, 상기 충돌률은 상기 시간량에 걸쳐 상기 제1 스레드에서 실행된 트랜잭션들의 전체 수에 대한 상기 제2 스레드와의 충돌들에 기초하여 중단된 상기 제1 스레드에서의 트랜잭션들의 수를 포함하는 장치.
15. 제14항에 있어서,
    상기 충돌 로직은 상기 제1 스레드에서 중단된 상기 트랜잭션의 수의 상기 제1 스레드에서의 트랜잭션의 중단에 응답하여 증가되도록 구성된 제1 하드웨어 카운터, 및 상기 제1 스레드에서 실행된 상기 트랜잭션들의 전체 수의 상기 제1 스레드에서의 트랜잭션을 마주치는 것에 응답하여 증가되도록 구성된 제2 하드웨어 카운터를 포함하는 장치.
16. 제13항에 있어서,
    상기 제2 스레드가 현재 실행중이고, 상기 충돌 매트릭이 충돌 임계값보다 클 때, 상기 제1 스레드를 스케줄링하라는 요청에 응답하여, 실행을 위해 상기 제1 스레드를 스케줄링하는 것을 지연하도록 구성된 스케줄러 로직은, 시작 트랜잭션 명령어가 스케줄링을 위해 이용가능하고, 상기 제2 스레드가 실행을 위해 현재 활성인 것에 응답하여, 상기 제1 스레드로부터의 상기 시작 트랜잭션 명령어를 스케줄링하는 것을 지연하는 하드웨어 스케줄러를 포함하는 장치.
17. 제13항에 있어서,
    상기 충돌 임계값은 상기 스케줄러 로직이 실행을 위한 상기 제1 스레드의 스케줄링을 지연 시간 프레임에 걸쳐 지연 임계값보다 더 지연하는 것에 응답하여 동적으로 증가되는 장치.
18. 코드를 포함하는 비일시적 머신 판독가능 매체로서,
    상기 코드는, 머신에 의해 실행될 때, 상기 머신으로 하여금,
    제2 스레드와의 충돌들로 인해 시간 기간에 걸쳐 중단된 제1 스레드에서의 트랜잭션들의 제1 수를 결정하는 동작; 및
    시간 기간에 걸쳐 중단된 상기 제1 스레드에서의 상기 트랜잭션들의 제1 수에 기초해서 상기 제2 스레드가 현재 실행중일 때 상기 제1 스레드 내의 트랜잭션의 시작에 응답하여 제어 소프트웨어 스케줄러로 상기 제1 스레드의 스케줄링을 지연하는 동작을 수행하도록 하는 비일시적 머신 판독가능 매체.
19. 제18항에 있어서,
    제2 스레드와의 충돌들로 인해 시간 기간에 걸쳐 중단된 제1 스레드에서의 트랜잭션들의 제1 수를 결정하는 것은, 상기 제1 스레드의 트랜잭션과 상기 제2 스레드에 의한 액세스 사이의 충돌에 응답한 상기 제1 트랜잭션의 중단에 응답하여, 상기 제2 스레드에 관한 제1 스레드에 대한 중단 카운트를 증가시키는 것을 포함하는 비일시적 머신 판독가능 매체.
20. 제18항에 있어서,
    상기 시간 기간에 걸쳐 중단된 상기 제1 스레드에서의 상기 트랜잭션들의 제1 수에 기초해서 상기 제2 스레드가 현재 실행중일 때 상기 제1 스레드 내의 트랜잭션의 시작에 응답하여 제어 소프트웨어 스케줄러로 상기 제1 스레드의 스케줄링을 지연하는 것은, 상기 시간 기간에 걸쳐 중단된 상기 제1 스레드에서의 상기 트랜잭션들의 제1 수에 기초해서 상기 제2 스레드가 현재 실행중일 때 상기 제1 스레드 내의 상기 트랜잭션의 시작에 응답하여 상기 제어 소프트웨어에 대한 애플리케이션 인터페이스에 대한 호출을 지연하는 것을 포함하는 비일시적 머신 판독가능 매체.
21. 제20항에 있어서,
    상기 시간 기간에 걸쳐 중단된 상기 제1 스레드에서의 상기 트랜잭션들의 제1 수에 기초해서 상기 제2 스레드가 현재 실행중일 때 상기 제1 스레드 내의 트랜잭션의 시작에 응답하여 제어 소프트웨어 스케줄러로 상기 제1 스레드의 스케줄링을 지연하는 것은, 상기 제2 스레드가 현재 실행중이고, 상기 시간 기간에 걸쳐 중단된 상기 제1 스레드에서의 상기 트랜잭션들의 제1 수가 상기 시간 기간에 걸친 중단 임계값보다 클 때에 상기 제1 스레드 내의 상기 트랜잭션의 시작에 응답하여, 상기 제어 소프트웨어에 대한 상기 애플리케이션 인터페이스에 대한 호출을 지연하는 것을 더 포함하는 비일시적 머신 판독가능 매체.
22. 제20항에 있어서,
    상기 시간 기간에 걸쳐 중단된 상기 제1 스레드에서의 상기 트랜잭션들의 제1 수에 기초해서 상기 제2 스레드가 현재 실행중일 때 상기 제1 스레드 내의 트랜잭션의 시작에 응답하여 제어 소프트웨어 스케줄러로 상기 제1 스레드의 스케줄링을 지연하는 것은, 상기 제2 스레드가 현재 실행중이고, 상기 시간 기간에 걸쳐 중단된 상기 제1 스레드에서의 상기 트랜잭션들의 제1 수를 상기 시간 기간에 걸쳐 실행된 상기 제1 스레드로부터의 트랜잭션들의 전체 수로 나눈 것이 충돌률 임계값보다 클 때에 상기 제1 스레드 내의 상기 트랜잭션의 시작에 응답하여, 상기 제어 소프트웨어에 대한 상기 애플리케이션 인터페이스에 대한 호출을 지연하는 것을 더 포함하는 비일시적 머신 판독가능 매체.
23. 시간 기간에 걸쳐 실행된 제1 스레드에서의 트랜잭션들의 제1 수를 결정하는 단계;
    제2 스레드와의 충돌들에 응답하여 중단되는 상기 시간 기간에 걸쳐 실행된 상기 트랜잭션들의 제1 수에 대한 트랜잭션들의 제2 수를 결정하는 단계;
    상기 트랜잭션들의 제1 수 및 상기 트랜잭션들의 제2 수에 기초하여 충돌률을 결정하는 단계; 및
    상기 제2 스레드가 현재 실행중이고, 상기 충돌률이 충돌 임계값을 초과하는 것에 응답하여 상기 제1 스레드의 스케줄링을 지연하는 단계를 포함하는 방법.
24. 제23항에 있어서,
    시간 기간에 걸쳐 실행된 제1 스레드에서의 트랜잭션들의 제1 수를 결정하는 단계 및 제2 스레드와의 충돌들에 응답하여 중단되는 상기 시간 기간에 걸쳐 실행된 상기 트랜잭션들의 제1 수에 대한 트랜잭션들의 제2 수를 결정하는 단계는, STM(Software Transactional Memory) 런타임 코드의 실행에 응답하여 수행되는 방법.
25. 제23항에 있어서,
    시간 기간에 걸쳐 실행된 제1 스레드에서의 트랜잭션들의 제1 수를 결정하는 단계 및 제2 스레드와의 충돌들에 응답하여 중단되는 상기 시간 기간에 걸쳐 실행된 상기 트랜잭션들의 제1 수에 대한 트랜잭션들의 제2 수를 결정하는 단계는 하드웨어에서 수행되는 방법.
26. 제23항에 있어서,
    상기 트랜잭션들의 제1 수 및 상기 트랜잭션들의 제2 수에 기초하여 충돌률을 결정하는 단계는 M/N을 포함하는 공식으로부터 상기 충돌률을 결정 - 여기서, N은 상기 트랜잭션들의 제1 수를 포함하고, M은 상기 트랜잭션들의 제2 수를 포함함 - 하는 단계를 포함하는 방법.
27. 제23항에 있어서,
    상기 트랜잭션들의 제1 수 및 상기 트랜잭션들의 제2 수에 기초하여 충돌률을 결정하는 단계는 P * M/N + (1-p) * X/Y를 포함하는 공식으로부터 상기 충돌률을 결정 - 여기서, N은 상기 트랜잭션들의 제1 수를 포함하고, M은 상기 트랜잭션들의 제2 수를 포함하고, Y는 이전의 시간 기간에 걸쳐 실행된 상기 제1 스레드에서의 트랜잭션들의 제3 수를 포함하고, X는 상기 이전의 시간 기간 동안 중단된 상기 제1 스레드에서의 트랜잭션들의 제4 수를 포함하고, p는 0 이상 및 1 이하의 상수를 포함함 - 하는 단계를 포함하는 방법.
28. 제23항에 있어서,
    상기 제2 스레드가 현재 실행중이고, 상기 충돌률이 충돌 임계값을 초과하는 것에 응답하여 상기 제1 스레드의 스케줄링을 지연하는 단계는 상기 제2 스레드가 현재 실행중이고, 상기 충돌률이 충돌 임계값을 초과하는 것에 응답하여 상기 제1 스레드에 대한 리턴(return)을 지연하는 단계를 포함하는 방법.
29. 제23항에 있어서,
    상기 제2 스레드가 현재 실행중이고, 상기 충돌률이 충돌 임계값을 초과하는 것에 응답하여 상기 제1 스레드의 스케줄링을 지연하는 단계는 상기 제2 스레드가 현재 실행중이고, 상기 충돌률이 충돌 임계값을 초과하는 것에 응답하여 상기 제1 스레드에 대한 애플리케이션 인터페이스 호출을 지연하는 단계를 포함하는 방법.

Images