KR101843671B1 - 트랜잭션 상태를 표시하기 위한 일관성 프로토콜 증대 - Google Patents
트랜잭션 상태를 표시하기 위한 일관성 프로토콜 증대 Download PDFInfo
- Publication number
- KR101843671B1 KR101843671B1 KR1020167017373A KR20167017373A KR101843671B1 KR 101843671 B1 KR101843671 B1 KR 101843671B1 KR 1020167017373 A KR1020167017373 A KR 1020167017373A KR 20167017373 A KR20167017373 A KR 20167017373A KR 101843671 B1 KR101843671 B1 KR 101843671B1
- Authority
- KR
- South Korea
- Prior art keywords
- transaction
- processor
- remote
- request
- cpu
- Prior art date
Links
- 230000003416 augmentation Effects 0.000 title description 2
- 230000004044 response Effects 0.000 claims abstract description 93
- 230000015654 memory Effects 0.000 claims description 104
- 238000000034 method Methods 0.000 claims description 51
- 238000012545 processing Methods 0.000 description 42
- 238000001514 detection method Methods 0.000 description 39
- 239000000872 buffer Substances 0.000 description 24
- 238000010586 diagram Methods 0.000 description 20
- 230000009471 action Effects 0.000 description 16
- 238000012937 correction Methods 0.000 description 14
- 238000013461 design Methods 0.000 description 14
- 230000006870 function Effects 0.000 description 14
- 238000001693 membrane extraction with a sorbent interface Methods 0.000 description 13
- 230000007246 mechanism Effects 0.000 description 11
- 238000005457 optimization Methods 0.000 description 10
- 230000007704 transition Effects 0.000 description 9
- 230000008901 benefit Effects 0.000 description 8
- 238000002955 isolation Methods 0.000 description 8
- 230000008569 process Effects 0.000 description 8
- 238000010200 validation analysis Methods 0.000 description 8
- 238000000926 separation method Methods 0.000 description 7
- 238000012360 testing method Methods 0.000 description 7
- 239000002699 waste material Substances 0.000 description 7
- 238000004590 computer program Methods 0.000 description 6
- 238000004574 scanning tunneling microscopy Methods 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 5
- 230000002452 interceptive effect Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012544 monitoring process Methods 0.000 description 5
- 125000004122 cyclic group Chemical group 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000005259 measurement Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 230000001419 dependent effect Effects 0.000 description 3
- 230000007717 exclusion Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000013519 translation Methods 0.000 description 3
- XUIMIQQOPSSXEZ-UHFFFAOYSA-N Silicon Chemical compound [Si] XUIMIQQOPSSXEZ-UHFFFAOYSA-N 0.000 description 2
- 206010000210 abortion Diseases 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 230000004888 barrier function Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000001427 coherent effect Effects 0.000 description 2
- 230000002860 competitive effect Effects 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000002156 mixing Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000002829 reductive effect Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 229910052710 silicon Inorganic materials 0.000 description 2
- 239000010703 silicon Substances 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 101100452681 Arabidopsis thaliana INVD gene Proteins 0.000 description 1
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 1
- 241000238631 Hexapoda Species 0.000 description 1
- 101000666458 Homo sapiens XK-related protein 3 Proteins 0.000 description 1
- 101710092886 Integrator complex subunit 3 Proteins 0.000 description 1
- 206010051602 Laziness Diseases 0.000 description 1
- 102100025254 Neurogenic locus notch homolog protein 4 Human genes 0.000 description 1
- 241001122315 Polites Species 0.000 description 1
- 102100038348 XK-related protein 3 Human genes 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 230000002730 additional effect Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 229910052802 copper Inorganic materials 0.000 description 1
- 239000010949 copper Substances 0.000 description 1
- 230000000593 degrading effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 239000002241 glass-ceramic Substances 0.000 description 1
- 235000003642 hunger Nutrition 0.000 description 1
- 230000007334 memory performance Effects 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000001902 propagating effect Effects 0.000 description 1
- 238000010926 purge Methods 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000008054 signal transmission Effects 0.000 description 1
- 230000037351 starvation Effects 0.000 description 1
- 239000004575 stone Substances 0.000 description 1
- 230000001629 suppression Effects 0.000 description 1
- 238000002198 surface plasmon resonance spectroscopy Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
- G06F12/0815—Cache consistency protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
- G06F9/30087—Synchronisation or serialisation instructions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3824—Operand accessing
- G06F9/3834—Maintaining memory consistency
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3854—Instruction completion, e.g. retiring, committing or graduating
- G06F9/3858—Result writeback, i.e. updating the architectural state or memory
- G06F9/38585—Result writeback, i.e. updating the architectural state or memory with result invalidation, e.g. nullification
-
- G06F9/3859—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/10—Providing a specific technical effect
- G06F2212/1016—Performance improvement
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/62—Details of cache specific to multiprocessor cache arrangements
- G06F2212/621—Coherency control relating to peripheral accessing, e.g. from DMA or I/O device
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Memory System Of A Hierarchy Structure (AREA)
- Executing Machine-Instructions (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
- Communication Control (AREA)
- Advance Control (AREA)
Abstract
본 발명의 실시 예들은 일관성 프로토콜을 구현하는 것에 관한 것이다. 한 실시 예는 데이터에 대한 요청을 리모트 프로세서에 내보내는 단계 및 프로세서에 의해, 상기 리모트 프로세서로부터의 응답을 수신하는 단계를 포함한다. 상기 프로세서는 상기 리모트 프로세서 상의 상기 리모트 트랜잭션의 트랜잭션 상태를 로컬 트랜잭션 간섭 추적 테이블(a local transaction interference tracking table)에 추가한다.
Description
본 발명은 일반적으로 프로토콜들을 요청하고 응답하는 것에 관한 것이고, 더 구체적으로는 트랜잭션 상태를 표시하기 위한 일관성 프로토콜 증대(coherence protocol augmentation)에 관한 것이다.
칩 상의 중앙 처리 유닛(CPU) 코어들의 수와 공유 메모리에 접속된 CPU 코어들의 수는 증가하는 워크로드 용량 수요를 지원하기 위해 계속적으로 대단히 증가하고 있다. 동일 워크로드들을 처리하기 위해 협력하는 CPU들의 수가 증가하면 소프트웨어 스케일능력(scalability)에 심각한 부담을 주는데; 예를 들어, 전통적인 세마포어들(traditional semaphores)에 의해서 보호되는 공유 큐들 또는 데이터 구조들(shared queues or data-structures)은 핫스팟(hot spots)이 되어서 서브-리니어 n-웨이 스케일링 커브들(sub-linear n-way scaling curves)에 이르게 된다. 전통적으로, 그것은 소프트웨어 내에서는 더 정교하게-세분화된 로킹(finer-grained locking)을 구현함으로써 그리고 하드웨어 내에서는 더 낮은 지연/더 높은 대역폭 인터커넥트들을(lower latency/higher bandwidth interconnects) 둠으로써 대응해 왔다. 소프트웨어 스케일능력을 개선하기 위해 더 정교하게-세분화된 로킹을 구현하는 것은 매우 복잡하고(complicated) 오류발생이 쉽게 일어날(error-prone) 수 있으며, 그리고 오늘날 CPU 주파수들에서, 하드웨어 인터커넥트들의 지연은 칩들 및 시스템들의 물리적 디멘젼에 의해서, 그리고 빛의 속도에 의해서 제한된다.
하드웨어 트랜잭션 메모리(Hardware transactional memory)(HTM, 또는 이 출원에서는 단순하게 TM이라고 함)가 도입되었는데, 여기서 한 그룹의 명령들 ― 이를 트랜잭션이라 한다 ― 은 다른 중앙 처리 유닛들(CPU들) 및 I/O 서브시스템이 볼 때 메모리 내 데이터 구조에서 원자 방식으로(in an atomic manner) 연산된다(operate)(원자적 연산(atomic operation)이란 또한 다른 문헌에서는 블록이 동시화(concurrent) 또는 직렬화(serialized)된다는 것으로 알려져 있다). 트랜잭션은 록(a lock)을 획득하지 않는 한 낙관적으로(optimistically) 실행하지만, 만일, 트랜잭션 실행 중에, 한 메모리 위치 상의 연산이 동일 메모리 위치 상의 다른 연산과 충돌이 일어난다면, 그 트랜잭션 실행을 폐기하고(abort) 재시도(retry)할 필요가 있을 수 있다. 이전에, 소프트웨어 트랜잭션 메모리 구현들이 소프트웨어 트랜잭션 메모리(TM)을 지원하기 위해 제안되었다.
본 발명의 실시 예들에는 일관성 프로토콜(a coherence protocol)을 구현하기 위한 방법, 시스템, 및 컴퓨터 프로그램 제품이 포함된다. 데이터에 대한 요청이 리모트 프로세서(a remote processor)에 보내지면, 한 프로세서가 상기 리모트 프로세서로부터 응답(a response)을 수신하고, 상기 응답은 상기 리모트 프로세서 상의 리모트 트랜잭션(a remote transaction)의 트랜잭션 상태(a transaction status)를 갖는다. 상기 프로세서는 상기 리모트 프로세서상의 상기 리모트 트랜잭션의 트랜잭션 상태를 로컬 트랜잭션 간섭 추적 테이블(a local transaction interference tracking table)에 추가한다.
본 발명의 실시 예들에 관한 주제는 구체적으로 기재되어 본 명세서의 끝 부분의 청구 범위에서 청구항들로서 분명하게 청구된다. 본 발명의 실시 예들의 전술한 그리고 기타 특징들, 및 장점들은 아래에 첨부되는 도면들을 참조한 아래의 상세한 설명으로부터 명확하다.
도 1은 본 발명의 한 실시 예에 따라 예시적 멀티플 프로세서(CPU)/코어 트랜잭션 메모리 환경의 개념적 블록도를 도시한다.
도 2는 본 발명의 한 실시 예에 따라 트랜잭션 프로세서를 보여주는 블록도를 도시한다.
도 3은 본 발명의 한 실시 예에 따라 도 1 및 2에서 도시한 트랜잭션 프로세서(CPU)의 예시적 컴포넌트들의 블록도를 도시한다.
도 4는 본 발명의 한 실시 예에 따라 하드웨어 트랜잭션 환경에서 요청들과 응답들을 허용하기 위해, 도 1―3에서 도시한 멀티프로세서 시스템과 같은 컴포넌트들을 갖는 컴퓨터 시스템의 블록도를 도시한다.
도 5는 본 발명의 한 실시 예에 따른 예시적 프로토콜 요청과 응답을 도시한다.
도 6은 본 발명의 한 실시 예에 따른 예시적 프로토콜 요청을 도시한다.
도 7은 본 발명의 한 실시 예에 따라 프로세서가 데이터에 대한 요청을 함에 의한 프로토콜 요청 생성의 흐름도를 도시한다.
도 8은 본 발명의 한 실시 예에 따라 요청을 수신하고 응답을 내보내는 수신/리모트 프로세서에 의한 요청 처리의 흐름도를 도시한다.
도 9는 본 발명의 한 실시 예에 따라 프로세서에 의한 트랜잭션 처리를 보여주는 흐름도를 도시한다.
도 10은 본 발명의 한 실시 예에 따른 프로토콜 요청과 새로운 프로토콜 응답을 도시한다.
도 11은 본 발명의 한 실시 예에 따른 프로토콜 라이트 요청과 새로운 응답을 도시한다.
도 12는 본 발명의 한 실시 예에 따라 요청을 수신하는 수신/리모트 프로세서에 의한 일관성 요청 처리를 보여주는 흐름도를 도시한다.
도 13은 본 발명의 한 실시 예에 따라 요청하는 프로세서에 의한 프로토콜 요청 오리지네이션 및 처리를 보여주는 흐름도를 도시한다.
도 14는 본 발명의 한 실시 예에 따라 프로세서에 의한 트랜잭션 처리를 보여주는 흐름도를 도시한다.
도 15는 본 발명의 한 실시 예에 따라 로컬 추적 트랜잭션 간섭 스토리지 테이블에서 간섭 표시에 대해 프로세서가 어떻게 응답하는지를 보여주는 흐름도를 도시한다.
도 16은 본 발명의 한 실시 예에 따라 로컬 추적 트랜잭션 간섭 스토리지 테이블에서 간섭 표시에 대해 프로세서가 어떻게 응답하는지를 보여주는 흐름도를 도시한다.
도 17은 본 발명의 한 실시 예에 따라 일관성 프로토콜 처리를 위한 방법을 도시한다.
도 18은 본 발명의 한 실시 예에 따른 컴퓨터 판독 가능 매체를 도시한다.
도 1은 본 발명의 한 실시 예에 따라 예시적 멀티플 프로세서(CPU)/코어 트랜잭션 메모리 환경의 개념적 블록도를 도시한다.
도 2는 본 발명의 한 실시 예에 따라 트랜잭션 프로세서를 보여주는 블록도를 도시한다.
도 3은 본 발명의 한 실시 예에 따라 도 1 및 2에서 도시한 트랜잭션 프로세서(CPU)의 예시적 컴포넌트들의 블록도를 도시한다.
도 4는 본 발명의 한 실시 예에 따라 하드웨어 트랜잭션 환경에서 요청들과 응답들을 허용하기 위해, 도 1―3에서 도시한 멀티프로세서 시스템과 같은 컴포넌트들을 갖는 컴퓨터 시스템의 블록도를 도시한다.
도 5는 본 발명의 한 실시 예에 따른 예시적 프로토콜 요청과 응답을 도시한다.
도 6은 본 발명의 한 실시 예에 따른 예시적 프로토콜 요청을 도시한다.
도 7은 본 발명의 한 실시 예에 따라 프로세서가 데이터에 대한 요청을 함에 의한 프로토콜 요청 생성의 흐름도를 도시한다.
도 8은 본 발명의 한 실시 예에 따라 요청을 수신하고 응답을 내보내는 수신/리모트 프로세서에 의한 요청 처리의 흐름도를 도시한다.
도 9는 본 발명의 한 실시 예에 따라 프로세서에 의한 트랜잭션 처리를 보여주는 흐름도를 도시한다.
도 10은 본 발명의 한 실시 예에 따른 프로토콜 요청과 새로운 프로토콜 응답을 도시한다.
도 11은 본 발명의 한 실시 예에 따른 프로토콜 라이트 요청과 새로운 응답을 도시한다.
도 12는 본 발명의 한 실시 예에 따라 요청을 수신하는 수신/리모트 프로세서에 의한 일관성 요청 처리를 보여주는 흐름도를 도시한다.
도 13은 본 발명의 한 실시 예에 따라 요청하는 프로세서에 의한 프로토콜 요청 오리지네이션 및 처리를 보여주는 흐름도를 도시한다.
도 14는 본 발명의 한 실시 예에 따라 프로세서에 의한 트랜잭션 처리를 보여주는 흐름도를 도시한다.
도 15는 본 발명의 한 실시 예에 따라 로컬 추적 트랜잭션 간섭 스토리지 테이블에서 간섭 표시에 대해 프로세서가 어떻게 응답하는지를 보여주는 흐름도를 도시한다.
도 16은 본 발명의 한 실시 예에 따라 로컬 추적 트랜잭션 간섭 스토리지 테이블에서 간섭 표시에 대해 프로세서가 어떻게 응답하는지를 보여주는 흐름도를 도시한다.
도 17은 본 발명의 한 실시 예에 따라 일관성 프로토콜 처리를 위한 방법을 도시한다.
도 18은 본 발명의 한 실시 예에 따른 컴퓨터 판독 가능 매체를 도시한다.
멀티프로세서 시스템들은 일관성 프로토콜들을 사용하는데, 이는 분산된 공유 메모리 시스템(a system of distributed shared memory)에서 모든 캐시들(all the caches) 사이에서 일관성(the consistency)을 유지하기 위함이다. 특정 캐시로부터의 데이터에 대한 요청이 있으면, 상기 캐시는 요청된 데이터를 제공하고(issue) 자신이 더 이상 그 데이터를 가지고 있지 않다거나 또는 그 데이터는 배타적으로(exclusively) 보유되고(held) 있지 않다고 자신의 상태를 갱신한다(update). 만일 어느 프로세서가 트랜잭션 실행 중이고, 자신의 캐시로부터 상기 데이터가 요청되고 상기 데이터가 상기 트랜잭션의 일부분이라면, 상기 프로세서는 상기 트랜잭션을 폐기하고, 상기 데이터를 내보낸다.
한 요청이 다른 트랜잭션을 폐기하였는지에 관해서는 아무런 정보도 제공되지 않는다. 일부 경우들에서는, 요청이 다른 트랜잭션에 영향을 끼쳤는지(impacted)에 관하여 최초 요청자(the original requestor)에게 알려주는 것이 바람직한데, 이는 피드백을 제공해서, 상기 최초 요청자가 자신의 실행을 조정할 수 있도록, 예를 들어, 무한반복 시나리오들(livelock scenarios)을 검출하고 다른 성능 열화 시나리오들(other performance degrading scenarios)을 해결하도록 하기 위함이다.
본 발명의 실시 예에 따라, 일관성 프로토콜은 트랜잭션 상태에 관한 추가 정보를 포함하도록 확장된다(extended). 프로세서가 트랜잭션 실행 중일 때, 일관성 요청(a coherence request)이 자신의 실행을 폐기하도록 할 수 있는데, 그 이유는, 예를 들어 데이터가 트랜잭션 리드(read) 또는 라이트(write) 세트의 일부분이고 그리고 충돌이 검출되었기 때문이다. 상기 일관성 프로토콜 요청(the coherence protocol request)은 본 발명의 실시 예들에 따라 트랜잭션 실행 동안 그것(상기 일관성 요청을 수신한 프로세서)이 트랜잭션을 폐기하였다는 추가의 정보 때문에 확장된다.
"여기서 전체가 참조로 포함되는 IBM®사가 2013년 5월 22일 발표한 "파워 ISA 버전 2.07(Power ISA™ Version 2.07)에는 축소 명령 세트 컴퓨터(RISC) 명령 세트 아키텍처(ISA)의 예가 잘 설명되어 있다". 또한, 여기서 전체가 참조로 포함되는 IBM®사가 2012년 8월 발표한 "z/아키텍처 연산의 원리들" SA22-7832-09에는 복잡 명령 세트 컴퓨터(CISC) 명령 세트 아키텍처(ISA)의 예가 잘 설명되어 있다.
역사적으로, 컴퓨터 시스템 또는 프로세서는 오직 하나의 프로세서(처리 유닛 또는 중앙 처리 유닛으로도 알려짐)만을 가졌다. 상기 프로세서는 명령 처리 유닛(IPU), 분기 유닛, 메모리 제어 유닛, 등을 포함했다. 그러한 프로세서들은 한번에 프로그램의 하나의 스레드(a single thread)를 실행할 수 있었다. 운영 체제들이 개발되어서 한 구간의 시간 기간 동안(for a period of time) 한 프로그램이 프로세서 상에서 실행되도록 파견하고(dispatching), 다른 구간의 시간 기간 동안(for another period of time) 다른 프로그램이 프로세서 상에서 실행되도록 파견함으로써 프로세서의 시간을 공유할 수 있게(time-share) 해 주었다, 기술이 발전함에 따라, 변환 룩어사이드 버퍼들(translation lookaside buffers: TLBs)을 포함하는 복잡한 동적 어드레스 변환뿐만 아니라 메모리 서브시스템 캐시들이 종종 프로세서에 추가 되었다. IPU 그 자체는 종종 프로세서로 불리었다. 기술이 계속 발전함에 따라, 전체 프로세서가, 하나의 단일 칩 또는 다이(die)로서 패키지 될 수 있었는데, 그러한 프로세서를 마이크로프로세서라 하였다. 그 후 다수의 IPU들을 포함하는 프로세서들이 개발되었는데, 그러한 프로세서들은 종종 멀티프로세서들(multiprocessors)이라 불리었다. 멀티프로세서 컴퓨터 시스템(프로세서)의 각 프로세서는 개별 또는 공유 캐시들, 메모리 인터페이스들, 시스템 버스, 어드레스 변환 메커니즘, 등을 포함할 수 있다. 가상 머신 및 명령 세트 아키텍처(ISA) 에뮬레이터들(Virtual machine and instruction set architecture (ISA) emulators)은 소프트웨어의 층을 프로세서에 추가하였는데, 이것은 단일 하드웨어 프로세서에서 단일 IPU의 타임-슬라이스(time-slice)를 이용함으로써 가상 머신에 다수의 "가상 프로세서들"(또한 프로세서들로도 알려짐)을 제공하였다. 기술이 더욱 발전함에 따라, 멀티 스레드 프로세서들(multi-threaded processors)이 개발되었고, 이들은 단일 멀티 스레드 IPU를 갖는 단일 하드웨어 프로세서가 다른 프로그램들의 스레드들을 동시에 실행하는 능력을 제공할 수 있게 해 주었고, 그 결과 멀티-스레드 프로세서의 각 스레드는 운영 체제에 대하여 하나의 프로세서처럼 보이게 되었다. 기술이 계속 발전함에 따라, 단일의 반도체 칩 또는 다이 상에 다수의 프로세서들(각각은 하나의 IPU를 가짐)을 배치하는 것도 가능하게 되었다. 이들 프로세서들은 프로세서 코어들 또는 그냥 코어들이라고 불리었다. 따라서, 예를 들어, 프로세서, 중앙 처리 유닛, 처리 유닛, 마이크로프로세서, 코어, 프로세서 코어, 프로세서 스레드, 스레드 등과 같은 용어들은 종종 서로 같은 의미로(interchangeably) 사용된다. 본 발명의 실시 예들에서는 위에서 소개한 것들을 포함하는 어떠한 또는 모든 프로세서들이 본 명세서의 설명을 벗어남이 없이 사용될 수 있다. 여기서 "스레드(thread)" 또는 "프로세서 스레드"라는 용어가 사용될 때, 본 발명의 실시 예의 특별한 장점이 프로세서 스레드 구현에 포함될 수 있음이 기대된다.
인텔® 기반 실시 예들에서 트랜잭션 실행
여기서 전체가 참조로 포함되는 인텔 사가 2012년 2월에 발표한, "인텔 아키텍처 명령 세트 확장 프로그래밍 레퍼런스" 319433-012A("Intel® Architecture Instruction Set Extensions Programming Reference" 319433-012A)에서 제8장은, 부분적으로, 멀티스레드 애플리케이션들(multithreaded applications)은 더 높은 성능을 달성하기 위해 CPU 코어들의 수를 증가시키는 것을 이용할 수 있음을 시사한다. 그러나, 멀티-스레드 애플리케이션들의 라이팅은 프로그래머들이 다수의 스레드들 사이에서의 데이터 공유(data sharing)을 이해하고 고려할 것을 요구한다. 공유 데이터(shared data)에 대한 액세스는 통상적으로 동기화 메커니즘들을 필요로 한다. 이들 동기화 메커니즘들은, 다수의 스레드들이, 종종 락(a lock)에 의해서 보호되는 크리티컬 섹션(a critical section)의 사용을 통해서, 공유된 데이터에 적용된 연산들을 직렬화함으로써(by serializing) 공유된 데이터를 확실히 갱신하기 위해 사용된다. 직렬화(serialization)는 동시 실행(concurrency)을 제한하므로, 프로그래머들은 동기화로 인한 오버헤드(the overhead)를 제한하기 위해 노력한다.
인텔 트랜잭션 동기화 확장들(Intel® Transactional Synchronization Extensions (Intel® TSX))은 프로세서가 락-보호된 크리티컬 섹션들(lock-protected critical sections)을 통해 스레드들이 직렬화될 필요가 있는지를 동적으로 결정하여 필요할 때만 그 직렬화를 수행할 수 있게 한다. 이는 프로세서가 동적으로 불필요한 동기화 때문에 애플리케이션에서 숨겨져 있던 동시실행을 노출하고 이용할 수 있게 해준다.
인텔 TSX 때문에, 프로그래머-명시된 코드 영역들(programmer-specified code regions)(또한 "트랜잭션 영역들" 또는 그냥 "트랜잭션들"이라고도 함)은 트랜잭션으로서(transactionally) 실행된다. 만일 상기 트랜잭션 실행이 성공적으로 완료되면, 상기 트랜잭션 영역 내에서 수행된 모든 메모리 연산들은 다른 프로세서들에서 보았을 때 동시에(instantaneously) 일어난(occurred) 것으로 보여질 것이다. 프로세서는 오직 성공적인 커밋(a successful commit)이 발생할 때만, 즉 트랜잭션이 성공적으로 실행을 완료했을 때만, 실행된 트랜잭션의 메모리 연산을 실시하는데, 이는 트랜잭션 영역 내에서 수행되고, 다른 프로세서들에게 보여질 수 있다. 이 프로세스를 종종 원자 커밋(an atomic commit)이라 한다.
인텔 TSX는 트랜잭션 실행을 위한 코드의 영역들을 명시하기 위해 두 개의 소프트웨어 인터페이스들을 제공한다. 하드웨어 락 일리전(Hardware Lock Elision:HLE)은 구형 컴퓨터 시스템과 호환 가능한 명령세트 확장(a legacy compatible instruction set extension) (XACQUIRE 및 XRELEASE prefixes를 포함함)이고 트랜잭션 영역들을 명시한다. 제한된 트랜잭션 메모리(Restricted Transactional Memory: RTM)는 프로그래머들을 위한 새로운 명령 세트 인터페이스(a new instruction set interface)(XBEGIN, XEND, 및 XABORT 명령들을 포함함)이며, 이는 프로그래머들이 HLE와 가능한 것보다 더 융통성 있는 방식으로 트랜잭션 영역들을 정의할 수 있게 해 준다. HLE 는 종래의 상호 배타(mutual exclusion) 프로그래밍 모델의 낙후된 호환성(backward compatibility)을 선호하고, 그리고 구형 컴퓨터 하드웨어 상에서 HLE-인에이블된 소프트웨어(HLE-enabled software)를 실행하기를 원하지만 또한 HLE 지원과 함께 하드웨어 상의 새로운 락 일리전 능력들(the new lock elision capabilities)의 장점도 이용하기를 원하는 프로그래머들을 위한 것이다. RTM은 트랜잭션 실행 하드웨어에 대한 융통성 있는 인터페이스를 선호하는 프로그래머들을 위한 것이다. 이에 더하여, 인텔 TSX는 또한 XTEST 명령을 제공한다. 이 명령은 논리 프로세서가 HLE 또는 RTM에 의해서 식별된 트랜잭션 영역에서 트랜잭션으로서 실행하고 있는지에 관해서 소프트웨어가 질의할 수 있도록 해준다.
성공적인 트랜잭션 실행이 원자적 커밋을 보장하기 때문에, 프로세서는 명시적인 동기화 없이도 코드 영역(the code region)을 낙관적으로 실행한다. 만일 동기화가 특정 실행을 위해 불필요하다면, 실행은 아무런 크로스-스레드 직렬화(any cross-thread serialization)없이 커밋될 수 있다. 만일 프로세서가 원자적으로 커밋할 수 없다면, 낙관적 실행은 실패한다. 이러한 일이 발생하면, 프로세서는 상기 실행을 롤백(roll back)할 것인데, 이러한 프로세스를 트랜잭션 폐기라 한다. 트랜잭션 폐기가 결정되면, 프로세서는 상기 트랜잭션에 의해서 사용되었던 메모리 영역 내에서 수행되었던 모든 갱신들(all updates)을 버리고(discard), 낙관적인 실행이 결코 발생하지 않았던 것처럼 아키텍처 상태(architectural state)를 복원하여(restore), 비-트랜잭션으로서(non-transactionally) 실행을 재개할 것이다(resume).
프로세서는 여러 가지 이유로 트랜잭션 폐기를 수행할 수 있다. 트랜잭션을 폐기하는 일차적인 이유는 트랜잭션으로서 실행하는 논리 프로세서와 다른 논리 프로세서 사이에서 메모리 액세스들의 충돌 때문이다. 그러한 메모리 액세스들의 충돌은 성공적인 트랜잭션 실행을 방해할 수 있다. 트랜잭션 영역 내에서 읽혀지는(read from) 메모리 어드레스들은 트랜잭션 영역의 리드-세트(the read-set)를 구성하고 트랜잭션 영역 내에서 기록되는(written to) 어드레스들은 트랜잭션 영역의 라이트-세트(the write-set)를 구성한다. 인텔 TSX는 캐시 라인의 세부영역(the granularity of a chache line)에서 리드-세트 및 라이트-세트를 유지한다. 메모리 액세스의 충돌은 만일 다른 논리 프로세서가 트랜잭션 영역의 라이트-세트의 일부분인 위치를 리드하거나(read) 또는 트랜잭션 영역의 리드-세트 또는 라이트-세트의 일부분인 위치를 라이트(write)한다면 발생한다. 액세스 충돌은 통상적으로 이 코드 영역을 위해 동기화가 필요하다는 것을 의미한다. 인텔 TSX는 캐시라인의 세부 영역에서 데이터 충돌을 검출하므로, 동일 캐시 라인에 배치된 관련 없는 데이터 위치들은 트랜잭션 폐기를 가져오는 충돌들로서 검출될 것이다. 트랜잭션 폐기는 또한 제한된 트랜잭션 자원들 때문에 발생할 수도 있다. 예를 들어, 상기 영역에서 액세스된 데이터의 양이 설계 용량(an implementation-specific capacity)을 초과할 수 있다. 또한 일부 명령들 및 시스템 이벤트들도 트랜잭션 폐기를 일으킬 수 있다. 빈번한 트랜잭션 폐기는 사이클들(cycles)을 낭비하고 비효율을 증가시킨다.
하드웨어 락 일리전(Hardware Lock Elision)
하드웨어 락 일리전(Hardware Lock Elision: HLE)은 트랜잭션 실행을 사용하기 위해 프로그래머들에게 구형 컴퓨터 시스템과 호환 가능한 명령 세트 인터페이스(a legacy compatible instruction set interface)를 제공한다. HLE는 두 개의 새로운 명령 프리픽스 힌트들(two new instruction prefix hints): XACQUIRE 및 XRELEASE을 제공한다.
HLE를 사용하여, 프로그래머는 XACQUIRE 프리픽스(prefix)를 크리티컬 섹션을 보호하는 락을 획득하기 위해 사용되는 명령의 전면(the front)에 추가한다. 프로세서는 상기 프리픽스를 락 획득 연산과 관련된 라이트를 생략하기(elide) 위한 힌트로 취급한다. 비록 락의 획득(the lock acquire)이 락에 대한 관련된 라이트 연산을 갖는다 할지라도, 프로세서는 락의 어드레스를 트랜잭션 영역의 라이트-세트에 더하지도 않고, 락에 대한 어떠한 라이트 요청들도 발행하지 않는다. 대신에, 락의 어드레스는 리드-세트에 추가되고, 논리 프로세서는 트랜잭션 실행에 들어간다. 만일 락이 XACQUIRE 프리픽스된 명령(the XACQUIRE prefixed instruction) 전에 이용 가능하게 되었다면, 모든 다른 프로세서들은 계속해서 상기 락을 나중에 이용 가능한 것으로 볼 수 있다. 트랜잭션으로서 실행하는 논리 프로세서는 락의 어드레스를 자신의 라이트-세트에 추가하지도, 락에 대하여 외부적으로 볼 수 있는 라이트 연산들을 수행하지도 않을 것이기 때문에, 다른 논리 프로세서들은 데이터 충돌을 일으키는 일 없이 락을 리드(read)할 수 있다. 이것은 다른 논리 프로세서들도 또한 락에 의해서 보호되는 크리티컬 섹션에 들어가서 동시에 실행할 수 있게 해 준다. 따라서 프로세서는 자동으로 트랜잭션 실행 동안 발생하는 모든 데이터 충돌들을 검출하고 필요한 경우 트랜잭션 폐기를 수행할 것이다.
비록 생략하는 프로세서(the eliding processor)가 락에 대하여 아무런 외부 라이트 연산들을 수행하지 않았다 할지라도, 상기 프로세서는 락에 관한 연산들의 프로그램 순서는 보장한다. 만일 상기 생략하는 프로세서 자신이 크리티컬 섹션에서 락의 값을 리드한다면, 그것은 마치 상기 프로세서가 락을 획득한 것처럼 보일 것이다. 즉 상기 리드는 생략이 없는 값(the non-elided value)을 리턴(return)할 것이다. 이러한 동작은 HLE 실행이 HLE 프리픽스들이 없는 실행과 기능적으로 동등하게 될 수 있게 해 준다.
XRELEASE 프리픽스는 크리티컬 섹션을 보호하는 락을 해제하기 위해 사용되는 명령의 앞(front)에 추가될 수 있다. 상기 락을 해제하려면 상기 락에 대해 라이트를 수행해야 한다. 만일 상기 명령이 상기 락의 값을 XACQUIRE가 상기 동일 락에 관한 락 획득 연산으로 프리픽스되기 전에 상기 락이 가졌던 값으로 복원 한다면, 상기 프로세서는 상기 락의 해제와 관련된 외부 라이트 요청을 생략하고(elide) 상기 락의 주소를 라이트-세트에 추가하지 않는다. 그런 다음, 상기 프로세서는 트랜잭션 실행을 커밋 하는 것을 시도한다.
HLE로 인하여, 만일 다수의 스레드들이 상기 동일 락에 의해서 보호되는 크리티컬 섹션들을 실행하지만 서로의 데이터에 관하여 어떠한 충돌하는 연산도 수행하지 않는다면, 상기 스레드들은 직렬화 없이 동시에 실행할 수 있다. 비록 소프트웨어가 공동의 락에 관하여 락 획득 연산들을 사용하더라도, 하드웨어는 이것을 인지하여, 상기 락을 생략하고 상기 락을 통한 ― 통신이 동적으로 불필요했다면 ― 어떠한 통신을 요구함이 없이 두 개의 스레드들에 관한 크리티컬 섹션들을 실행한다.
만일 프로세서가 영역을 트랜잭션으로서 실행할 수 없다면, 프로세서는 그 영역을 비-트랜잭션으로서 실행하고 생략(elision)도 없을 것이다. HLE이 인에이블된 소프트웨어는 하부의 비-HLE 락 기반 실행(the underlying non-HLE lock-based execution)으로서 동일 전진 보장들(the same forward progress guarantees)을 갖는다. 성공적인 HLE 실행을 위해서, 락 및 크리티컬 섹션 코드는 특정 지침들을 따라야 한다. 이들 지침들은 다만 성능에만 영향을 미치고; 이들 지침들을 따르지 못했더라도 기능적 실패(a functional failure)를 초래하지는 않는다. HLE 지원이 없는 하드웨어는 XACQUIRE와 XRELEASE 프리픽스 힌트들을 무시하고 아무런 생략도 수행하지 않는데, 이들 프리픽스들이 XACQUIRE 및 XRELEASE가 유효한 명령들 상에서는 무시되는 REPNE/REPE IA-32 프리픽스들에 대응하기 때문이다. 중요한 사실은, HLE는 기존의 락-기반 프로그래밍 모델과 호환 가능하다는 것이다. 힌트들의 부적절한 사용이 코드 내에서 이미 존재하는 잠복하는 버그들을 노출할 수는 있지만 기능적 버그들(functional bugs)을 일으키지는 않는다.
제한된 트랜잭션 메모리(Restricted Transactional Memory: RTM)는 트랜잭션 실행을 위해 융통성 있는 소프트웨어 인터페이스를 제공한다. RTM은 프로그래머들이 트랜잭션 실행을 시작하고, 커밋하고 그리고 폐기할 수 있도록 세 개의 새로운 명령들 ― XBEGIN, XEND, 및 XABORT― 을 제공한다.
프로그래머는 트랜잭션 코드 영역의 시작을 명시하기 위해 XBEGIN 명령을 그리고 트랜잭션 코드 영역의 종료를 명시하기 위해 XEND 명령을 사용한다. 만일 RTM 영역이 트랜잭션으로서 성공적으로 실행될 수 없었다면, XBEGIN 명령은 폴백 명령 주소(the fallback instruction address)에 상대적인 오프셋(a relative offset)을 제공하는 오퍼랜드를 가져온다.
프로세서는 여러 가지 이유로 RTM 트랜잭션 실행을 폐기할 수 있다. 많은 경우들에서, 하드웨어는 자동으로 트랜잭션 폐기 조건들을 검출하고 폴백 명령 주소로부터 실행을 다시 시작하는데, 이때 아키텍처 상태는 XBEGIN 명령 시작에 제공하는 것에 대응하고 EAX 레지스터는 폐기 상태를 기술하기 위해 갱신된다.
XABORT 명령은 프로그래머들이 RTM 영역의 실행을 명시적으로 폐기할 수 있게 해 준다. XABORT 명령은 8-비트 즉시 변수(an 8-bit immediate argument)를 취하고, 이는 ETX 레지스터에 로드되어 그 다음 RTM 폐기 이후 소프트웨어에 이용 가능하게 된다. RTM 명령들은 이들과 관련된 어떠한 데이터 메모리 위치를 갖지 않는다. 하드웨어는 RTM 영역이 트랜잭션으로서 항상 성공적으로 커밋할 것인지에 관해서 아무런 보장들을 제공하지는 않지만, 추천된 지침들을 따르는 대부분의 트랜잭션들은 트랜잭션으로서 성공적으로 커밋할 것이 기대된다. 그러나, 프로그래머들은 항상 전진을 보장하기 위해 폴백 경로 내에 대체 코드 시퀀스를 제공해야 한다. 이것은 락을 획득하고 명시된 코드 영역을 비-트랜잭션으로서 실행하는 것만큼 단순할 수 있다. 더 나아가서, 주어진 구현에서 항상 폐기하는 트랜잭션이라도 미래 구현에서는 트랜잭션으로서 완료할 수도 있다. 따라서, 프로그래머들은 트랜잭션 영역을 위한 코드 경로를 보장해야 하고 대체 코드 시퀀스도 기능적으로 테스트되어야 한다.
HLE 지원의 검출(Detection of HLE Support)
프로세서는 만일 CPUID.07H.EBX.HLE [bit 4] = 1이면 HLE 실행을 지원한다. 그러나, 애플리케이션은 프로세서가 HLE를 지원하는지 확인하지 않고 HLE 프리픽스들(XACQUIRE 및 XRELEASE)을 사용할 수 있다. HLE 지원이 없는 프로세서들은 이들 프리픽스들을 무시하고 트랜잭션 실행에 들어감이 없이 코드를 실행한다.
RTM 지원의 검출(Detection of RTM Support)
프로세서는 만일 CPUID.07H.EBX.RTM [bit 11] = 1이면 RTM 실행을 지원한다. 애플리케이션은 RTM 명령들 (XBEGIN, XEND, XABORT)을 사용하기 전에 프로세서가 RTM을 지원하는지를 확인해야 한다. 이들 명령들은 RTM을 지원하지 않는 프로세서 상에서 사용되었을 때 #UD 예외를 생성한다.
XTES 명령의 검출(Detection of XTEST Instruction)
프로세서는 만일 HLE 또는 RTM을 지원한다면 XTEST 명령을 지원한다. 애플리케이션은 XTEST 명령을 사용하기 전에 이들 특징 플래그들 중 어느 하나를 확인해야 한다. 이 명령은 HLE 또는 RTM 어느 것도 지원하지 않는 프로세서 상에서 사용될 때 #UD 예외를 생성한다.
트랜잭션 실행 상태를 질의함(Querying Transactional Execution Status)
XTEST 명령은 HLE 또는 RTM에 의해서 명시된 트랜잭션 영역의 트랜잭션 상태를 결정하기 위해 사용될 수 있다. HLE 프리픽스들이 HLE를 지원하지 않는 프로세서 상에서 무시되지만, XTEST 명령은 HLE 또는 RTM 어느 것도 지원하지 않는 프로세서들 상에서 사용될 때 #UD 예외를 생성한다는 사실에 주목해야 한다.
HLE 락들을 위한 요건들(Requirements for HLE Locks)
HLE 실행이 트랜잭션으로서 성공적으로 커밋하기 위해서, 락은 특정 특성들(certain properties)을 만족해야 하고 락에 대한 액세스는 특정 지침들을 따라야 한다.
XRELEASE 프리픽스된 명령은 생략된 락의 값(the value of the elided lock)을 락 획득 전에 가졌던 값으로 복원해야 한다. 이것은 하드웨어가 그 것들을 라이트-세트에 추가하지 않음으로써 락들을 안전하게 생략(elide)할 수 있게 해준다. 락 해제 (XRELEASE 프리픽스된) 명령의 데이터 사이즈와 데이터 어드레스는 락 획득 (XACQUIRE 프리픽스된) 명령의 그것들과 일치해야 하고(must match) 그리고 락은 캐시 라인 경계를 넘어서는 안된다(must not cross a cache line boundary).
소프트웨어는 트랜잭션 HLE 영역 내부의 생략된 락에 대하여 XRELEASE 프리픽스된 명령이 아닌 어떠한 명령으로도 라이트 해서는 안 되며, 그렇지 않으면 그러한 라이트는 트랜잭션 폐기를 일으킬 수 있다. 이에 더하여, (한번도 해제함이 없이 스레드가 동일 락을 여러 번 획득하는 경우와 같은) 반복적인 락들(recursive locks)은 또한 트랜잭션 폐기를 일으킬 수 있다. 소프트웨어는 크리티컬 섹션 내부에서 생략된 락 획득의 결과를 관찰할 수 있음을 주목해야 한다. 그러한 리드 연산은 락에 대한 라이트의 값을 리턴할 것이다.
프로세서는 이들 지침들에 대한 위반들을 자동으로 검출하고, 생략(elision) 없이 비-트랜잭션 실행으로 안전하게 전환한다. 인텔 TSX는 캐시 라인의 세부사항에서 충돌들을 검출하고, 생략된 락과 동일한 캐시 라인 상에서 수집된 데이터에 대한 라이트들은 동일 락을 생략하는 다른 논리 프로세서들에 의해서 데이터 충돌들로서 검출될 수 있다.
트랜잭션 내포(Transactional Nesting)
HLE 및 RTM 모두는 네스트된 트랜잭션 영역들(nested transactional regions)을 지원한다. 그러나, 트랜잭션 폐기는 트랜잭션 실행을 시작한 연산: 가장 바깥쪽의 XACQUIRE 프리픽스된 HLE 엘리저블 명령(the outermost XACQUIRE prefixed HLE eligible instruction) 또는 가장 바깥쪽의 XBEGIN 명령(the outermost XBEGIN instruction) 중 어느 하나에 대한 상태를 복원한다. 프로세서는 모든 네스트된 트랜잭션들을 하나의 트랜잭션으로서 취급한다.
HLE 내포 및 생략(HLE Nesting and Elision)
프로그래머들은 HLE 영역들을 MAX_HLE_NEST_COUNT의 구현 특정 깊이(an implementation specific depth of MAX HLE NEST COUNT)까지 내포(nest)할 수 있다. 각각의 논리 프로세서는 내포 카운트를 내부적으로 추적하지만 이 카운트는 소프트웨어에게는 이용 가능하지 않다. XACQUIRE 프리픽스된 HLE-엘리저블 명령은 내포 카운트를 증가시키고, XRELEASE 프리픽스된 HLE-엘리저블 명령은 그것을 감소시킨다. 논리 프로세서는 내포 카운트가 0에서 1로 될 때 트랜잭션 실행에 들어간다. 논리 프로세서는 내포 카운트가 0이 될 때만 커밋하는 것을 시도한다. 트랜잭션 폐기는 만일 내포 카운트가 MAX_HLE_NEST_COUNT를 초과한다면 발생할 수 있다.
내포된 HLE 영역들을 지원하는 것에 더하여, 프로세서는 또한 다수의 내포된 락들을 생략할 수 있다. 프로세서는 락을 위해 XACQUIRE 프리픽스된 HLE 엘리저블 명령으로 시작하고 동일 락을 위해 XRELEASE 프리픽스된 HLE 엘리저블 명령으로 종료하는 생략을 위한 락을 추적한다. 프로세서는, 한 번에, 락들의 최대 HLE 생략 락들(MAX_HLE_ELIDED_LOCKS)의 수까지 추적할 수 있다. 예를 들어, 만일 구현이 두 개의 최대 HLE 생략 락들(MAX_HLE_ELIDED_LOCKS) 값을 지원하고 만일 프로그래머가 (락들 중 어느 것에 관하여도 개입하는 XRELEASE 프리픽스된 HLE 엘리저블 명령을 수행함이 없이 XACQUIRE 프리픽스된 HLE 엘리저블 명령을 세 개의 구별되는 락들에 관하여 수행함에 의해서) 세 개의 HLE 식별된 크리티컬 섹션들을 내포한다면, 첫 두 개의 락들은 생략되지만, 세 번째는 생략되지 않을 것이다(트랜잭션 라이트-세트에 더해질 것이다). 그러나, 실행은 여전히 트랜잭션으로서 계속될 것이다. 일단 두 개의 생략된 락들 중 하나를 위한 XRELEASE가 나타나면(encountered), XACQUIRE 프리픽스된 HLE 엘리저블 명령을 통해 획득된 후속의 락은 생략될 것이다.
모든 생략된 XACQUIRE 및 XRELEASE 쌍들이 일치되었고(matched), 내포 카운트는 0이 되며, 그리고 락들은 요건들을 만족하였을 때 프로세서는 HLE 실행을 커밋하는 것을 시도한다. 만일 실행이 원자적으로 커밋을 할 수 없다면, 실행은 마치 제1 명령이 XACQUIRE 프리픽스를 갖지 않는 것처럼 생략 없이 비-트랜잭션 실행으로 이행된다(transition).
RTM 내포(RTM Nesting)
프로그래머들은 RTM 영역들을 특정 MAX_RTM_NEST_COUNT 구현(an implementation specific MAX_RTM_NEST_COUNT)까지 내포(nest)할 수 있다. 논리 프로세서는 내포 카운트를 내부적으로 추적할 수 있지만 이 카운트는 소프트웨어에는 이용 가능하지 않다. XBEGIN 명령은 내포 카운트를 증가시키고, XEND 명령은 내포 카운트를 감소시킨다. 논리 프로세서는 내포 카운트가 0이 될 때만 커밋하는 것을 시도한다. 트랜잭션 폐기는 만일 내포 카운트가 MAX_RTM_NEST_COUNT를 초과한다면 발생한다.
HLE 및 RTM의 내포(Nesting HLE and RTM)
HLE 및 RTM은 두 개의 대체 소프트웨어 인터페이스들을 공동 트랜잭션 실행 능력(a common transactional execution capability)에 제공한다. 트랜잭션 처리 동작은 HLE 및 RTM이 함께 내포 되었을 때, 예를 들어 HLE가 RTM의 내부에 있을 때 또는 RTM이 HLE의 내부에 있을 때 특정하게 구현된다(implementation specific). 그러나, 모든 경우에 있어서, 그러한 구현은 HLE 및 RTM의 시맨틱스(semantics)를 유지할 것이다. RTM 영역들 내부에서 사용되었을 때 HLE 힌트들을 무시하는 구현이 선택될 수 있고, 이는 RTM 명령들이 HLE 영역들 내부에서 사용될 때 트랜잭션 폐기를 일으킬 수 있다. 후자의 경우에, 트랜잭션에서 비-트랜잭션 실행으로 이행이 매끄럽게(seamlessly) 발생하는데, 이는 프로세서가 실제로 생략을 행함이 없이 HLE 영역을 재실행하고, 그 다음에 RTM 명령들을 실행할 것이기 때문이다.
폐기 상태 정의(Abort Status Definition)
RTM은 폐기 상태를 소프트웨어에 알리기 위해 EAX 레지스터를 사용한다. RTM 폐기 다음에 EAX 레지스터는 다음의 정의를 갖는다.
| RTM 폐기 상태 정의 | |
| EAX 레지스터 비트 위치 |
의미 |
| 0 | XABORT 명령에 의해서 폐기가 일어났다면, 세트함 |
| 1 | 만일 세트라면, 트랜잭션은 재시도에서 성공할 수 있고, 이 비트는 비트 0이 세트되었다면 항상 클리어된다 |
| 2 | 만일 다른 논리 프로세서가 폐기된 트랜잭션의 일부분이었던 메모리 어드레스와 충돌되었다면, 세트함 |
| 3 | 만일 내부 버퍼가 오버플로였다면, 세트함 |
| 4 | 만일 디버그 브레이크포인트가 히트되었다면, 세트함 |
| 5 | 만일 폐기가 내포된 트랜잭션의 실행 동안 발생하였다면, 세트함 |
| 23:6 | 유보됨 |
| 31-24 | XABORT 변수(비트 0이 세트된 경우에만 유효하고, 그렇지 않는 경우는 유보됨) |
RTM을 위한 EAX 폐기 상태는 폐기들에 대한 원인들만을 제공한다. 그 자체로는 RTM 영역들에 대해 폐기 또는 커밋이 발생하였는지 인코드(encode) 하지 않는다. EAX의 값은 RTM 폐기 다음에 0이 될 수 있다. 예를 들어, RTM 영역 내부에서 사용되었을 때 CPUID 명령은 트랜잭션 폐기를 일으키고 EAX 비트들 중 어느 것을 세트하기 위한 요건들을 만족시키지 못할 수 있다. 이는 EAX 값을 0이 되게 할 수 있다.
RTM 메모리 정리(RTM Memory Ordering)
성공적인 RTM 커밋은 RTM 영역 내 모든 메모리 연산들이 원자적으로 실행하도록 한다. XBEGIN과 다음에 오는 XEND로 구성되는 성공적으로 커밋된 RTM 영역은, 비록 RTM 영역에서 메모리 연산은 없을지라도, LOCK 프리픽스된 명령과 동일한 정리 시맨틱스를 갖는다.
XBEGIN 명령은 펜싱 시맨틱스(fencing semantics)를 갖고 있지는 않다. 그러나, 만일 RTM 실행이 폐기되면, RTM 영역 내로부터의 모든 메모리 갱신들은 버려져서 다른 논리 프로세서들에게는 보여질 수 없게 된다.
RTM-인에이블된 디버거 지원(RTM-Enabled Debugger Support)
디폴트로(By default), RTM 영역 내부의 모든 디버그 예외는 트랜잭션 폐기를 일으키고, 제어 플로(control flow)를 폴백 명령 어드레스로 재지정(redirect)함에 따라, 아키텍처 상태는 회복되고 EAX의 비트 4가 세트된다. 그러나, 소프트웨어 디버거들(software debuggers)이 디버그 예외들에서 실행을 인터셉트(intercept)할 수 있도록 하기 위해, RTM 아키텍처는 추가적인 능력을 제공한다.
만일 DR7의 비트 11과 IA32_DEBUGCTL_MSR의 비트 15가 모두 1이면, 디버그 예외(#DB) 또는 브레이크포인트 예외(#BP)로 인한 모든 RTM 폐기가 실행을 롤백(roll back)시켜서 폴백 어드레스 대신에 XBEGIN 명령으로부터 다시 시작하게 한다. 이 시나리오에서, EAX 레지스터도 또한 XBEGIN 명령의 포인트로 되돌아가서 복원될 것이다.
프로그래밍 고려사항들(Programming Considerations)
통상의 프로그래머-식별된 영역들(Typical programmer-identified regions)은 트랜잭션으로서 실행하고 성공적으로 커밋할 것이 기대된다. 그러나, 인텔 TSX는 그러한 것에 관하여 어떠한 보장도 제공하지 않는다. 트랜잭션 실행은 많은 이유들 때문에 폐기될 수 있다. 트랜잭션 능력들의 장점을 완전하게 이용하려면, 프로그래머들은 트랜잭션 실행이 성공적으로 커밋할 확률을 높이기 위해 특정 지침들을 따라야 한다.
이 섹션에서는 트랜잭션 폐기들을 일으킬 수 있는 다양한 이벤트들에 관해서 논의할 것이다. 아키텍처는 후속적으로 실행을 폐기시키는 트랜잭션 내에서 수행된 갱신들을 볼 수 있게 하는 것을 보장하지 않는다. 다만 커밋된 트랜잭션 실행들이 아키텍처 상태에 대해서 갱신을 시작할 뿐이다. 트랜잭션 폐기들은 결코 기능적 실패를 초래하지는 않으며 다만 성능에 영향을 줄 뿐이다.
명령 기반의 고려 사항들(Instruction Based Considerations)
프로그래머들은 트랜잭션(HLE 또는 RTM) 내부에서 임의의 명령을 안전하게 사용할 수 있고 임의의 특권 수준에서 트랜잭션들을 사용할 수 있다. 그러나, 일부 명령들은 항상 트랜잭션 실행을 폐기시키고 실행을 비-트랜잭션 경로로 매끄럽게 그리고 안전하게 이행시킨다.
인텔 TSX는 대부분의 보통 명령들이 폐기들을 일으킴이 없이 트랜잭션 내부에서 사용될 수 있게 해 준다. 트랜잭션 내부의 다음 연산들은 통상적으로 폐기를 일으키지 않는다:
그러나, 프로그래머들은 트랜잭션 영역 내부에서 SSE 및 AVX 연산들을 혼합할 때는 주의해야 한다. XMM 레지스터들을 액세스하는 SSE 명령들 및 YMM 레지스터들을 액세스하는 AVX 명령들을 혼합하는 것은 트랜잭션들이 폐기되게 할 수 있다. 프로그래머들은 트랜잭션 내부에 REP/REPNE 프리픽스된 스트링 연산들(prefixed string operations)을 사용할 수 있다. 그러나, 긴 스트링들은 폐기들을 일으킬 수 있다. 더 나아가, CLD 및 STD명령들의 사용도 이 명령들이 DF 플래그의 값을 변경시킨다면 폐기들을 일으킬 수 있다. 그러나, 만일 DF가 1이면, STD 명령은 폐기를 일으키지 않는다. 비슷하게, 만일 DF가 0이면, CLD 명령은 폐기를 일으키지 않는다.
트랜잭션 내부에서 사용될 때 폐기를 일으키는 것으로 여기서 열거되지 않은 명령들은 통상적으로 트랜잭션이 폐기되게 하지 않는다(이러한 예들로는 MFENCE, LFENCE, SFENCE, RDTSC, RDTSCP, 등이 포함되지만, 이들에 한정되지는 않는다).
다음 명령들은 모든 구현에서 트랜잭션을 폐기시킨다:
이에 더하여, 일부 구현들에서, 다음 명령들은 항상 트랜잭션 폐기들을 일으킬 수 있다. 이들 명령들은 통상적인 트랜잭션 영역들 내부에서 보통으로 사용될 것으로 기대되지 않는다. 그러나 프로그래머들은 트랜잭션 폐기를 강제하기 위해 이들 명령들에 의존해서는 안 된다. 왜냐하면 이들 명령들이 트랜잭션 폐기들을 일으킬지는 구현에 따라 다르기 때문이다.
VZEROUPPER, MASKMOVQ, 및 V/MASKMOVDQU.
런타임 고려 사항들(Runtime Considerations)
명령-기반 고려 사항들에 더하여, 런타임 이벤트들도 트랜잭션 실행이 폐기되게 할 수 있다. 이것은 데이터 액세스 패턴들 또는 마이크로아키텍처 구현 특징들에 기인할 수 있다. 아래 목록은 모든 폐기 원인들을 모두 나열한 것은 아니다.
소프트웨어에 노출되어야 하는 트랜잭션에서의 모든 결함 또는 트랩(fault or trap)은 억제될 것이다. 마치 결함 또는 트랩이 전혀 발생하지 않았던 것처럼, 트랜잭션 실행은 폐기되고 실행은 비-트랜잭션 실행으로 이행될 것이다. 만일 예외가 마스크되지 않는다면, 그 마스크되지 않은 예외는 트랜잭션 폐기를 초래하고 상태는 마치 예외가 결코 발생하지 않았던 것처럼 보여지게 될 것이다.
트랜잭션 실행 동안 발생하는 동기 예외 이벤트들(synchronous exception events)(#DE, #OF, #NP, #SS, #GP, #BR, #UD, #AC, #XF, #PF, #NM, #TS, #MF, #DB, #BP/INT3)은 실행을 트랜잭션으로서 커밋하지 못하게 하여 비-트랜잭션 실행을 요구할 수도 있다. 이들 이벤트들은 마치 그들이 전혀 발생하지 않았던 것처럼 억제된다. HLE에서는, 비-트랜잭션 코드 경로가 트랜잭션 코드 경로와 동일하기 때문에, 이들 이벤트들은 예외를 일으킨 명령이 비-트랜잭션으로서 재실행될 때 통상적으로 다시 보여지게 되고, 따라서 관련된 동기 이벤트들이 비-트랜잭션 실행에서도 적절하게 전달되게 한다. 트랜잭션 실행 동안 발생하는 비동기 이벤트들(asynchronous events)(NMI, SMI, INTR, IPI, PMI, 등)은 트랜잭션 실행을 폐기시키고 비-트랜잭션 실행으로 이행되게 할 수 있다. 비동기 이벤트들은 계류되었다가 트랜잭션 폐기가 처리되고 난 후에 처리될 것이다.
트랜잭션들은 오직 라이트-백 캐시 가능한 메모리 타입 연산들(write-back cacheable memory type operations)만 지원한다. 만일 트랜잭션이 다른 메모리 타입에서의 연산들을 포함한다면, 그러한 트랜잭션은 항상 폐기될 수 있다. 이에는 UC 메모리 타입에 대한 명령 페치들(instruction fetches to UC memory type)이 포함된다.
트랜잭션 영역 내에서 메모리 액세스를 하려면 프로세서에게 참조된 페이지 테이블 엔트리의 액세스된 더티 플래그들(the Accessed and Dirty flags)을 세트하도록 요구할 수 있다. 프로세서가 이를 처리하는 방식은 구현마다 다르다(implementation specific). 일부 구현들은 트랜잭션 영역이 후속으로 폐기된다 하더라도 이들 플래그들에 대한 갱신들을 외부적으로 보이게 할 수 있다. 일부 인텔 TSX 구현들은 이들 플래그들이 갱신될 필요가 있다면 트랜잭션 실행을 폐기하는 것을 선택할 수 있다. 더 나아가, 프로세서의 페이지-테이블 워크(a processor's page-table walk)는 그 자신의 트랜잭션으로서 라이트 되었지만 커밋되지 않은 상태(its own transactionally written but uncommitted state)에 대하여 액세스들을 생성할 수 있다. 일부 인텔 TSX 구현들은 그러한 상황들에서 트랜잭션 영역의 실행을 폐기하는 것을 선택할 수 있다. 이와 상관없이, 그러한 아키텍처에서는, 만일 트랜잭션 영역이 폐기된다면, 트랜잭션으로서 라이트된 상태(the transactionally written state)가 TLB들과 같은 구조들의 동작을 통해서 구조적으로(architecturally) 보여질 수 있게 되지는 않을 것이 확실하다.
셀프 수정 코드(self-modifying code)를 트랜잭션으로서 실행하여도 또한 트랜잭션 폐기를 일으킬 수 있다. 프로그래머들은 HLE 및 RTM을 채용할 때 조차도 셀프-수정 및 크로스-수정 코드(self-modifying and cross-modifying code)를 라이트 하려면 계속적으로 인텔 추천 지침들을 따라야 한다. RTM 및 HLE의 구현은 통상적으로 보통의 트랜잭션 영역들을 실행하기 위해 충분한 자원들을 공급하지만, 트랜잭션 영역들에 대한 구현 제한들 및 과도한 사이즈들은 트랜잭션 실행을 폐기시키고 비-트랜잭션 실행으로 이행하게 할 수 있다. 이러한 아키텍처는 트랜잭션 실행을 하기 위해 이용 가능한 자원들의 양을 보장하지도 않고 트랜잭션 실행이 언제나 성공할 것이라는 것도 보장하지 않는다.
트랜잭션 영역 내에서 액세스된 캐시 라인에 대한 요청들의 충돌은 트랜잭션을 성공적으로 실행하지 못하게 할 수 있다. 예를 들어, 논리 프로세서 P0이 트랜잭션 영역에서 라인 A를 리드하고(read) 다른 논리 프로세서 P1이 라인 A를 라이트 한다면(write) (트랜잭션 영역 내부 또는 외부 어디에서든지), 논리 프로세서 P0은 논리 프로세서 P1의 라이트가 프로세서 P0의 트랜잭션으로서 실행할 능력을 간섭하는(interfere) 경우 폐기할 수 있다.
유사하게, 만일 P0이 트랜잭션 영역에서 라인 A를 라이트하고(write) P1이 라인 A를 리드하거나(read) 또는 라이트한다면(write) (트랜잭션 영역 내부 또는 외부 어디에서든지), P0은 P1의 라인 A에 대한 액세스가 P0의 트랜잭션으로서 실행할 능력을 간섭하는(interfere) 경우 폐기할 수 있다. 이에 더하여, 다른 일관성 트래픽이 때로 충돌하는 요청들로서 나타날 수 있고 폐기들을 일으킬 수 있다. 이들 거짓 충돌들(false conflicts)이 발생할 수 있지만, 흔한 경우는 아니다. P0 또는 P1이 위의 시나리오에서 폐기할 것인지를 결정하기 위한 충돌 해결 정책(the conflict resolution policy)은 구현마다 다르다(implementation specific).
제네릭 트랜잭션 실행 실시 예들(Generic Transaction Execution embodiments):
여기서 전체로서 참조로 포함된, 그리고 2009년 6월, 오스틴 맥도날드(Austen McDonald)에 의해서 박사 학위를 위한 요건들 중 일부분을 충족하기 위해 스탠퍼드 대학교의 컴퓨터 과학과 및 대학원 연구에 관한 위원회에 제출된 "트랜잭션 메모리를 위한 아키텍처들(ARCHITECTURES FOR TRANSACTIONAL MEMORY)"이란 제목의 논문에 따르면, 원자적인 그리고 고립된 트랜잭션 영역을 구현하기 위해 필요한 메커니즘들에는 기본적으로 다음의 세 개가 있다: 버져닝(versioning), 충돌 검출(conflict detection), 그리고 경쟁 관리(contention management).
트랜잭션 코드 영역을 원자적으로 보이게 하기 위해서, 트랜잭션 코드 영역에 의해서 수행되는 모든 수정들은 반드시 저장되어야 하고 커밋 타임까지 다른 트랜잭션들로부터 고립 상태를 유지해야 한다(kept isolated). 시스템은 버져닝 정책(a versioning policy)을 구현함으로써 이것을 실천한다. 두 개의 버져닝 패러다임들이 존재하며 다음과 같다: 열심(eager) 그리고 게으름(lazy). 열심 버져닝 시스템(an eager versioning system)은 새롭게 생성된 트랜잭션 값들을 정 위치에(in place) 저장하고 이전의 메모리 값들은 언두-로그(undo-log)라 불리는, 사이드(side)에 저장한다. 게으름 버져닝 시스템(a lazy versioning system)은 새로운 값들을 라이트 버퍼(a write buffer)라 불리는 곳에 일시적으로 저장하고, 커밋이 있을 때만(only on commit) 그들을 메모리로 복사한다. 어느 시스템에서도, 캐시는 새로운 버전들의 스토리지를 최적화하기 위해 사용된다.
트랜잭션들이 원자적으로 수행되는 것으로 보이는 것을 확실히 하기 위해서, 충돌들은 검출되고 해결되어야 한다. 두 개의 시스템들, 즉 열심과 게으름 버져닝 시스템들은, 낙관적(optimistic) 또는 비관적(pessimistic), 충돌 검출 정책을 구현함으로써 충돌들을 검출한다. 낙관적 시스템은 트랜잭션들을 병렬로 실행하고, 트랜잭션이 커밋할 때만 충돌들에 대한 확인을 한다. 비관적 시스템은 각 로드와 저장마다 충돌들에 대한 확인을 한다. 버져닝과 유사하게, 충돌 검출도 또한 캐시를 사용하는데, 리드-세트의 부분, 라이트-세트의 부분, 또는 모두로서 각각의 라인을 마크한다(mark). 이 두 개의 시스템들은 경쟁 관리 정책을 구현함으로써 충돌들을 해결한다. 여러 경쟁 관리 정책들이 존재하는데, 일부는 낙관적 충돌 검출에 더 적당하고, 일부는 비관적 충돌 검출에 더 적당하다. 그러한 정책들의 일부 예들을 아래에서 기술한다.
각각의 트랜잭션 메모리(TM) 시스템은 버져닝 검출과 충돌 검출 모두를 필요로 하기 때문에, 이들 선택들은 다음과 같은 네 개의 구별되는 TM 설계들을 가능하게 한다: 열심-비관(Eager-Pessimistic: EP), 열심-낙관(Eager-Optimistic: EO), 게으름-비관(Lazy- Pessimistic: LP), 및 게으름-낙관(Lazy-Optimistic: LO). 테이블 2는 네 개의 모든 구별되는 TM 설계들을 기술한다.
도 1 및 2는 멀티 코어 TM 환경의 예를 묘사한다. 도 1은, 인터 커넥트 컨트롤(120a, 120b)의 관리 하에서 인터커넥트(122)로 접속된, 하나의 다이(100) 상에 여러 TM-인에이블된 CPU들(CPU1 114a, CPU2 114b, 등)이 배치되어 있는 것을 도시한다. 각각의 CPU(114a, 114b)(또한 프로세서로도 알려짐)는 분리된 캐시(a split cache)를 가질 수 있는데, 이 캐시는 명령 캐시(an Instruction Cache)(116a, 116b)와 TM 지원을 갖는 데이터 캐시(a Data Cache with TM support)(118a, 118b)로 구성되고, 명령 캐시는 메모리로부터 실행될 명령들을 캐시하며, 데이터 캐시는 CPU (114a, 114b)에 의해서 연산될 메모리 위치들의 데이터(오퍼랜드들)를 캐시해 온다(도 1에서, 각각의 CPU (114a, 114b) 및 그것과 관련된 캐시들은 (112a, 112b)로서 참조된다). 한 구현에서, 다수의 다이들(100)의 캐시들은 인터커넥트 되어서 다수의 다이들(100)의 캐시들 사이에서 캐시 일관성(cache coherency)을 지원한다. 한 구현에서, 단일 캐시가, 분리된 캐시 대신에, 명령들 및 데이터 모두를 저장하기 위해 채용된다. 여러 구현들에서, CPU 캐시들은 계층적 캐시 구조에서 캐싱의 한 수준(one level of caching)이다. 예를 들어, 각각의 다이(100)는 공유 캐시(a shared cache)(124)를 채용할 수 있는데, 이는 다이(100) 상의 모든 CPU들 사이에서 공유된다. 다른 구현에서, 각각의 다이는, 모든 다이들(100)의 모든 프로세서들 사이에서 공유되는, 공유 캐시(124)에 액세스를 할 수 있다.
도 2는 TM을 지원하기 위한 추가 구성들(additions to support TM)을 포함하는, 예시적 트랜잭션 CPU(114)를 상세하게 도시한다. 트랜잭션 CPU(프로세서)(114)는 레지스터 체크포인트들(Register Checkpoints)(126) 및 특별 TM 레지스터들(128)을 지원하기 위한 하드웨어를 포함할 수 있다. 트랜잭션 CPU 캐시는 종래의 캐시의 MESI 비트들(130), 태그들(140) 및 데이터 (142)를 가질 수 있지만, 또한, 예를 들어, 하나의 라인을 도시하는 R 비트들(132)은 트랜잭션을 실행하는 동안 CPU(114)에 의해서 리드된(read) 것이고, 하나의 라인을 도시하는 W 비트들(138)은 트랜잭션을 실행하는 동안 CPU(114)에 의해서 라이트된(written) 것이다.
모든 TM 시스템에서 프로그래머들이 고려해야 할 중요 사항은 비-트랜잭션 액세스들을 트랜잭션들과 어떻게 상호작용하게(interact) 할 것인가 이다. 설계에 의해서, 트랜잭션 액세스들은 위의 메커니즘들을 사용하여 서로로부터 스크린 된다(screened). 그러나, 정규의, 비-트랜잭션 로드(a regular, non-transactional load)와 그 어드레스에 대한 새로운 값을 포함하는 트랜잭션 사이의 상호작용(the interaction)은 여전히 고려되어야만 한다. 이에 더하여, 비-트랜잭션 스토어(a non-transactional store)와 그 어드레스를 리드한 트랜잭션 사이의 상호작용 또한 탐색되어야 한다. 이들은 데이터 베이스 개념 분리의 이슈들(issues of the database concept isolation)이다.
TM 시스템은, 모든 비-트랜잭션 로드 및 스토어가 원자적 트랜잭션처럼 동작될 때, 때때로 강한 원자성(strong atomicity)이라 불리는, 강한 분리(strong isolation)을 구현한다고 한다. 그러므로, 비-트랜잭션 로드들은 커밋되지 않은 데이터(uncommitted data)를 볼 수 없고 비-트랜잭션 스토어들은 그 어드레스를 리드한 모든 트랜잭션에서 원자성 위반들(atomicity violations)을 일으킨다. 그렇지 않은 시스템은 때때로 약한 원자성이라 불리우는, 약한 분리(weak isolation)를 구현한다고 한다.
강한 분리는 종종 약한 분리보다 더 바람직한데, 그 이유는 강한 분리(strong isolation)의 개념화(conceptualization) 및 구현(implementation)이 상대적으로 쉽기 때문이다. 이에 더하여, 만일 프로그래머가 일부 공유 메모리 참조들을 트랜잭션들로 둘러싸는 것을 잊어버렸고, 그래서 버그들을 일으켰다 하더라도, 강한 분리 때문에, 프로그래머는 종종 그러한 실수를 간단한 디버그 인터페이스를 사용하여 검출할 수 있는데, 이는 프로그래머가 원자성 위반들을 일으키는 비-트랜잭션 영역을 볼 수 있기 때문이다. 또한, 하나의 모델에 라이트된 프로그램들은 다른 모델 상에서는 다르게 동작할 수 있다.
더 나아가서, 강한 분리는 종종 약한 분리보다 하드웨어 TM에서 지원하는 것이 더 쉽다. 강한 분리 때문에, 일관성 프로토콜이 프로세서들 사이의 로드 및 스토어 통신을 이미 관리하고 있어도, 트랜잭션들은 비-트랜잭션 로드들 및 스토어들을 검출할 수 있고 적절하게 처리할 수 있다. 소프트웨어 트랜잭션 메모리(TM)에서 강한 분리를 구현하려면, 비-트랜잭션 코드는, 잠재적으로 성능에 손상을 가져오는, 리드-및 라이트 장벽들(read-and write- barriers)을 포함하도록 수정되어야 한다. 여러 불필요한 장벽들을 제거하기 위해 큰 노력을 기울여왔더라도, 그러한 기술들은 종종 복잡하고 성능은 통상적으로 HTM들의 성능보다 훨씬 떨어진다(far lower).
| 트랜잭션 메모리 설계 공간 | |||
| 버져닝 | |||
| 게으름(Lazy) | 열심(Eger) | ||
| 충 돌 검 출 |
낙관 | 라이트 버퍼에 갱신들을 저장함; 커밋 타임에 충돌을 검출함. | 실용적이지 않음: 커밋 타임까지 메모리를 갱신하는 것을 기다리지만 액세스 타임에서 충돌들을 검출하는 것은 작업을 낭비하고 아무런 장점을 제공하지 못함. |
| 비관 | 라이트 버퍼에서 갱신들을 저장하고; 액세스 타임에서 충돌들을 검출함. | 메모리를 갱신하고, 오래된 값들을 언두 로그에 유지함; 액세스 타임에서 충돌들을 검출함. | |
테이블 2는 트랜잭션 메모리의 기본 설계 공간을 도시한다(버져닝 및 충돌 검출).
열심-비관(Eager-Pessimistic)(EP)
아래에서 기술하는 이 제1 TM 설계는 열심-비관(Eager-Pessimistic)(EP)으로 알려져 있다. EP 시스템은 자신의 라이트-세트를 "제자리에(in place)"(그러므로 그 이름은 "열심(eager)"이라 한다) 저장하고, 롤백(rollback)을 지원하기 위해, "언두 로그(undo log)"에 오버라이트된(overwritten) 라인의 오래된 값들을 저장한다. 프로세서들은 리드 및 라이트를 추적하기 위해 그리고 스누프된(snooped) 로드 요청들을 수신할 때 충돌들을 검출하기 위해 W(138) 및 R(132) 캐시 비트들을 사용한다. 아마도 알려진 문헌에서의 EP시스템 중에서 가장 주목할 만한 것은 로그TM 및 UTM이다.
EP시스템에서 트랜잭션을 시작하는 것은 다른 시스템들에서 트랜잭션을 시작하는 것과 매우 유사하다: tm_begin()은 레지스터 체크포인트를 가져와서 모든 상태 레지스터들을 초기화 한다. EP 시스템은 또한 언두 로그를 초기화할 것을 요구하는데, 이것의 세부 사항들(details)은 로그 포맷에 의존하지만, 종종 로그 베이스 포인터를 미리 할당된(pre-allocated), 스레드 프라이빗 메모리(thread-private memory)의 영역으로 초기화하고, 로그 한계 레지스터(a log bounds register)를 클리어(clear)하는 것에 개입한다..
버져닝: EP에서, 열심 버져닝이 기능하도록 설계된 방식 때문에, MESI(130) 상태 이행들(state transitions)(수정(Modified), 배타(Exclusive), 공유(Shared), 및 무효(Invlid) 코드 상태들에 대응하는 캐시 라인 표시자들)은 대부분 변경되지 않은 채로 남아있다. 트랜잭션 외부에서, MESI(130) 상태 이행들은 완전히 변경되지 않은 채로 남아있다. 라인 내부 트랜잭션을 리드(read)할 때, 표준 일관성 이행들(the standard coherence transitions)은 (S(공유)→S, I(무효)→S, 또는 I→E(배타))을 적용하며, 필요한 경우 로드 미스(a load miss)를 발행하지만, R(132) 비트 또한 세트된다. 마찬가지로, 라인을 라이트(write)할 때도 표준 이행들(S→M, E→I, I→M)을 적용하며, 필요에 따라 미스를 발행하고, 또한 W(138)(라이트된) 비트를 세트한다. 라인이 최초로(the first time)라이트될 때, 전체 라인의 오래된 버전이 로드되어 언두 로그에 라이트 되는데, 이는 현재 트랜잭션이 폐기될 경우를 대비하여 그것을 보존하기 위함이다. 그 다음 새롭게 라이트되는 데이터는, 그 오래된 데이터 위에, "제자리에" 저장된다.
충돌 검출: 비관 충돌 검출(Pessimistic conflict detection)은 미스들, 또는 갱신들에 관하여 일관성 메시지들(coherence messages)을 사용하는데, 이는 트랜잭션들 사이의 충돌들을 찾기 위함이다. 트랜잭션에서 리드 미스가 발생하면, 다른 프로세서들은 로드 요청을 수신한다; 그러나 그들은 만일 그들이 필요한 라인을 갖고 있지 않다면 그 요청을 무시한다. 만일 다른 프로세서들이 필요한 라인을 비-추측으로(non-speculatively) 갖고 있거나 또는 라인 R(132)(리드)를 갖고 있다면, 그들은 그 라인을 S로 다운그레이드(downgrade) 하고, 특정 경우들에서, 만일 그들이 MESI의 130 M 또는 E 상태에서 라인을 갖고 있다면 캐시-투-캐시 트랜스퍼(a cache-to-cache transfer)를 발행한다. 그러나, 만일 캐시가 라인 W(138)를 갖고 있다면, 충돌이 두 개의 트랜잭션들 사이에서 검출되고 추가의 액션들이 취해져야 한다.
유사하게, 트랜잭션이 (최초의 라이트에서) 공유에서 수정으로 라인을 업그레이드하는 것을 추구하는 경우, 그 트랜잭션은 배타 로드 요청을 발행하는데, 이것도 또한 충돌들을 검출하기 위해 사용된다. 만일 수신하는 캐시가 라인을 비-추측으로 갖는다면, 그 라인은 무효화되고, 특정 경우들에서, 캐시-투-캐시 트랜스퍼(M 또는 E 상태들)가 발행된다. 그러나, 만일 라인이 R(132) 또는 W(138)이면, 충돌이 검출된다.
유효성 확인(Validation): 모든 로드에 관해서 충돌 검출이 수행되기 때문에, 트랜잭션은 항상 자기 자신의 라이트-세트에 대해서 배타 액세스를 갖는다. 그러므로 유효성 확인은 별도의 추가의 작업을 필요로 하지 않는다.
커밋(Commit): 열심 버져닝은 데이터 항목들의 새로운 버전을 제자리에 저장하기 때문에, 커밋 프로세스는 단순히 W(138) 및 R(132)을 클리어하고 언두 로그를 버린다(discard).
폐기(Abort): 트랜잭션이 롤백되면, 언두 로그 내의 각 캐시의 원래 버전은 복원되어야 하는데, 이 프로세스를 언두 로그 "언롤링(unrolling)" 또는 "적용하기(applying)"라 부른다. 이 프로세스는 tm_discard() 수행 동안 처리되며 다른 트랜잭션들에 관하여 원자적이어야 한다. 구체적으로, 라이트-세트는 여전히 충돌들을 검출하기 위해서 사용되어야 한다: 이 트랜잭션은 자신의 언두 로그 내 라인들 중 유일한 커렉트 버전(the only correct version)이고, 요청하는 트랜잭션들은 상기 커렉트 버전이 상기 로그로부터 복원 되기를 기다려야 한다. 그러한 로그는 하드웨어 상태 머신(a hardware state machine) 또는 소프트웨어 폐기 핸들러(software abort handler)를 사용하여 적용될 수 있다.
열심-비관(Eager-Pessimistic)은 다음의 특성을 갖는다: 커밋은 단순하고, 그것은 제자리에 위치하므로 매우 빠르다(very fast). 유사하게, 유효성 확인은 no-op이다. 비관 충돌 검출은 충돌들을 조기에 검출하고, 이에 의해서 "불운한(doomed)" 트랜잭션들의 수를 줄인다. 예를 들어, 만일 두 개의 트랜잭션들이 라이트-에프터-리드 의존성(a Write- After-Read dependency)에 개입되어 있다면, 그러한 의존성은 비관 충돌 검출에서는 즉시 검출된다. 그러나, 낙관 충돌 검출에서 그러한 충돌들은 라이터(writer)가 커밋할 때까지는 검출되지 않는다.
열심-비관(Eager-Pessimistic)은 또한 다음의 특성을 갖는다: 전술한 바와 같이, 캐시라인이 처음으로 라이트되었다면, 오래된 값은 로그에 라이트 되어야 하므로, 이는 여분의 캐시 액세스들을 발생시킨다. 폐기들은 로그를 무효로 할 것을 요구하므로 비용이 많이 든다(expensive). 각각의 캐시 라인에 대해서, 로드가 발행되어야 하고, 아마도 다음 라인으로 계속하기 전에 주 메모리까지 진행되어야 할 것이다. 비관 충돌 검출은 또한 특정의 직렬 가능한 스케줄들(certain serializable schedules)의 존재(existing)를 막는다.
추가로, 충돌들은 발생할 때 처리되기 때문에, 무한 반복(livelock) 가능성이 있고, 전진(forward progress)을 보장하려면 주의 깊은 경쟁 관리 메커니즘들이 채용되어야 한다.
게으름-낙관(Lazy-Optimistic: LO)
다른 인기 있는 TM 설계는 게으름-낙관(LO)이며, 이는 자신의 라이트-세트를 "라이트 버퍼" 또는 "리두 로그(redo log)"에 저장하고, 충돌들을 커밋 타임에 검출한다(여전히 R(132) 및 W(138) 비트들을 사용함).
버져닝(Versioning): EP 시스템과 마찬가지로, LO 설계의 MESI 프로토콜이 트랜잭션들의 외부에서 구현된다. 일단 트랜잭션 내부에서, 라인을 리드하는 것(reading)은 표준 MESI 이행들을 발생시키고 또한 R(132) 비트를 세트시킨다. 마찬가지로, 라인을 라이트 하는 것은 그 라인의 W(138) 비트를 세트하지만, LO 설계의 MESI 이행들의 처리는 EP 설계의 그것과는 다르다. 첫째, 게으름 버져닝에서, 라이트된 데이터의 새로운 버전들은 커밋될 때까지 캐시 계층에 저장되지만 한편 다른 트랜잭션들은 메모리 또는 다른 캐시들에서 이용 가능한 오래된 버전들에 대한 액세스들을 갖는다. 오래된 버전들을 이용 가능하게 하기 위해서, 트랜잭션에 의해서 처음 라이트되었을 때 더티 라인들(dirty lines)(M lines)은 퇴거되어야(evicted) 한다. 둘째, 갱신 미스들(upgrade misses)은 필요하지 않는데 이는 낙관 충돌 검출 특징 때문이다: 만일 트랜잭션이 S 상태에서 라인을 갖는다면, 그 트랜잭션은 그것에 대해서 단순히 라이트하여 그 라인을 갱신할 수 있는데 다른 트랜잭션들과 그 변경들을 통신함이 없이 할 수 있으며, 그 이유는 충돌 검출이 커밋 타임에 행해지기 때문이다.
충돌 검출 및 유효성 확인(Conflict Detection and Validation): 트랜잭션의 유효성을 확인하고 충돌들을 검출하기 위해서, LO은 다른 트랜잭션들에 대해 추측으로 수정된 라인들의 어드레스들(the addresses of speculatively modified lines)을 통신하는데 LO이 커밋하는 것을 준비하고 있을 때만 한다. 유효성 확인을 위해, 프로세서는 라이트-세트 내 모든 어드레스들을 포함하는 하나의, 잠재적으로 큰, 네트워크 패킷을 내보낸다. 데이터는 내보내지 않고 커미터(committer)의 캐시 내에 남겨두고 더티(dirty)(M)로 마크한다. W로 마크된 라인들을 위해 캐시를 탐색함이 없이 이 패킷을 구축하기 위해서, 단순한 비트 벡터가 이용되는데, 이를 "스토어 버퍼(store buffer)"라 부르며, 이들 추측으로 수정된 라인들을 추적하기 위해 캐시 라인 당 하나의 비트가 사용된다. 다른 트랜잭션들은 이 어드레스 패킷을 충돌들을 검출하기 위해 사용한다: 만일 하나의 어드레스가 캐시 내에서 발견되고 R(132) 및/또는 W(138) 비트들이 세트 되었다면, 하나의 충돌이 시작된 것이다. 만일 그 라인이 발견되었지만 R(132) 또는 W(138) 어느 것도 세트되어 있지 있다면, 그 라인은 단순히 무효화된 것이고, 이는 배타 로드(exclusive load)를 처리하는 것과 유사하다.
트랜잭션 원자성을 지원하기 위해서, 이들 어드레스 패킷들은 원자적으로 처리되어야 하는데, 즉 두 개의 어드레스 패킷들이 동일 어드레스들과 동시에 존재할 수 없다. LO 시스템에서, 이것은 어드레스 패킷을 내보내기 전에 단순히 글로벌 커밋 토큰(a global commit token)을 획득함으로써 달성될 수 있다. 그러나, 먼저 어드레스 패킷을 내보내고, 응답들을 수집하며, 정리 프로토콜(an ordering protocol)(아마도 가장 오래된 트랜잭션을 먼저 하는)을 실시하고, 그리고 일단 모든 반응들이 만족스럽다면 커밋함으로써, 2-단계 커밋 계획(a two-phase commit scheme)도 채용될 수 있을 것이다
커밋(Commit): 일단 유효성 확인이 이루어졌다면, 커밋은 특별한 취급이 필요 없다: 단순히 W(138) 및 R(132) 비트들과 스토어 버퍼를 클리어하면 된다. 트랜잭션의 라이트들은 캐시 내에서 이미 더티(dirty)로 마크되었고 그리고 이들 라인들의 다른 캐시들의 복사본들도 주소 패킷을 통해서 무효화 되었다. 그 다음 다른 프로세서들은 정규 일관성 프로토콜을 통해 커밋된 데이터에 액세스할 수 있다.
폐기(Abort): 롤백(Rollback)도 똑같이 쉽다: 라이트-세트가 로컬 캐시들 내에 포함되어 있기 때문에, 이들 라인들은 무효화될 수 있고, 그 다음에 W(138) 및 R(132) 비트들과 스토어 버퍼를 클리어할 수 있다. 스토어 버퍼는 캐시를 탐색할 필요 없이 무효화 하기 위해 W 라인들이 발견될 수 있게 해 준다.
게으름-낙관(Lazy-Optimistic)은 다음의 특성을 갖는다: 폐기들이 매우 빠르고, 추가의 로드나 스토어를 요구하지 않으며, 오직 로컬 변경들만 만든다. EP에서 발견되는 것보다 더 직렬화 가능한 스케줄들(More serializable schedules)이 존재할 수 있고, 이는 LO 시스템이 트랜잭션이 독립적이라는 것을 더 공격적으로 예측할 수 있도록 해주며, 이는 더 높은 성능을 달성할 수 있게 한다. 결국, 충돌들을 늦게 검출하는 것이 전진의 가능성(the likelihood of forward progress)을 증가시킬 수 있다.
게으름-낙관은 또한 다음의 특성을 갖는다: 유효성 확인은 라이트-세트의 사이즈에 비례하는 글로벌 통신 시간을 요구한다. 불운한 트랜잭션들은 작업을 낭비할 수 있는데, 이는 충돌들이 오직 커밋 타임에만 검출되기 때문이다.
게으름-비관(Lazy-Pessimistic: LP)
게으름-비관(LP)은 제3의 TM 설계 선택을 나타내는데, EP와 LO 사이의 어딘가에 위치한다: 새롭게 라이트된 라인들을 라이트 버퍼에 저장하지만 충돌들의 검출은 액세스 당 기초로(on a per access basis) 한다.
버져닝(Versioning): 버져닝은 유사하지만 LO의 그것과 동일하지는 않다: 라인을 리드하는 것은 자신의 R 비트(132)를 세트하고, 라인을 라이트하는 것은 자신의 W 비트(138)를 세트하며, 그리고 스토어 버퍼는 캐시에서 W 라인들을 추적하기 위해 사용된다. 또한, 더티(M) 라인들은, LO에서와 같이, 트랜잭션에 의해서 처음으로 라이트될 때 퇴거되어야(evicted) 한다. 그러나, 충돌 검출이 비관적이기 때문에, LO에서와 달리, I, SM으로부터 트랜잭션 라인을 업그레이드 할 때 로드 배타들(load exclusives)이 수행되어야 한다
충돌 검출(Conflict Detection): LP의 충돌 검출은 EP의 충돌 검출과 동일하게 이루어진다: 일관성 메시지들을 사용하여 트랜잭션들 사이에서 충돌들을 찾는다.
유효성 확인(Validation): EP에서와 마찬가지로, 비관 충돌 검출은 어느 시점에서도(at any point), 하나의 러닝 트랜잭션(a running transaction)은 다른 어떠한 러닝 트랜잭션과도 충돌을 갖지 않음을 보장하며, 그래서 유효성 확인은 노-오피(a no-op)이다.
커밋(Commit): 커밋은 특별한 취급이 필요 없다; LO에서와 같이, W(138) 및 R(132) 그리고 스토어 버퍼를 단순히 클리어하면 된다.
폐기(Abort): 롤백(Rollback)은 또한 LO의 경우와 같다: 스토어 버퍼를 사용하여 라이트-세트를 단순히 무효화하고 그리고 W 및 R 비트들과 스토어 버퍼를 클리어하면 된다.
열심-낙관(Eager-Optimistic: EO)
LP는 다음과 같은 특성을 갖고 있다: LO와 마찬가지로, 폐기들의 처리는 매우 빠르다. EP와 마찬가지로, 비관 충돌 검출을 사용하면 "불운한" 트랜잭션들의 수를 줄일 수 있다. EP와 마찬가지로, 일부 직렬화 가능한 스케줄들은 허용되지 않으며, 충돌 검출은 각각의 캐시 미스에 대해서 수행되어야 한다.
버져닝과 충돌 검출의 최종 조합은 열심-낙관(EO)이다. E0은 HTM 시스템들을 위한 최적 선택보다는 덜한(less) 선택일 수 있다: 새로운 트랜잭션 버전들이 제-자리에 라이트 되기 때문에, 다른 트랜잭션들은 충돌들이 발생하면(즉, 캐시 미스들이 발생하면) 그들을 통지하는 것 외에 다른 선택이 없다. 그러나, EO는 충돌들을 검출하기 위해 커밋 타임까지 기다리기 때문에, 이들 트랜잭션들은 "좀비들(zombies)"이 되어, 실행을 계속하므로, 자원들을 낭비하지만, 그럼에도 폐기되는 "불운한(doomed)" 운명에 처하게 된다.
EO은 STM들에서 유용하다는 것이 증명되었고 Bartok-STM 및 McRT에 의해서 구현된다. 게으름 버져닝 STM(a lazy versioning STM)은 가장 최근 값을 리드한다는 것을 보장하기 위해 각각의 리드에 대해서 자신의 라이트 버퍼를 확인할 필요가 있다. 라이트 버퍼는 하드웨어 구조가 아니기 때문에―하드웨어 구조로 하면 비싸짐―, 제자리에 라이트하는 열심 버져닝(write-in-place eager versioning)이 선호된다. 추가적으로, 충돌들을 확인하는 것은 STM에서는 또한 비용이 많이 드는 것이므로, 낙관 충돌 검출은 이 연산을 벌크로 수행하는 장점을 제공한다.
경쟁 관리(Contention Management)
일단 시스템이 트랜잭션을 폐기하기로 결정한 후 그 트랜잭션을 어떻게 롤백하는지에 관하여 위에서 기술하였지만, 충돌은 두 개의 트랜잭션들과 관련이 있으므로, 어느 트랜잭션이 폐기되어야 하는지, 그 폐기가 어떻게 개시되어야 하는지, 그리고 그 폐기된 트랜잭션은 언제 재시도가 되어야 하는지에 관한 주제는 탐구될 필요가 있다. 이들은 트랜잭션 메모리의 핵심 컴포넌트인, 경쟁 관리(CM)에 의해서 해결되어야 하는 주제이다. 시스템이 폐기들을 어떻게 개시하는지에 관한 정책들(policies) 그리고 충돌에서 어떤 트랜잭션들이 폐기되어야 하는지를 관리하는 다양하게 확립된 방법들을 아래에서 기술한다.
경쟁 관리 정책들(Contention Management Policies)
경쟁 관리(CM) 정책은 충돌에 관련된 트랜잭션에서 어느 것을 폐기하고 그리고 그 폐기된 트랜잭션을 언제 재시도해야 하는지를 결정하는 메커니즘이다. 예를 들면, 폐기된 트랜잭션을 즉시 재시도하는 것은 종종 최상의 결과(best performance)를 가져오지 못한다. 반대로, 폐기된 트랜잭션의 재시도를 지연시키는, 백-오프 메커니즘(a back-off mechanism)을 채용하는 것이 더 나은 결과를 달성할 수도 있다. 최선의 경쟁 관리 정책들을 발견하기 위해 STM들이 최초로 고심하였고(first grappled) 아래에서 기술된 정책들 중 많은 것들이 원래는 STM들을 위해 개발되었던 것이다.
CM 정책들은 결정들을 내리기 위해서 많은 측정들(a number of measures)을 활용하는데, 그들에는 트랜잭션들의 수명(ages of the transactions), 리드- 및 라이트-세트들의 사이즈(size of read- and write-sets), 이전에 일어난 폐기들의 횟수(the number of previous aborts), 등이 포함된다. 그러한 결정들을 내리기 위한 측정들의 조합은 끝이 없지만, 특정 조합들을, 간략하게 복잡성이 큰 순서로, 아래에서 기술한다.
일부 용어(nomenclature)를 확립하기 위해, 충돌에는 두 개의 측면들: 공격자(the attacker) 및 방어자(the defender)가 있음을 먼저 주목해야 한다. 공격자는 공유된 메모리 위치에 대한 액세스를 요청하는 트랜잭션이다. 비관 충돌 검출에서, 공격자는 로드 또는 로드 배타(load exclusive)를 발행하는 트랜잭션이다. 낙관 충돌 검출에서, 공격자는 유효성 확인을 시도하는 트랜잭션이다. 비관 충돌 검출 및 낙관 충돌 검출 모두에서, 방어자는 공격자의 요청을 수신하는 트랜잭션이다.
공격적 CM 정책(Aggressive CM Policy)에서 공격자 또는 방어자는 어느 쪽이든지 즉시 그리고 항상 재시도한다. LO에서, 공격적이라는 말은 공격자가 항상 이긴다(win)라는 것을 의미하고, 그래서 공격적이라 함은 때때로 커미터(committer)가 이긴다라는 의미로 사용된다. 그러한 정책은 가장 초기의 LO 시스템들에서 사용되었다. EP의 경우에, 공격적이라는 말은 방어자가 이긴다는 의미로 또는 공격자가 이긴다는 의미로 어느 쪽이든지 사용될 수 있다.
즉시 다른 충돌을 경험할 수 있는 충돌 트랜잭션을 재시작하는 것은 작업 ― 즉, 캐시 미스들을 리필하는(refilling) 인터커넥트 대역폭 ― 을 낭비할 가능성이 크다. 정중한 CM 정책(Polite CM Policy)은 충돌들을 재시작하기 전에 지수의 백오프(exponential backoff)(그러나 선형(linear) 또한 사용될 수 있음)를 채용한다. 프로세스(a process)가 스케줄러에 의해서 자신에 할당된 자원들을 갖지 못하는 상황, 즉 기아(starvation)를 방지하기 위해서, 지수의 백오프는 일부 n 재시도들 후의 트랜잭션 성공의 가능성(the odds)을 대단히 높여 준다.
충돌 해결에 대한 다른 접근 방식은 공격자 또는 방어자를 임의로(randomly) 폐기하는 것이다(이를 임의화된 정책(a policy called randomized)이라 한다). 그러한 정책은 불필요한 경쟁을 피하기 위해 임의화된 백오프 방식(a randomized backoff scheme)과 조합될 수 있다.
그러나, 폐기할 트랜잭션을 선택할 때, 임의로 선택하면, "많은 작업(a lot of work)"을 완료한 트랜잭션들을 폐기하는 경우를 초래할 수 있는데, 이는 자원들을 낭비할 수 있다. 그러한 낭비를 피하기 위해서, 어느 트랜잭션을 폐기할 것인지를 결정할 때 트랜잭션에서 완료된 작업의 양이 고려될 수 있다. 작업의 한가지 측정은 트랜잭션의 수명(a transaction's age)이 될 수 있다. 기타 방법들에는 올디스트(Oldest), 벌크TM(Bulk TM), 사이즈 매터즈(Size Matters), 카르마(Karma), 및 폴카(Polka)가 포함된다. 올디스트는 충돌에서 더 젊은 트랜잭션(the younger transaction)을 폐기하는 단순한 타임스탬프 방법(a simple timestamp method)이다. 벌크 TM은 이 방법을 사용한다. 사이즈 매터즈는 올디스트와 비슷하지만, 트랜잭션 수명 대신에, 리드/라이트된 워드들의 수가 우선순위(the priority)로서 사용되고, 일정 수의 폐기들이 된 이후에는 올디스트로 복귀한다(revert). 카르마도, 유사하며, 라이트-세트의 사이즈를 우선순위로 사용한다. 롤백은 일정 시간이 지난 후 진행된다. 폐기된 트랜잭션들은 폐기된 후에도 우선순위를 유지한다(그러므로 그 이름이 카르마이다). 폴카도 카르마와 비슷하게 작동하지만 미리 정의된 시간 동안 백오프하는 대신 매번 더 지수적으로 백오프한다.
폐기하는 것은 작업을 낭비하는 것이기 때문에, 방어자가 트랜잭션을 완료할 때까지 공격자를 지연시키는 것(stalling)이 더 좋은 결과를 가져올 것이라고 주장하는 것이 논리적일 것이다. 불행하게도, 그러한 단순한 방법은 쉽게 데드락(deadlock)으로 이어질 수 있다.
데드락 회피 기술들(Deadlock avoidance techniques)이 이 문제를 해결하기 위해 사용될 수 있다. 그리디(Greedy)는 데드락을 피하기 위해 두 가지 규칙들을 사용한다. 첫 번째 규칙은, 만일 제1 트랜잭션, T1이 제2 트랜잭션, T0보다 더 낮은 우선순위를 갖고 있거나, 또는 만일 T1이 다른 트랜잭션을 기다리고 있다면, T0과 충돌하는 때 T1은 폐기한다. 두 번째 규칙은 만일 T1이 T0보다 더 높은 우선순위를 가지고 있고 다른 트랜잭션을 기다리고 있지 않다면, T0은 T1이 커밋, 폐기 또는 기다림을 다시 시작할 때까지 기다린다(기다림을 다시 시작하는 경우에는 첫 번째 규칙이 적용된다). 그리디는 한 세트의 트랜잭션들을 실행하기 위한 시간 한계(time bounds)에 관한 보장을 제공한다. 하나의 EP 설계(로그TM)는 보수적인 데드락 회피를 달성하기 위해 그리디와 유사한 CM 정책을 사용한다.
예시적인 MESI 일관성 규칙들(Example MESI coherency rules)은 멀티프로세서 캐시 시스템의 캐시라인이 상주할 수 있는 4개의 가능한 상태들, M, E, S, 및 I를 제공하는데, 이들에 대한 정의는 다음과 같다:
수정(Modified: M): 캐시 라인은 오직 현재 캐시에만 존재하고, 그리고 더티(dirty)이다; 이는 주 메모리 내의 값으로부터 수정된다. 이 캐시는, (더 이상 유효하지 않은) 주 메모리 상태의 다른 어떠한 리드를 허용하기 전에, 미래에 언젠가 주 메모리에 데이터를 라이트-백하기 위해 필요하다. 상기 라이트-백은 상기 라인을 배타 상태로 변경한다.
배타(Exclusive: E): 캐시 라인은 오직 현재 캐시에만 존재하지만, 클린(clean)이다; 그것은 주 메모리와 일치한다(match). 그것은, 리드 요청에 응답하여, 언제든지 공유 상태(Shared state)로 변경될 수 있다. 이와 달리, 그 것에 대해 라이트가 있을 때 그것은 수정 상태(the Modified state)로 변경될 수 있다.
공유(Shared: S): 이 캐시 라인이 머신의 다른 캐시들에도 저장될 수 있고 "클린"임을 표시한다; 그것은 주 메모리와 매치된다. 이 캐시 라인은 언제든지 버려질 수 있다(무효 상태로 변경된다).
무효(Invalid: I): 이 캐시 라인이 무효(사용되지 않음)임을 표시한다.
TM 일관성 상태 표시자들(TM coherency status indicators)(R 132, W 138)은 각각의 캐시 라인에 대해 제공될 수 있거나, 이에 더하여, 또는 MESI 일관성 비트들 내에 인코드될(encoded) 수 있다. R(132) 표시자는 현재 트랜잭션이 캐시 라인의 데이터로부터 리드를 갖고 있음을 표시하고, W(138) 표시자는 현재의 트랜잭션이 캐시 라인의 데이터에 대해 라이트 되었음을 표시한다.
TM 설계의 다른 실시 예로서, 트랜잭션 스토어 버퍼들을 사용하여 설계된 시스템이 있다. 2000년 3월 31일 출원되고, 여기서 전체로서 참조로 포함된, "마이크로프로세서 컴퓨터 시스템에서 메모리 참조들을 재정리하고 재 명명하기 위한 방법들 및 장치들(Methods and Apparatus for Reordering and Renaming Memory References in a Multiprocessor Computer System )"이라는 제목의 미국 특허 번호 6,349,361은 적어도 제1 및 제2 프로세서를 갖는 마이크로프로세서 컴퓨터 시스템에서 메모리 참조들을 재정리하고 재명명하기 위한 방법을 보여준다. 제1 프로세서는 제1 프라이빗 캐시(a first private cache) 와 제1 버퍼를 갖고, 제2 프로세서는 제2 프라이빗 캐시와 제2 버퍼를 갖는다. 상기 방법은, 하나의 데이터를 저장하기 위해 제1 프로세서에 의해서 수신된 복수의 게이트된(gated) 저장 요청들 각각에 대하여, 연산들을 포함하고, 상기 연산들은 상기 데이터를 포함하는 캐시 라인을 제1 프라이빗 캐시에 의해서 배타적으로 획득하고, 상기 데이터를 상기 제1 버퍼에 저장한다. 특정 데이터를 로드하기 위한 로드 요청을 제1 프로세서로부터 제1 버퍼가 수신하면, 상기 데이터는 로드 및 스토어 연산들의 적절한 시퀀스에 기초하여 제1 버퍼에 저장된 데이터들 가운데에서 제1 프로세서로 제공된다. 제1 캐시가 주어진 데이터에 대한 로드 요청을 제2 캐시로부터 수신한 경우, 상기 주어진 데이터에 대한 로드 요청이 제1 버퍼에 저장된 데이터에 해당하는 때에는, 에러 조건이 표시되고 프로세서들 중 적어도 하나의 현재 상태는 이전의 상태(an earlier state)로 리셋된다.
트랜잭션 메모리 퍼실리티의 주된 구현 컴포넌트들(The main implementation components of one such transactional memory facility)은 사전-트랜잭션 GR(범용 레지스터) 내용(pre-transaction GR (general register) content)을 저장하기 위한 트랜잭션-백업 레지스터 파일(a transaction-backup register file), 트랜잭션 동안 액세스되는 캐시 라인들을 추적하기 위한 캐시 디렉토리(a cache directory), 트랜잭션이 종료될 때까지 저장들을 버퍼하기 위한 저장 캐시(a store cache), 그리고 다양하고 복잡한 기능들을 수행하기 위한 펌웨어 루틴들(firmware routines)이다. 이 섹션에서는 상세한 구현에 관하여 기술한다.
IBM z엔터프라이즈 EC12 엔터프라이즈 서버 실시 예(IBM zEnterprise EC12 Enterprise Server Embodiment)
IBM z엔터프라이즈 EC12 엔터프라이즈 서버는 트랜잭션 메모리 내에 트랜잭션 실행(TX)을 도입하는데, 이는 다음 논문에 일부가 기술되어 있다. 이 논문은, 2012년 12월 1-5일, 밴쿠버, 브리티시 콜럼비아, 캐나다, 마이크로-45에서 제공된 프리시딩 페이지 25-26에 발표된 "IBM 시스템 z를 위한 트랜잭션 메모리 아키텍처 및 구현(Transactional Memory Architecture and Implementation for IBM System z)"이고, 이는 IEEE 컴퓨터 협회 콘퍼런스 퍼블리싱 서비스(CPS)로부터 이용 가능하며, 여기서 전체로서 참조로 포함되었다.
표 3은 예시적인 트랜잭션을 보여준다. TBEGIN으로 시작되는 트랜잭션들이 TEND로 언제나 성공적으로 완료될 것이라는 보장은 없다. 왜냐하면 그들은, 예를 들어, 다른 CPU들과의 반복되는 충돌들로 인하여, 매번 시도되는 실행에서 폐기 조건(an aborting condition)을 경험할 수 있기 때문이다. 이것은 프로그램이, 예를 들어 전통적인 로킹 방법들(traditional locking schemes)을 사용함에 의해서, 동일 연산을 비-트랜잭션으로서 수행하기 위한 폴백 경로(a fallback path)를 지원할 것을 요구한다. 이것은 프로그래밍 및 소프트웨어 검증 팀들(the programming and software verification teams)에게 심각한 부담을 주는데, 특히 폴백 경로가 신뢰할 수 있는 컴파일러에 의해서 자동으로 생성되지 않을 경우 그러하다.
| 예시적인 트랜잭션 코드 |
| LHI R0,0 *재시도 카운트=0으로 초기화함 loop TBEGIN * 트랜잭션을 시작함 JNZ abort * 만일 CC1=0이면 코드를 폐기함 LT R1,lock * 폴백 락을 로드하고 테스트함 JNZ lckbzy * 만일 락이 비지이면 분기함. … 연산 수행함 … TEND * 트랜잭션을 종료함 … … … … lckbzy TABORT * 만일 락이 비지이면 폐기함; 이것은 * TBEGIN 후에 재개함 abort JO fallback * 만일 CC=3이면 재시도 없음 AHI R0,1 * 제시도 카운트를 증가시킴 CIJNL R0,6,fallback * 6번 시도 후 포기함 PPA R0,TX * 재시도 카운트에 기초하여 임의로 지연함 … 락이 프리로 되는 것을 잠재적으로 기다림 … J loop * 재시도 폴백으로 점프함 OBTAIN lock * Compare&Swap을 사용함. … 연산 수행함 … RELEASE lock … … … … |
폐기된 트랜잭션 실행(TX) 트랜잭션들(aborted Transaction Execution (TX) transactions)에 대해 폴백 경로를 제공하는 것의 요건은 어려운(onerous) 것일 수 있다. 공유 데이터 구조들 상에서 처리되는 많은 트랜잭션들은 짧고(short), 구별되는 메모리 위치들은 적게 터치하고(touch only a few distinct memory locations), 그리고 단순한 명령들만 사용하는 것이 기대된다. 이들 트랜잭션들을 위해, IBM z엔터프라이즈 EC12는 제한된 트랜잭션들(constrained transactions)의 개념을 도입한다; 정상 조건들 하에서는, CPU(114)는 필요한 재시도들의 수에 엄격한 제한을 주는 일 없이 확실하게 제한된 트랜잭션들이 궁극적으로 성공적으로 종료되게 한다. 제한된 트랜잭션은 TBEGINC 명령으로 시작하고 정규의 TEND로 종료한다. 작업(a task)을 제한된 또는 비-제한된 트랜잭션으로서 구현하는 것은 통상적으로 매우 비교할만한 결과(very comparable performance)를 가져오지만, 제한된 트랜잭션들은 폴백 경로에 대한 필요를 제거함으로써 소프트웨어 개발을 단순화한다. IBM의 트랜잭션 실행 아키텍처는 2012년 9월 IBM이 발표한 SA22-7832-09의 10판의 "z/아키텍처, 연산 원리들(z/Architecture, Principles of Operation)"에서 더 상세히 기술되어 있으며, 여기서 전체로서 참조로 포함된다.
제한된 트랜잭션은 TBEGINC 명령으로 시작한다. TBEGINC으로 개시된 트랜잭션은 프로그래밍 제한들의 목록(a list of programming constraints)을 따라야 한다; 그렇지 않으면, 프로그램은 걸러낼 수 없는 제한-위반 인터럽션(a non-filterable constraint-violation interruption)을 취하게 된다. 제한들의 예들은 다음과 같으며, 이에 한정되지는 않는다: 트랜잭션은 최대 32 명령들을 실행할 수 있으며, 모든 명령문은 메모리의 256 연속 바이트들 이내 이어야 한다; 트랜잭션은 오직 포워드-포인팅 상대 분기들만(only forward-pointing relative branches) 포함해야 한다(즉, 루프들 또는 서브루틴 콜들이 없어야 한다); 트랜잭션은 최대 메모리의 4 정렬된 옥토워드들(4 aligned octowords)(한 옥토워드는 32바이트이다)을 액세스 할 수 있다; 그리고 십진 또는 부동소수점 연산들과 같은 복잡한 명령들을 배제하기 위해 명령-세트의 제한이 있다. 제한들은 이중으로 링크된 목록-삽입/삭제 연산들(doubly linked list-insert/delete operations)과 같은 많은 보통의 연산들이 수행될 수 있도록 선택되며, 4 정렬된 옥토워드들을 목표로 하는 원자의 비교-및-교환(atomic compare-and-swap)의 대단히 강력한 개념을 포함한다. 동시에, 제한들은 미래의 CPU 구현들이 제한들을 조정할 필요 없이 트랜잭션 성공을 달성할 수 있도록 보수적으로 선택되는데, 그렇게 하지 않을 경우 소프트웨어 호환성이 달성될 수 없기 때문이다.
TBEGINC는, 부동 소수점 레지스터(FPR) 제어 및 프로그램 인터럽션 필터링 필드들(the program interruption filtering fields)이 존재하지 않는다는 점과, 제어들(the controls)은 0이 되는 점을 제외하고, 대개 TSX에서의 XBEGIN 또는 IBM의 zEC 12 서버들 상의 TBEGIN과 같은 기능을 수행한다(behave). 트랜잭션 폐기가 있는 경우, 명령 어드레스는 다음 명령으로 세트되는 대신에, TBEGINC에 직접적으로 돌아가게 세트되는데, 이것은 즉각적인 재시도(the immediate retry)와 제한된 트랜잭션들에 대한 폐기 경로의 부재(absence of an abort path for constrained transactions)를 반영한다.
내포된 트랜잭션들(Nested transactions)은 제한된 트랜잭션들 내에서는 허용되지 않지만, 만일 비-제한 트랜잭션 내에서 TBEGINC이 발생한다면 그것은 TBEGIN이 그랬던 것과 같이 새로운 비-제한 내포 수준(a new non-constrained nesting level)을 여는 것(opeing)으로서 취급된다. 이것은, 예를 들어, 만일 비-제한 트랜잭션이 제한된 트랜잭션을 내부적으로 사용하는 서브루틴을 호출한다면, 발생될 수 있다.
인터럽션 필터링(interruption filtering)이 전혀 없기 때문에(implicitly off), 제한된 트랜잭션 동안의 모든 예외들(all exceptions)은 운영 체제(OS)로 보내지는 인터럽션을 초래한다. 트랜잭션의 성공적 완료는 궁극적으로 임의의 제한된 트랜잭션에 의해서 터치되는 기껏해야 4 페이지(the at most 4 pages)의 페이지-인을 하는(page-in) OS의 능력에 의존하게 된다. OS는 또한 트랜잭션이 완료되는 것을 허용할 만큼 충분히 긴 시간 동안의 타임-슬라이스들(time-slices)을 보장해야 한다.
| 트랜잭션 코드 예 |
| TBEGINC * 제한된 트랜잭션을 시작함 … 연산을 수행함 … TEND * 트랜잭션을 종료함 |
표 4는 표 3에서 코드의 제한된-트랜잭션 구현을 보여주며, 이는 제한된 트랜잭션들이 다른 로킹-기반 코드(other locking-based code)와 상호작용하지 않는다는 것을 가정한다. 그러므로 락 테스팅(lock testing)은 도시되지 않았다. 그러나 이것은 만일 제한된 트랜잭션들과 락-기반 코드가 혼합된다면 추가될 수 있다.
실패가 반복적으로 발생하는 경우, 시스템 펌웨어의 일부인 밀리코드(millicode)를 사용하여 소프트웨어 에뮬레이션(software emulation)이 수행된다. 제한된 트랜잭션들은 프로그래머들에게서 부담을 제거해 주기 때문에 바람직한 특성들을 갖는 장점이 있다
도 3을 참조하면, IBM z엔트프라이즈 EC12 프로세서는 트랜잭션 실행 퍼실리티(transactional execution facility)를 도입하였다. 이 프로세서는 클록 사이클 당 3개의 명령들을 디코드할 수 있다; 단순한 명령들은 단일 마이크로-오피들(single micro-ops)로서 파견되고(dispatched), 그리고 더 복잡한 명령들은 다수의 마이크로-오피들로 쪼개진다(cracked). 마이크로-오피들(Uops)(232b)은 통합된 이슈 큐 (a unified issue queue)(216)로 라이트되는데, 여기서 문제가 발생할 수 있다. 두 개의 고정 소수점(two fixed-point), 하나의 부동 소수점(one floating-point), 두 개의 로드/스토어(two load/store), 그리고 두 개의 분기 명령들(two branch instructions)까지는 모든 사이클(every cycle)에서 실행할 수 있다. 글로벌 완료 테이블(Global Completion Table:GCT)(232)는 모든 마이크로-오피 및 트랜잭션 내포 깊이(a transaction nesting depth: TND)(232a)를 보유한다. GCT(232)는 디코드 타임에 순서대로 라이트되고, 각각의 마이크로-오피(232b)의 실행 상태를 추적하며, 가장 오래된 명령 그룹의 모든 마이크로-오피들(232b)이 성공적으로 실행되었을 때 명령들은 완료된다.
레벨 1(L1) 데이터 캐시(240)는 256 바이트 캐시-라인들 및 4 사이클 사용 대기 기간(cycle use latency)을 갖는 96KB(킬로-바이트) 6-웨이(way) 연관 캐시(associative cache)이고, 이는 L1(240) 미스들을 위해 7 사이클 사용-대기 기간 페널티를 갖는 프라이빗 1MB(메가바이트) 8-웨이 연관 제2-레벨(L2) 데이터 캐시(268)에 결합된다. L1(240) 캐시는 프로세서에 가장 근접한 캐시이고 그리고 Ln 캐시는 캐싱의 n번째 위치한 캐시이다. L1(240) 및 L2(268) 캐시들은 스토어-스루(store-through)이다. 각각의 중앙 프로세서(CP) 칩 상의 6개의 코어들은 48MB 제3-레벨 스토어-인 캐시(a 48MB 3rd-level store-in cache)를 공유하고, 그리고 6개의 CP 칩들은 오프-칩 384MB 제4-레벨 캐시(an off-chip 384MB 4th-level cache)에 접속되며, 이들은 글라스 세라믹 멀티-칩 모듈(a glass ceramic multi-chip module: MCM) 상에 서로 패키지 된다. 4 개의 멀티-칩 모듈들(MCM들)까지 144개의 코어들(모든 코어들이 고객 워크로드(customer workload)를 실행하는 데 이용 가능하지는 않음)까지 가질 수 있는 일관된 대칭 멀티-프로세서(a coherent symmetric multi-processor: SMP) 시스템에 접속될 수 있다.
일관성(Coherency)은 MESI 프로토콜의 변종(a variant of the MESI protocol)으로 관리 된다. 캐시-라인들은 판독-전용으로(read only)(공유) 또는 배타(exclusive)적으로 소유될 수 있다; L1(240) 및 L2(268)는 스토어-스루이고, 따라서 더티 라인들은 포함하지 않는다. L3(272) 및 L4 캐시들(도시되지 않음)은 스토어-인(store-in)이고 더티 상태들(dirty states)을 추적한다. 각각의 캐시는 모든 자신의 연결된 더 낮은 레벨의 캐시들을 포함한다.
일관성 요청들은 "교차 질문들(cross interrogates)"(XI)이라 불리우며, 더 높은 레벨의 캐시들에서 더 낮은 레벨의 캐시들로 계층적으로, 그리고 L4들 사이로 보내진다. 하나의 코어가 L1(240) 및 L2(268)를 미스하고 자신의 로컬 L3(272)으로부터 캐시 라인을 요청하였을 때, L3(272)은 자신이 그 라인을 소유하고 있는지를 확인하고, 그리고 필요한 경우 그것이 요청자에게 그 캐시 라인을 리턴(returen)하기 전에 일관성을 확인하기 위해 L3(272) 하에서 현재 소유하는(currently owning) L2(268)/L1(240)으로 XI를 보낸다. 만일 그 요청이 또한 L3(272)을 미스한다면, L3(272)은 요청을 L4(도시하지 않음)로 보내는데, 이는 L4 하에서 모든 필요한 L3들에게, 그리고 이웃하는 L4들에게 XI들을 보냄으로써 일관성을 강제한다. 그 다음 L4는 요청하는 L3에게 응답을 보내고, L3은 응답을 L2(268)/L1(240)에 전송한다.
여기서 주목할 것은 캐시 계층의 포용 규칙(the inclusivity rule of the cache hierarchy)으로 인하여, 때때로 캐시 라인들은 하위-레벨 캐시들(lower-level cashes)로부터 XF된다(XFed)는 점이며, 이는 다른 캐시 라인들에 대한 요청들로부터 연관성 오버플로들(associativity overflows)에 의해 야기된 상위-레벨의 캐시들(higher-level cashes) 상의 퇴거들(evictions) 때문이다. 이들 XI들은 "LRU XI들"이라 불리 울 수 있으며, 여기서 LRU는 최근에 가장 적게 사용된(least recently used)을 의미한다.
XI 요청들의 또 다른 종류에 대해서 설명하면, 강등-XI들(Demote-XIs)은 캐시-소유를 배타 상태(exclusive state)로부터 판독-전용 상태(read-only state)로 이행하고(transition), 배타-XI들(Exclusive-XIs)은 캐시 소유를 배타 상태로부터 무효 상태(invalid state)로 이행한다. 강등-XI들 및 배타-XI들은 XI 센더(the XI sender)에게 돌려줄 응답이 필요하다. 타겟 캐시가 XI를 수용(accept)하기 전에 먼저 더티 데이터를 퇴거시킬(evict) 필요가 있으면 타겟 캐시는 XI를 "수용"하거나, 또는 "거절(reject)"하는 응답을 내보낼 수 있다. L1(240)/L2(268) 캐시들은 스토어 스루(store through)이지만, 만일 그들이 배타 상태를 다운그레이드 하기 전에 L3로 보내져야 할 필요가 있는 저장들(stores)을 그들의 스토어 큐들에 가지고 있다면, 강등-XI들 및 배타 XI들을 거절할 수 있다. 거절된 XI는 센더(sender)에 의해서 반복된다. 판독-전용 XI들은 판독-전용 라인(the line read-only)을 소유하는 캐시들에게 보내진다; 그들은 거절될 수 없기 때문에 그러한 XI들에 대해서는 응답이 필요하지 않다. SMP 프로토콜의 상세 사항들은, 여기서 전체가 참조로 포함된, 피. 마크(P. Mak), 씨. 월터즈(C. Walters), 및 지. 스트레이트(G. Strait)가, 2009년, 연구 및 개발에 관한 IBM 저널, Vol 53:1에서 발표한, "IBM 시스템 z10 프로세서 캐시 서브시스템 마이크로아키텍처"에서 소개한 IBM z10에 대해서 기술한 것과 유사하다.
트랜잭션 명령 실행(Transactional Instruction Execution)
도 3은 CPU(114) 및 그것과 상호 작용하는 캐시들/컴포넌트들(도 1 및 2에서 묘사했던 것과 같은)을 포함하는 CPU 환경의 예(112)의 컴포넌트들의 예를 묘사한다. 명령 디코드 유닛(208)(IDU)은 현재 트랜잭션 내포 깊이(the current transaction nesting depth)(212)(TND)를 추적한다. IDU(208)가 TBEGIN 명령을 수신하면, TND(212)는 증가되고(incremented), 반대로 TEND 명령들 상에서는 감소된다(decremented). TND(212)는 모든 파견된 명령(every dispatched instruction)을 위해 GCT(232) 내에 라이트된다(written). TBEGIN 또는 TEND가 나중에 방출되는(get flushed) 예측 경로(a speculative path) 상에서 디코드 되면, IDU(208)의 TND(212)는 아직 방출되지 않은 최신의 GCT(232) 엔트리로부터 리프레시된다(refreshed). 트랜잭션 상태는 또한 발행 큐(issue queue)(216) 내에 라이트되는데, 이는 실행 유닛들, 대부분은, 내부에 또한 효과적인 어드레스 계산기를 가지고 있는, 로드/스토어 유닛(LSU)(280)에 의해서 사용되기 위해서이다. TBEGIN 명령은, 만일 트랜잭션이 TEND 명령에 도달하기 전에 폐기된다면, 상태 정보를 기록하기 위해 트랜잭션 진단 블록(TDB)을 명시할 수 있다.
내포 깊이와 유사하게, IDU(208)/GCT(232)도 트랜잭션 내포(nest)를 통해 액세스 레지스터/부동-소수점 레지스터(AR/FPR) 수정 마스크들을 협력적으로 추적한다; IDU(208)는 AR/FRR-수정 명령이 디코드되고 수정 마스크가 그것을 차단할 때 폐기 요청을 GCT(232)로 보낼 수 있다. 명령이 완료에 근접(next-to-complete)할 때, 완료는 차단되고 트랜잭션은 폐기된다. 다른 제한된 명령들도 비슷하게 처리되는데, 만일 제한된 트랜잭션에서 디코드되는 경우 TBEGIN을 포함하고, 그렇지 않으면, 최대 내포 깊이를 초과한다.
가장 바깥의 TBEGIN(outermost TBEGIN)은 쪼개져서 지알-세이브-마스크(GR-Save-Mask)에 따라 다수의 마이크로-오피들(multiple micro-ops)이 된다; 각각의 마이크로-오피(232b)(예를 들어, uop 0, uop 1, 및 uop 2를 포함)는 두 개의 고정 소수점 유닛들(FXU들)(220) 중 하나에 의해서 실행되어 한 쌍의 GR들(228)을 특별 트랜잭션-백업 레지스터 파일(224)에 세이브하는데, 이는 나중에 트랜잭션 폐기의 경우에 GR(228) 내용을 복원하는데 사용된다. 또한 TBEGIN은 마이크로-오피들(232b)을 산출하는데(spawn), 이는 만일 1이 명시되었다면 TDB에 대한 액세스 가능성 테스트(an accessibility test)를 수행하기 위함이다; 어드레스는 특별 목적 레지스터 내에 세이브되는데, 이는 폐기가 일어나는 경우에 나중에 사용하기 위함이다. 가장 바깥의 TBEGIN의 디코딩에서, TBEGIN의 명령 어드레스와 명령 텍스트는 또한 나중에 있을 잠재적 폐기 처리를 위해 특별 목적 레지스터들 내에 세이브된다.
TEND 및 NTSTG는 단일 마이크로-오피(232b) 명령들이다; NTSTG(비-트랜잭션 스토어)는 LSU(280)가 그것을 적절하게 취급할 수 있도록 발행 큐(216) 내에 비-트랜잭션으로서 마크되는 것을 제외하고 정상 스토어(a normal store)와 같이 처리된다. TEND는 실행 타임에(at execution time) 노-오피(a no-op)이고, 트랜잭션의 종료(ending)는 TEND가 완료될 때 수행된다.
전술한 바와 같이, 트랜잭션 내에 있는 명령들은 발행 큐(216)에 그대로 마크되지만, 달리 실행해도 대개 변경되지는 않는다(unchanged); LSU(280) 분리 추적(isolation tracking)을 실행하는데, 이는 다음 섹션에서 기술한다.
디코딩이 정상적(in-order)이고, 그리고 IDU(208)가 현재 트랜잭션 상태를 추적하고 그것을 그 트랜잭션으로부터의 모든 명령과 함께 발행 큐(216) 내에 라이트해도, TBEGIN, TEND, 그리고 그 트랜잭션 전의(before), 내의(within), 및 후의(after) 명령들의 실행은 비정상적으로(out-of order) 수행될 수 있다. TEND가 먼저 실행되고, 그 다음에 전체 트랜잭션이, 그리고 마지막으로 TBEGIN이 실행되는 것도 가능할 수 있다(비록 가능성은 낮지만). 프로그램 순서는 완료 타임에 GCT (232)를 통해서 복원된다. 트랜잭션들의 길이는 GCT(232)의 사이즈에 의해서 제한되지 않는데, 이는, 범용 레지스터들(GR들)(228) 백업 레지스터 파일(224)로부터 복원될 수 있기 때문이다.
실행 동안, 프로그램 이벤트 기록(PER) 이벤트들(the program event recording (PER) events)은 이벤트 억제 컨트롤(Event Suppression Control)에 기초하여 걸러지고, 그리고 PER TEND 이벤트는 만일 인에이블된다면(if enabled) 검출된다. 비슷하게, 트랜잭션 모드에 있는 동안, 슈도-랜덤 발생기(a pseudo-random generator)는 트랜잭션 진단 컨트롤(the Transaction Diagnostics Control)에 의해서 인에이블 되므로 임의의 폐기들(random aborts)을 일으킬 수 있다.
트랜잭션 분리에 대한 추적(Tracking for Transactional Isolation)
로드/스토어 유닛(280)은 트랜잭션 실행 동안 액세스된 캐시 라인들을 추적하여, 만일 다른 CPU로 부터의 XI(또는 LRU-XI)가 풋프린트(the footprint)와 충돌한다면 폐기를 촉발한다(trigger). 만일 충돌하는 XI가 배타 또는 강등 XI라면, LSU(280)는 XI를 거절하여 L3(272)으로 되돌려 보내는데, 이는 L3(272)이 XI를 반복하기 전에 트랜잭션을 완료하는 것에 관한 희망에서 그렇게 한다. 이 "밀어내기(stiff-arming)"는 경쟁이 심한(highly contended) 트랜잭션들에서 매우 효율적이다. 두 개의 CPU들이 서로 밀어내기를 할 때 행들(hangs)을 방지하기 위해, XI-거절 카운터가 구현되는데, 이는 임계값에 도달할 때(when a threshold is met) 트랜잭션 폐기를 촉발한다.
L1 캐시 디렉토리(240)는 전통적으로 정적 랜덤 액세스 메모리들(SRAM들)로 구현된다. 트랜잭션 메모리 구현을 위해, 상기 디렉토리의 유효한 비트들(244)(64 rows x 6 ways)은 정상 논리 래치들(normal logic latches)로 이동되고, 캐시 라인당 두 개의 비트들: TX-리드(248) 및 TX-더티(252) 비트들이 더 보충된다.
TX-리드(248) 비트들은 새로운 가장 바깥의 TBEGIN(이는 이전의 아직 펜딩인 트랜잭션에 대해 상호 인터록되어 있다(interlocked))이 디코드 될 때 리세트된다. TX-리드(248) 비트는 실행 타임에 세트되는데, 발행 큐 내에 "트랜잭션"으로 마크되어 있는 모든 로드 명령에 의해서 된다. 여기서 주목할 것은 만일 추측 로드들(speculative loads)이, 예를 들어 잘못 예측된 분기 경로(a mispredicted branch path) 상에서 실행된다면, 이것은 오버-마킹(over-marking)으로 될 수 있다는 것이다. TX-리드(248) 비트를 로드 완료 타임에 세트하는 대안은 실리콘 면적(silicon area)에 대해서 너무 비싸게 먹혔는데, 그 이유는 다수의 로드들이 동시에 완료할 수 있기 때문이며, 이는 로드-큐(the load-queue) 상에 많은 리드-포트들(many read-ports)을 요구한다.
스토어들은 비-트랜잭션 모드에서와 동일 방식으로 실행하지만, 트랜잭션 마크는 스토어 명령의 스토어 큐(STQ)(260) 엔트리에 배치된다. STQ(260)로부터의 데이터가 L1 (240)에 라이트되는 때인, 라이트-백 타임에, L1-디렉토리(256) 내의 TX-더티 비트는 라이트된 캐시 라인에 대해 세트된다. L1(240)으로의 스토어 라이트-백(Store write-back)은 스토어 명령이 완료된 후에만 발생하고 싸이클 당 기껏해야 하나의 스토어가 라이트-백된다. 완료하고 라이트-백하기 전에 로드들이 STQ(260)로부터의 데이터를 액세스 할 수 있는데, 스토어-전송 수단(means of store-forwarding)에 의해서 할 수 있다; 라이트-백한 후에, CPU(114)(도 2)는 L1(240) 내의 추측으로 갱신된 데이터를 액세스 할 수 있다. 만일 트랜잭션이 성공적으로 종료되면, 모든 캐시 라인들의 TX-더티 비트들(252)은 클리어 되고, 그리고 또한 아직 라이트되지 않은 스토어들의 TX-마크들도 STQ(260) 내에서 클리어 되는데, 이는 펜딩 스토어들을 효과적으로 정상 스토어들 내로 돌려준다(turn).
트랜잭션 폐기가 있는 경우, 모든 펜딩 트랜잭션 스토어들은, 비록 그들이 이미 완료되었다 하더라도, STQ(260)로부터 무효화된다. 다시 말하면, L1(240) 내의 트랜잭션에 의해서 수정된 모든 캐시 라인들은 TX-더티 비트(252)는 온(on)으로 하고, 그들의 유효 비트들은 턴오프하는데, 이는 L1(240) 캐시로부터 동시에 그들을 효과적으로 제거한다.
이 아키텍처는 새로운 명령을 완료하기 전에, 트랜잭션 리드- 및 라이트-세트의 분리(isolation)가 유지될 것을 요구한다. 이 분리는 XI들이 펜딩인 적당한 때에 명령 완료를 멈춤으로써 보장된다; 추측 비정상 실행(speculative out-of order execution)이 허용되고, 펜딩 XI들은 서로 다른 어드레스로 보내져서 실제로 트랜잭션 충돌을 일으키지 않을 것이라고 낙관적으로 가정한다. 이 설계는 상기 아키텍처가 요구하는 강한 메모리 정리(the strong memory ordering)를 보장하기 위해 최신 시스템들 상에서 구현되는 XI-대-완료 인터록들(XI-vs-completion interlocks)과 매우 자연스럽게 잘 맞는다(fit).
L1(240)이 XI를 수신하면, L1(240)은 디렉토리를 액세스하여 L1(240) 내의 XI된(Xl'ed) 어드레스의 유효성을 확인하고, 만일 TX-리드 비트(248)가 XI된 라인 상에서 활성(active)이고 그 XI가 거절되지 않았다면, LSU(280)는 폐기를 촉발한다. 활성TX-리드 비트(248)를 갖는 캐시 라인이 L1(240)으로부터 LRU될 때(LRU'ed), 특별 LRU-확장 벡터(a special LRU-extension vector)는 L1(240)의 64 로우들(rows) 각각에 대해 TX-리드 라인이 그 로우 상에 존재했다는 것을 기억한다. LRU 확장들(extensions)에 대해서 정밀한 어드레스 추적은 존재하지 않고, 유효한 확장 로우를 히트하는 어떠한 거절된 XI도 없기 때문에, LSU(280)는 폐기를 촉발한다. 비-정밀 LRU-확장 추적에 대한 다른 CPU들(114)(도 1)과의 충돌들이 폐기들을 일으키지 않는다면, LRU-확장을 제공하는 것은 L1-사이즈로부터 L2-사이즈까지의 리드 풋프린트 능력(the read footprint capability)과 연관성(associativity)을 효과적으로 증가시킨다.
스토어 풋프린트(the store footprint)는 스토어 캐시 사이즈(스토어 캐시에 관해서는 아래에서 더 상세히 논의 될 것이다)에 의해서 따라서 L2(268) 사이즈와 연관성에 의해서 묵시적으로 제한된다. TX-더티(252) 캐시 라인이 L1(240)으로부터 LRU될 때 아무런 LRU-확장 액션(LRU-extension action)이 수행될 필요가 없다.
스토어 캐시(Store Cache)
최신 시스템들에서 L1(240) 및 L2(268)는 스토어-스루 캐시들이므로, 모든 스토어 명령은 L3(272) 스토어 액세스를 일으킨다; 이제 L3(272) 당 6개의 코어들이 있고 각각의 코어의 성능이 더 개선되어 있다면, L3(272)에 대한 스토어 속도(그리고 L2(268)에 대해서는 더 적게 잡더라도)는 특정 워크로드들에 대해서는 문제가 될 수 있다(problematic). 스토어 큐잉 지연들을 피하기 위해서, 수집 스토어 캐시(a gathering store cache)(264)가 추가되어야 했는데, 이는 L3(272)으로 스토어들을 보내기 전에 이웃하는 어드레스들(neighboring addresses)에 대한 스토어들을 합한다(combine).
트랜잭션 메모리 성능을 위해, 트랜잭션 폐기들이 있을 때 L1(240)으로부터의 모든 TX-더티(252) 캐시 라인을 무효화하는 것은 수용 가능한데, 그 이유는 L2(268) 캐시가 매우 가까워서(7 싸이클 L1(240) 미스 페널티) 클린 라인들을 도로 가져올 수(bring back) 있기 때문이다. 그러나, 트랜잭션이 종료하기 전에 트랜잭션 스토어들을 L2(268)에 라이트하고 그 다음 폐기가 있을 경우(혹은 공유된 L3(272) 상에서 더 나쁜 일이 있을 경우) 모든 더티 L2(268) 캐시 라인들을 무효화하는 것은 성능을 위해서(그리고 추적을 위한 실리콘 면적을 위해서) 수용될 가능성이 없다.
스토어 대역폭(store bandwidth) 및 트랜잭션 메모리 스토어 처리의 두 가지 문제들은 수집 스토어 캐시(the gathering store cache)(264)로 모두 해결될 수 있다. 캐시(232)는 64 엔트리들을 갖는 순환 큐(a circular queue)이고, 각각의 엔트리는 바이트-정밀 유효 비트들(byte-precise valid bits)을 갖는 128 바이트의 데이터를 보유한다. 비-트랜잭션 연산에서, 스토어가 LSU(280)로부터 수신되었을 때, 스토어 캐시는 동일 어드레스에 대해 엔트리가 존재하는지를 확인하고, 만일 존재하면 새로운 스토어를 기존의 엔트리로 수집한다(gather). 만일 엔트리가 존재하지 않으면, 새로운 엔트리는 큐로 라이트되고, 그리고 만일 프리 엔트리들의 수가 임계값 아래로 떨어지면, 가장 오래된 엔트리들은 L2(268) 및 L3(272) 캐시들에 도로 라이트된다.
새로운 가장 바깥의 트랜잭션이 시작할 때, 스토어 캐시 내의 모든 기존의 엔트리들은 닫힘(closed)으로 마크되어 새로운 스토어들이 그들 내부로 들어올 수 없게 하고, L2(268) 및 L3(272)로 이들 엔트리들의 퇴거가 시작된다. 그 시점부터, LSU(280)과 STQ(260)로부터 유입되는 트랜잭션 스토어들은 새로운 엔트리들을 할당하거나, 또는 기존의 트랜잭션 엔트리들로 수집된다. 이들 스토어들을 L2(268) 및 L3(272)으로 라이트-백하는 것은, 트랜잭션이 성공적으로 종료될 때까지, 차단된다; 그 시점 이후에(포스트-트랜잭션) 스토어들은 계속 기존 엔트리들로 수집될 수 있는데, 다음 트랜잭션이 이들 엔트리들을 다시 닫을 때까지 그렇게 할 수 있다.
스토어 캐시는 모든 배타 또는 강등 XI에 관해서 질의를 받고, 만일 XI가 어떠한 활성 엔트리에 대해서 비교하면 XI 거절을 일으킨다. 만일 코어가 XI들을 계속적으로 거절하는 동안 명령들을 추가적으로 완료하고 있지 않다면, 트랜잭션은 행들(hangs)을 피하기 위해 특정 임계 값에서(at a certain threshold) 폐기된다.
LSU(280)는 스토어 캐시가 오버플로(overflow)일 때 트랜잭션 폐기를 요청한다. LSU(280)는 기존 엔트리로 합칠(merge) 수 없는 새로운 스토어를 내보내려고 시도할 때 이 조건을 검출하며, 전체 스토어 캐시는 현재 트랜잭션으로부터의 스토어들로 채워진다. 스토어 캐시는 L2(268)의 서브세트(subset)로서 관리된다: 트랜잭션으로서 더티 라인들이 L1(240)으로부터 퇴거될 수 있는 동안, 그들은 트랜잭션 내내 L2(268) 내에 상주해야 한다. 따라서 최대 스토어 풋프린트는 64 x 128 바이트의 스토어 캐시 사이즈로 제한되고, 그것은 또한 L2(268)의 연관성에 의해서도 제한된다. L2(268)는 8-웨이 연관성이 있고 512 로우들을 갖고 있기 때문, 그것은 통상적으로 트랜잭션 폐기들을 일으키지 않을 만큼 충분히 크다.
만일 트랜잭션이 폐기되면, 스토어 캐시에게 통지되고 모든 엔트리들은 무효화된다. 스토어 캐시는 엔트리가 NTSTG 명령에 의해서 라이트되었든지 간에 또한 더블워드(8 바이트) 당 ― 이들 더블워드들은 트랜잭션 페기들에 걸쳐서 유효하다 ― 마크 하나를 갖는다.
밀리코드-구현된 기능들(Millicode-Implemented Functions)
전통적으로, IBM 메인프레임 서버 프로세서들은 밀리코드(millicode)라 불리우는 펌웨어 층을 포함하는데, 이는 특정 CISC 명령 실행들, 인터럽션 처리, 시스템 동기화, 및 RAS와 같은 복잡한 기능들을 수행한다. 밀리코드는 애플리케이션 프로그램들 및 운영 체제(OS)의 명령들과 유사하게 메모리로부터 페치되고 실행되는 명령 세트 아키텍처(ISA)의 명령들뿐만 아니라 머신 종속 명령들(machine dependent instructions)을 포함한다. 펌웨어는 고객 프로그램들이 액세스할 수 없는 주 메모리의 제한된 영역에 상주한다. 하드웨어가 밀리코드를 불러내야 할 필요가 있는 상황을 검출하면, 명령 페칭 유닛(204)은 "밀리코드 모드"로 전환하고 밀리코드 메모리 영역 내의 적절한 위치에서 페칭을 시작한다. 밀리코드는 명령 세트 아키텍처(ISA) 명령들과 동일 방식으로 페치되고 실행될 수 있으며, ISA 명령들을 포함할 수도 있다.
트랜잭션 메모리에 대해서, 밀리코드는 다양하고 복잡한 상황들에서 관련되어 있다. 모든 트랜잭션 폐기는 필요한 폐기 연산들을 수행하기 위해 전용 밀리코드 서브-루틴(a dedicated millicode sub-routine)을 불러낸다. 트랜잭션-폐기 밀리코드는 하드웨어 내부 폐기 이유(the hardware internal abort reason), 잠재적 예외 이유들(potential exception reasons), 및, 1이 명시되는 경우 밀리코드가 TDB를 저장하기 위해 사용하는, 폐기된 명령 어드레스(the aborted instruction address)를 보유하는 특별-목적 레지스터들(SPR들)을 리드함(reading)으로써 시작한다. TBEGIN 명령 텍스트는 SPR로부터 로드되어 GR-세이브-마스크를 획득하는데, 이는 어느 GR들(238)이 복원되어야 하는지를 밀리코드가 알아 내는 데 필요하다.
CPU(114)(도 2)는 백업-GR들(224)을 읽어 내어서 그들을 주 GR들(228)로 복사하기 위해 특별 밀리코드-전용 명령(a special millicode-only instruction)을 지원한다. TBEGIN 명령 어드레스도 또한 SPR로부터 로드되어 PSW 내 새로운 명령 어드레스를 세트하여 일단 밀리코드 폐기 서브-루틴이 마무리되면 TBEGIN 이후 실행을 계속한다. 상기 PSW는 폐기가 걸러지지-않은 프로그램 인트럽션(a non- filtered program interruption)에 의해서 일어나는 경우에 프로그램-올드 PSW(program-old PSW)로서 나중에 세이브될 수 있다.
TABORT 명령은 밀리코드로 구현될 수 있다; IDU(208)가 TABORT를 디코드하면, 그것은 명령 페치 유닛을 지시하여 TABORT의 밀리코드로 분기하게 하고, 이로부터 밀리코드는 공동 폐기 서브-루틴(the common abort sub-routine)으로 분기한다.
익스트랙트 트랜잭션 내포 깊이(the Extract Transaction Nesting Depth: ETND) 명령도 또한 밀리코드로 될 수 있는데, 이는 성능에 미칠 영향이 크지 않기 때문이며(not performance critical); 밀리코드는 특별 하드웨어 레지스터로부터 현재 내포 깊이를 로드하여 그것을 GR(228)에 배치한다. PPA 명령은 밀리코드로 되어 있고; 그것은 최적 지연(the optimal delay)을 수행하는데, PPA에 대한 오퍼랜드로서 소프트웨어에 의해서 제공되는 현재 폐기 카운트에 기초하고, 또한 다른 하드웨어 내부 상태에 기초하여 수행한다.
제한된 트랜잭션들을 위해, 밀리코드는 폐기들의 수를 추적할 수 있다. TEND가 성공적으로 완료되거나, 또는 OS 내에 인터럽션이 발생한다면 카운터는 0으로 리셋된다(왜냐하면 OS가 프로그램에 리턴할 것인지 또는 언제 리턴할 것인지 알려지지 않았기 때문이다). 현재 폐기 카운트에 따라서, 밀리코드가 특정 메커니즘들을 불러와서 후속 트랜잭션 재시도에 대한 성공의 가능성을 개선할 수 있다. 예를 들어, 상기 메커니즘들이 재시도들 사이에서 랜덤 지연들을 성공적으로 증가시키고, 추측 실행의 양을 감소시키는 일에 관여하는데, 이는 트랜잭션이 실제로 사용하지 않고 있는 데이터에 대한 추측 액세스들에 의해서 일어나는 폐기들을 만나는 것을 피하기 위해서이다. 최후의 수단으로서, 밀리코드는, 다른 CPU들(114)(도 2)을 해제하여(release) 정상 처리를 계속하도록 하기 전에, 다른 CPU들(114)에게 모든 충돌하는 작업을 중단하고, 로컬 트랜잭션을 재시도하라고 전파할 수 있다. 다수의 CPU들(114)은 데드락들(deadlocks)을 일으키지 않도록 조정되어야 하며, 그래서 다른 CPU들(114) 상의 밀리코드 인스턴스들(millicode instances) 사이에서 일부 직렬화가 요구된다.
도 4는 본 발명의 실시 예에 따른 컴퓨터 시스템(300)을 도시한다. 도 4는 도 1-3 및 도 5-18에서 논의되는 특징들을 구현하도록 구성된다. 컴퓨터(300)는 프로세서(112a)(CPU 1) 및 (112b)(CPU 2)(이와 함께 추가되는 프로세서들은 도시되지 않음)로서 지정되는 다수의 프로세서들을 포함하고, 상기 프로세서는 계층적 캐시 서브시스템의 방식에 의해 메모리(310)와 통신하며, 상기 프로세서에 의해서, 트랜잭션 로드들이 계층적 캐시 서브시스템의 캐시에서 감시된다(monitored). 도 4에서 도시한 컴퓨터 시스템(300)은 도 1에서 도시한 컴퓨터 시스템(100)과 동일한 엘리먼트들을 가지고 있고 동일 참조 번호들을 가지고 있지만, 도 1의 모든 엘리먼트가 도 4에서 도시되지는 않는다.
컴퓨터 시스템(300)은 요청, 예를 들어, 트랜잭션들을 위해 이용 가능한 또는 현재 트랜잭션들을 처리하고 있는 하나 또는 그 이상의 프로세서들에게 제출된, 인터럽션을 관리할 수 있다. 한 예에서, 요청하는 프로세서(예를 들어, CPU 1(112a))는 수신하는/리모트 프로세서(예를 들어, CPU 2(112b))를 선택하고 요청을 그 선택된 리모트 프로세서에 보낼 수 있다. 한 예에서, 상기 컴퓨터 시스템은 트랜잭션-실행(TX) 시스템 또는 환경이며, 예를 들어 트랜잭션을 실행할 수 있는 CPU 또는 프로세서를 포함한다. 각각의 트랜잭션은 프로세서들 (112a) 및 (112b)에서 각각 실행하는 트랜잭션 명령들 (320a) 및 (320b)로서 각각 도시된다. 각각의 프로세서 (112a) 및 (112b)는, 각각, 자기 자신의 레지스터 (334a) 및 (334b)를 갖고 있다.
각각의 데이터 캐시 (118a) 및 (118b)는 각각 자기 자신의 L1 및 L2 캐시를 가질 수 있다. 컴퓨터 메모리는 일반적으로 메모리(310)에 의해서 표시되는데, 이 메모리는 TX CPU들, 다시 말하면, 프로세서들 (112a) 및 (112b)로서 지정된 CPU들 내의 상위 수준 캐시를 포함할 수 있다. 각각의 프로세서 (112a) 및 (112b)는 테이블들 (1350a) 및 (1350b)로서, 각각, 지정된 자기 자신의 로컬 트랜잭션 간섭 추적 테이블(local transaction interference tracking table)을 갖는다. 테이블들 (1350a) 및 (1350b)는 데이터 캐시 (118a), (118b), 레지스터들(334a, 334b)에서, 및/또는 메모리(310)에서 각각 저장될 수 있다. 메모리(310)도 또한 트랜잭션들의 진단 정보를 저장하기 위해 트랜잭션 진단 블록(a transaction diagnostic block)(350)을 포함할 수 있고, 이는 테이블들 (1350a) 및 (1350b)에 (통계 정보와 함께) 트랜잭션 간섭 정보를 포함할 수 있으며, 이에 관해서는 아래에서 더 상세히 논의한다.
컴퓨터 시스템(300)은 본 발명의 실시 예들에 따른 요청들 및 응답들 모두를 내보내고, 수신하며 그리고 처리하는 트랜잭션(TX) 환경의 한 표현이다. 여기서 프로세서 (112a)(CPU 1)는 요청을 생성하고 프로세서 (112b)(CPU 2)로 내보내는 요청 프로세서로서, 프로세서 (112b)(CPU 2)는 상기 요청을 수신하는 수신/리모트 프로세서로서 도시되는 다양한 예들이 제공됨을 주목해야 한다. 당업자가 알 수 있듯이 이러한 지정은 설명의 목적을 위한 것이며, 어느 프로세서도 데이터에 대한 요청을 내보내고 수신할 수 있음을 이해해야 한다.
도 5는 프로토콜 요청 및 응답 예를 도시한다. 프로토콜 요청은 메인프레임 멀티프로세서 프로토콜이라 할 수 있고, 이 프로토콜은 버스 기반의 또는 스위치 기반의 인터커넥트를 통해서 전달될 수 있다. 이 프로토콜은 모두 병렬 신호전송(parallel signaling)(버스 스누핑(bus snooping)), 직렬 패킷들(serial packets), 또는 이들의 조합이 될 수 있다.
한 예로서, 데이터에 대한 요청(505)이 CPU 1(112a)로부터 CPU 2(112b)로 보내질 수 있다. 요청(505)은 타입 필드(506), 그리고 태그 필드(507)을 포함하는데, 타입 필드(506)는 어떤 타입의 요청(예를 들어, 알려진 MESI 일관성 프로토콜에 따른 리드 공유 요청(read shared request) 또는 리드 배타 요청(read exclusive request) ― 또는, 소유를 위한 리드 요청(request for ownership) ―, 또는 기타 그러한 프로토콜들에 따른 프로토콜 요청들)이 보내지는지를 알려주고, 태그 필드(507)는 상기 요청을 내보낸 특정 프로세서(예를 들어, CPU 1)와 선택적으로 수신 프로세서, 예를 들어 상기 요청이 보내지는 CPU 2와 그리고, 선택적으로, 다수의 요청들이 동시에 처리될 수 있다면, 각각의 요청을 고유하게 식별하기 위한 특정 요청 ID(a specific request ID)를 식별한다. 요청(505)은 또한 액세스 필드(508), 및 어드레스 필드(508)를 포함하고, 상기 액세스 필드는 상기 수신 프로세서(CPU 1)에 의해서 요청되는 액세스의 타입을 식별한다. 어드레스 필드(509)는 요청되는 캐시라인 또는 메모리 워드의 메모리 어드레스를 식별한다. 요청(505) 프로토콜은 에러 정정 필드(510)를 포함할 수 있고, 이는 에러 검출 및/또는 사용되는 정정 코드, 예를 들어 사이클 리던던시 체크(cyclic redundancy check: CRC), 패리티 비트들, 또는 ECC를 포함한다.
응답(515)이 수신 프로세서(CPU 2)로부터 요청 프로세서(CPU 1)로 보내질 수 있다. 응답(515)은, 예를 들어 리드 응답(READRESPONSE)과 같은 응답의 타입을 표시하는 타입 필드(516), 및 태그 필드(517)를 포함한다. 태그 필드(517)는 오리지널 요청(505)의 태그 필드(507)와 동일 태그 필드일 수 있고 그리고/또는 태그 필드(517)는 캐시 라인의 요청된 메모리 주소를 포함할 수 있다. 응답(515)은 데이터 필드(518)를 포함하고, 이는 요청 프로세서(CPU 1)에 의해서 요청된 데이터이다. 일부 프로토콜 응답들은 데이터 트랜스퍼들(data transfers)(예를 들어, 라인에 대한 소유권을 공유로부터 배타 소유권으로 확대하기 위한 프로토콜 요청들)을 포함하지 않을 수 있고 그리고 오직 처리가 수행되었다는 확인만 포함할 수 있다. 에러 정정 필드(519)도 응답(515)에 포함된다.
일부 실시 예들에서, 프로토콜 요청들을 위한 신호전송(signaling)은 복수의 비트 라인들을 통해 병렬로 할 수 있고, 모든 사용되지 않은 필드들은 프로토콜-정의된 값(protocol-defined value)을 갖고 있지 않거나, 디폴트 값에 세트되어 있거나, 또는 이와 달리 프로토콜 메시지의 일부분으로 고려되지 않는 라인들에 대응할 수 있다. 일부 실시 예들에서, 프로토콜 요청은 다수의 "비트들(beats)", 예를 들어 전체로서 프로토콜 메시지를 나타내는 비트들의 연속하는 그룹들(successive groups of bits)로서 전송될 수 있다. 또 다른 실시 예들에서, 프로토콜 요청들은 비트-직렬로(bit-serially) 전송될 수 있다. 다수의 비트들(beats)로 또는 직렬로 전송되는 프로토콜들에서, 일부 메시지들은 다른 프로토콜 요청들보다 더 많은 버스 신호전송 사이클들로 구성될 수 있다.
도 6은 또 다른 프로토콜 요청 예를 도시한다. 많은 프로토콜들은 라이트 연산들을 위해 RFO(소유권을 위한 리드) 또는 리드-배타 요청들을 통해 배타 액세스를 획득하고, 한편 일부 다른 프로토콜들은 직접적으로 라이트를 할 수 있다(제한적으로). 한 예로서, 데이터를 라이트하기 위한 예시적 요청(605)은 CPU 1(112a)로부터 CPU 2(112b)로 보내질 수 있다. 요청(605)은 타입 필드(506)와, 태그 필드(507)를 포함하고, 상기 타입 필드(506)는 보내지는 요청의 타입(예를 들어, 라이트)을 식별하며, 상기 태그 필드(507)는 상기 라이트 요청을 보낸 특정 프로세서(예를 들어 CPU 1)를 식별하고 그리고 상기 요청이 보내진 수신 프로세서, 예를 들어 CPU 2와 특정 요청을 선택적으로 식별한다. 요청(605)은 또한 요청 프로세서(CPU 1)에 의해서 라이트되는 데이터를 전송하는 데이터 필드(504), 및 어드레스 필드(509)를 포함한다. 어드레스 필드(509)는 라이트되는 캐시 라인 또는 어드레스 라인의 메모리 어드레스를 식별한다. 요청(605) 프로토콜은 에러 정정 필드(510)를 포함할 수 있고, 에러 정정 필드(510)는 에러 검출 및/또는 사용되는 정정 코드, 예를 들어 사이클 리던던시 체크(CRC), 패리티 비트들, 또는 ECC를 포함한다.
라이트 요청에 대한 응답에서는, 통상적으로 응답이 없는데, 그 이유는 라이트를 수행하기 전에 배타 액세스를 위한 데이터를 획득할 필요가 없기 때문이다
도 7은 본 발명의 한 실시 예에 따라 데이터에 대한 요청을 하는 프로세서(예를 들어, CPU 1(112a))에 의한 프로토콜 요청 생성의 흐름도(700)이다. 프로세서(예를 들어, CPU 1)는 블록(705)에서 메모리 데이터에 대한 요청을 갖는다. 프로세서(예를 들어, CPU 1)는 블록(710)에서 요청된 데이터가 자기 자신의 로컬 캐시(예를 들어, 데이터 캐시(118a)에 있는 L1 캐시)에 있는지 확인한다. 프로세서 자신의 로컬 캐시 내에서 그 데이터가 이용 가능하면, 플로(flow)는 블록(735)로 진행한다. 프로세서(CPU 1)의 로컬 캐시 내에서 그 데이터가 이용 가능하지 않으면, 프로세서는 블록(715)에서 다른 프로세서들(예를 들어, CPU 2(112b))로부터 원하는 데이터를 요청하기 위해 XI 요청(교차 질의)을 생성한다. 요청 프로세서(CPU 1)는 블록(720)에서 그 데이터에 대한 XI 요청을 인터커넥트(122)를 통해 수신 프로세서(CPU 2)로 내보내고, 요청 프로세서(CPU 1)는 블록(725)에서 수신 프로세서(CPU 2)로부터 그 (요청된)데이터를 갖는 XI 응답을 수신한다. 요청 프로세서(CPU 1)는 블록(730)에서 데이터 캐시(118a) 내 자신의 로컬 캐시들(예를 들어, L1, L2 캐시)에 그 데이터를 배치한다. 요청 프로세서(CPU 1)는 블록(735)에서 명령 캐시(116a)를 통해 자신의 로컬 캐시(118a)로부터 그 데이터를 획득한다. 요청 프로세서의 명령 캐시(116a)는 블록 (740)에서 처리를 위해 그 데이터를 CPU 1의 회로들에 제공한다.
한 실시 예에서, 그리고 공동 캐시 프로토콜(예를 들어, 알려진 MESI 프로토콜)에 따라, 프로세서가 리드를 위해 데이터를 액세스 할 때, 그 데이터가 이용 가능하지 않으면, XI가 리드-공유(read-shared)를 위해 생성되는데, 여기서 데이터는 다수의 CPU들(112a, 112b)이 캐시 내에서 그 데이터의 복사본을 가질 수 있는 공유 방식으로 획득되고, 그리고 각각의 CPU는 그 데이터에 대응하는 메모리 리드 액세스를 처리할 수 있다. 수신된 데이터는 캐시 내에 배치되고 공유 액세스를 위해 마크되며, 그리고 프로세서는 메모리-리드 연산들에 응답하여 상기 복사본으로부터 리드 액세스들을 수행할 수 있다. 프로세서가 라이트를 위해 데이터를 액세스할 때, 그리고 그 데이터가 배타 상태로 이용 가능하지 않으면, XI가 리드-배타를 위해 생성되는데, 여기서 데이터는 오직 단일 CPU(예를 들어 CPU 112a)만 캐시 내 그 데이터의 복사본을 가질 수 있는 배타 방식으로 획득된다. 수신된 데이터는 캐시 내에 배치되고 배타 액세스를 위해 마크되며, 그리고 프로세서는 메모리-라이트 연산들에 응답하여 상기 복사본을 갱신할 수 있다. 한 실시 예에서, 데이터가 공유 모드로 제출되고, 라이트 액세스가 수신되면, 리드-배타 XI가 생성된다. 적어도 하나의 실시 예에서, 이것은 구별되는 리드-배타 요청으로서 표시되는데, 여기서 데이터는 응답의 일부로서 수신되지 않는다. 한 실시 예에서, 응답이 수신되었을 때, 캐시 데이터는 배타 액세스를 위해 마크된다.
도 8은 본 발명의 한 실시 예에 따라 요청을 수신하고 응답을 내보내는 수신/리모트 프로세서(예를 들어, CPU 2(112b))에 의해서 처리되는 요청의 예시적 흐름도(800)를 도시한다.
리모트 프로세서(CPU 2)는 블록(805)에서 요청 프로세서(CPU 1)로부터 데이터에 대한 XI 요청을 수신한다. 블록(810)에서, 리모트 프로세서(CPU 2)는 간섭이 검출되는지를 확인하는데, 이 확인은 리모트 프로세서가 (리모트 프로세서의 로컬 캐시 내의) 요청된 데이터를 현재 필요로 하는 트랜잭션을 처리하고 있는지를 확인함으로써 한다. 리모트 프로세서(CPU 2(112b))가 블록(810)에서 요청 프로세서(CPU 1(112a))에 의해서 요청된 데이터를 리모트 프로세서가 현재 사용하고 있다고 결정하면, 리모트 프로세서는 블록(815)에서 간섭이 검출되었다고 결정하고(YES) 리모트 프로세서(CPU 2)는 리모트 프로세서(CPU 2)에서 진행하는 로컬 트랜잭션을 폐기한다. 일단 리모트 프로세서(CPU 2)에서 로컬 트랜잭션이 폐기되면, 리모트 프로세서는 블록(820)에서 요청 프로세서(CPU 1)에게로 리드 응답(READ RESPONSE)을 갖는 데이터를 전송한다. 리모트 프로세서(CPU 2)는 블록(825)에서 데이터 상태를 변경하고 필요하다면 선택에 따라 자신의 로컬 캐시들로부터의 데이터를 제거(purge)한다. 한 실시 예에서, 캐시 상태 변경은 트랜잭션이 폐기 되었을 때 리드 또는 라이트 세트 중 적어도 하나로부터 데이터를 방출하는 것(releasing)도 포함할 수 있다. 한 실시 예에서, 캐시 상태 변경은 캐시 디렉토리 내 캐시 라인의 상태를 변경하는 것, 예를 들어 상태를, 알려진 MESI 프로토콜과 같은 캐시 프로토콜에 따라, 공유(shared), 배타(exclusive), 무효(invalid), 및 등등 중 하나로 세트하는 것도 포함할 수 있다. 리모트 프로세서(CPU 1)는 블록(830)에서 트랜잭션 실패 처리를 개시하고 그리고 플로는 종료된다. 리모트 프로세서(CPU 2(112b))가 블록(810)에서 요청 프로세서(CPU 1(112a))에 의해서 요청된 데이터를 리모트 프로세서가 현재 사용하지 않고 있다고 결정하면, 리모트 프로세서는 블록(835)에서 간섭이 검출되지 않았다고 결정하고 리모트 프로세서(CPU 2)는 리드 응답(READ RESPONSE)을 갖는 데이터를 전송한다. 리모트 프로세서(CPU 2)는 블록(840)에서 데이터 상태를 변경하고 선택에 따라 필요하다면 로컬 캐시들로부터 데이터를 제거한다.
도 9는 본 발명의 한 실시 예에 따라 프로세서에 의해서 처리되는 트랜잭션을 도시하는 흐름도(900)이다. 블록(905)에서, 트랜잭션은 프로세서(예를 들어, CPU 1 또는 CPU 2) 상에서 실행하는 것을 시작한다. 도 9에서, 각각의 프로세서(CPU 1 및 CPU 2)는 이들 액션들을 수행하고 있을 수 있는데, 즉 트랜잭션들은 CPU(112a, 112b, 등)에 의해서 처리될 수 있음을 유의해야 한다. 프로세서는 블록(910)에서 트랜잭션 내의 명령들을 수행한다(예를 들어, 도 7에서 논의한 바와 같이). 프로세서는 블록(915)에서 트랜잭션 명령들에 응답하여 프로토콜 액션들을 수행한다. 프로세서는 블록(920)에서 자신의 트랜잭션을 프로세서가 폐기하도록 요구하는 (데이터의 사용을 갖는) 간섭이 존재하는지를 확인한다. 프로세서가 검출된 간섭이 존재한다고 결정하면(YES), 프로세서는 블록(925)에서 (그 데이터에 관한) 자기 자신의 트랜잭션을 폐기하고, 플로는 블록(935)로 진행한다. 프로세서가 간섭이 검출되지 않았다고 결정하면(NO), 프로세서는 블록(930)에서 자신의 트랜잭션(에 관한 명령들)을 완료한다. 프로세서는 블록(935)에서 (트랜잭션 진단 블록(TBD)과 같은) 트랜잭션 정보를 레지스터 내에 라이트 한다.
본 발명의 실시 예들에 따라, 일관성 프로토콜(the coherence protocol)은 트랜잭션 상태에 관한 추가 정보를 포함하도록 확장된다. 도 10은 본 발명의 실시 예들에 따라 프로토콜 요청(505) 및 새로운 프로토콜 응답(1005)을 도시한다. 도 10에서 도시한 바와 같이, 요청(505)의 일부 필드들은 도 5에서 논의한 필드들과 동일하다. 전술한 바와 같이, 요청(505)은 타입 필드(506)와, 태그 필드(507)를 포함하고, 상기 타입 필드(506)는 보내지는 요청의 타입(예를 들어, 리드)이 어떤 것인지를 식별하며, 상기 태그 필드(507)는 상기 요청을 보낸 특정 프로세서(예를 들어 CPU 1)(그리고 선택적으로 상기 요청이 보내지는 수신/리모트 프로세서, 예를 들어 CPU 2 및 요청 수)를 식별한다. 요청(505)은 또한 요청 프로세서(CPU 1)에 의해서 요청되는 액세스의 타입을 알려주는 액세스 필드(508), 및 요청되는 캐시 라인 또는 어드레스 라인의 메모리 어드레스를 알려주는 어드레스 필드(509)를 포함한다. 요청(505) 프로토콜은 예를 들어 사이클 리던던시 체크(CRC)와 같은 사용된 에러 코드의 타입을 알려주는 에러 정정 필드(510)를 포함한다.
새로운 응답(1005)은 추가의 트랜잭션 폐기 상태 필드(1010)과 함께 (도5에서의) 응답(515)의 필드들을 포함한다. 응답(1005)은 수신/리모트 프로세서(CPU 2)로부터 요청 프로세서(CPU 1)로 돌려보내질 수 있다. 응답(515)은 리드 응답(READRESPONSE)과 같은 응답의 타입을 표시하는 타입 필드(516)와, 캐시 라인의 요청된 메모리 어드레스를 표시하는 태그 필드(517)(오리지널 요청(505)의 태그 필드(507)와 동일 태그 필드일 수 있다)을 포함한다. 응답(515)은 요청 프로세서(CPU 1)에 의해서 요청되었던 요청 데이터인 데이터 필드(518)를 포함한다. 만일 데이터가 프로토콜 응답과 함께 전송되지 않는다면, 데이터 필드(518)는 비었거나 또는 존재하지 않는다. 에러 검출/정정 필드(519)가 응답(1005) 내에 포함된다.
추가로, 새로운 프로토콜 응답(1005)(리모트 프로세서 CPU 2에 의해서 요청 프로세서 CPU 1로 보내진)은 트랜잭션 폐기 상태 필드(1010)를 갖는다. 트랜잭션 폐기 상태 필드(1010)는 폐기되기 전에 리모트/수신 프로세서(CPU 2)상에서 이전에 실행하던 트랜잭션에 관한 다음 정보 중 하나 또는 그 이상을 포함한다:
1) (요청 프로세서(CPU 1)로 부터의) 요청(505)이 롤백(rollback)(즉, 폐기)을 일으켰는지 및/또는 일으키지 않았는지에 관한 정보;
2) 폐기되기 전에 리모트/수신 프로세서(CPU 2) 상에서 실행하고 있었던 이 트랜잭션의 우선순위;
3) 트랜잭션이 폐기되기 전에 얼마나 많은 명령들, 메모리 연산들, 및/또는 기타 작업의 량이 리모트/수신 프로세서(CPU 2) 상에서 이전에 실행하던 트랜잭션에 의해서 수행되었는지에 관한 정보;
4) 리모트 프로세서(CPU 2) 상에서 이전에 실행하던 트랜잭션(예를 들어, 토큰, TBEIGN의 어드레스, 및/또는 폐기된 트랜잭션을 식별하는 기타 수단)을 식별하는 정보.
더 나아가, 트랜잭션 폐기 상태 필드(1010)는 어떤 데이터가 폐기되었어야 했던 트랜잭션(이전에 리모트/수신 프로세서 상에서 실행 중이었던)에 의해서 획득되었는지를 알려주고, 그 트랜잭션의 어드레스를 알려 주며, 그리고 그 트랜잭션을 폐기하는 비용(3 클럭 사이클 또는 작업의 20,000클럭 사이클이 될 수 있다)을 알려준다.
프로세서(예를 들어, 예시 시나리오들에서 수신 프로세서 CPU 2)가 트랜잭션 실행 중일 때, 일관성 요청은 트랜잭션 실행을 폐기시킬 수 있는데, 그 이유는, 예를 들어 데이터가 트랜잭션 리드 또는 라이트 세트의 일부이고, 그리고 충돌(즉, 간섭)이 검출되기 때문이다
본 발명의 한 실시 예에 따라, 도 11은 도 6에서의 (요청 프로세서 CPU 1(112a)로부터 수신/리모트 프로세서 CPU 2(112b)로 보내진) 데이터를 라이트하기 위한 (라이트) 요청(605)을 도시하고 새로운 응답(1105)이 리모트 프로세서 CPU 2(112b)로부터 요청 프로세서 CPU 1(112a)로 돌려 보내진다. 도 11은 프로토콜 요청과 응답의 예이며, 이는 요청 발신자(request originator)에게 트랜잭션 간섭/폐기 정보를 전송하기 위해 프로토콜 응답을 이전에 요구하지 않던 트랜잭션에 대해 새로운 프로토콜 응답을 도입함으로써 본 발명의 한 실시 예에 따른 응답에 트랜잭션 정보를 추가한다. 적어도 하나의 실시 예에서, 트랜잭션 폐기 상태를 제공하는 하나의 목적을 위해 전송되는 프로토콜 응답은 선택적이고, 일부 모드들에서, 구성 비트들에 응답하여, 버스 혼잡에 응답하여, 및/또는 기타 이유들 때문에 억제될 수 있다. 응답이 수신되지 않는 그러한 시나리오에서, 응답이 수신되지 않았던 요청에 대응하는 트랜잭션 폐기 상태는 보고되지 않는다. 적어도 한 실시 예에서, 하나 또는 그 이상의 응답들의 부재가 보고될 수 있다. 전술한 바와 같이, 요청(605)은 타입 필드(506)와, 태그 필드(507)를 포함하고, 상기 타입 필드(506)는 보내지는 요청의 타입(예를 들어, 라이트)이 어떤 것인지를 알려주며, 상기 태그 필드(507)는 상기 라이트 요청을 보낸 특정 프로세서(예를 들어 CPU 1)(그리고 상기 요청이 보내지는 수신 프로세서, 예를 들어 CPU 2)를 식별한다. 요청(605)은 또한 요청 프로세서(CPU 1)에 의해서 요청되는 액세스의 타입을 알려주는 액세스 필드(508), 및 어드레스 필드(509)를 포함한다. 어드레스 필드(509)는 라이트 하기 위해 요청되는 캐시 라인 또는 어드레스 라인의 메모리 어드레스를 알려준다. 요청(605) 프로토콜은 에러 검출 및/또는, 예를 들어 패리티 비트들, ECC 또는 사이클 리던던시 체크(CRC) 코드와 같은 에러 정정/검출 코드를 갖는 정정 필드(510)를 포함한다.
라이트 요청(605)에 응답하여, (상기 라이트 요청에 대한) 새로운 응답(1105)은 이제 여기서 논의한 트랜잭션 폐기 상태 필드(1010)를 포함한다. 응답(1105)은 이 응답의 여러 필드들(1005)(도 10)을 포함한다. 새로운 응답(1105)은 수신/리모트 프로세서(CPU 2)로부터 요청 프로세서(CPU 1)로 되돌려 보내질 수 있다. 응답(1105)은 라이트 응답(WRITERESPONSE)과 같은, 응답의 타입을 표시하는 타입 필드(516)와, 캐시 라인의 요청된 메모리 어드레스를 표시하는 (상기 응답이 대응하는 요청을 식별하기 위한 오리지널 요청(505)의 태그 필드(507)와 동일 태그 일 수 있는)태그 필드(517)을 포함한다. 응답(1105)은 요청 프로세서(CPU 1)에 의해서 요청되는 요청된 데이터인 데이터 필드(518)를 포함할 수 있다. 수신/리모트 프로세서(CPU 2)의 (로컬)캐시로부터는 아무런 데이터가 없으므로, 데이터 필드(518)는 비어있다(empty). 에러 정정 필드(519)가 응답(1105) 내에 포함된다.
여기서 논의한 바와 같이, 트랜잭션 폐기 상태 필드(1010)는 (요청 프로세서(CPU 1)로부터의) 라이트 요청(605) 때문에 폐기하여야 했던 트랜잭션(수신/리모트 프로세서(CPU 2) 상에서 이전에 실행 중이었던)의 상태를 제공한다.
본 발명에 따른 프로토콜 향상들이 트랜잭션 폐기 상태 및 관련 정보에 대응하는 프로토콜 필드를 리드 요청에 대한 기존의 리드 응답에 추가하는 것에 관한 한 예시적 실시 예에서, 그리고 트랜잭션 폐기 상태 및 관련 정보에 대응하고 대응 라이트 요청을 식별하는 적어도 하나의 프로토콜 필드를 전송하기 위해서 최신 기술에 따른 프로토콜 응답을 갖고 있지 않는 프로토콜 라이트 요청에 대응하는 프로토콜 응답을 추가하는 것에 관한 다른 예시적 실시 예에서 기술되었지만, 당업자는 여기에 포함된 설명들을 다른 XI 포맷들, 프로토콜 포맷들, 요청들의 타입들, 일관성 프로토콜들, 등에 적용할 수 있을 것이다.
본 발명의 한 실시 예에 따라, 도 12는 일관성 요청 처리, 예를 들어 요청 프로세서 CPU 1(112a)로부터 요청을 수신하는 수신/리모트 프로세서 CPU 2(112b)에 의한 처리를 예시하는 흐름도를 도시한다. 도 12는 프로토콜 응답들의 일부로서 (트랜잭션 폐기 필드(1010) 내의) 트랜잭션 폐기 상태를 전송하는 단계를 포함하는 새로운(수정된) 블록들(1205 및 1210)과 함께, 도 8의 블록들을 포함한다.
도 12에서, 수신/리모트 프로세서(예를 들어, CPU 2(112b))에 의한 요청 처리 단계는 본 발명의 실시 예에 따라 요청을 수신한다. 리모트 프로세서 (CPU 2)는 블록(805)에서 요청 프로세서(CPU 1)로부터 데이터에 대한 XI 요청(예를 들어, 요청(505) 및/또는 요청(605))을 수신한다. 블록(810)에서, 리모트 프로세서(CPU 2)가 데이터를 참조하는 트랜잭션을, 수신된 요청, 예를 들어 요청(505 및 605)과 호환 될 수 없는 방식으로, 처리하고 있는지를 확인함으로써, 리모트 프로세서는 간섭이 검출되었는지를 확인한다. 예를 들어, 한 예시적 실시 예에서, 리드 공유 요청(a read shared request)은 트랜잭션 리드 세트 내의 데이터에 대한 참조와는 호환 가능하지만, 라이트 요청은 호환가능 하지 않다. 이에 더하여, 리드-배타, 리드 확장(즉, 공유에서 배타로의 변경) 또는 라이트 요청(a read-exclusive, read escalation (i.e., change from shared to exclusive) or write request)은 트랜잭션의 리드 또는 라이트 세트 어느 쪽에서든지 참조되는 동일 데이터와는 호환 가능성이 없다. 리모트 프로세서 (CPU 2(112b))가 블록(810)에서 요청 프로세서(CPU 1(112a))에 의해서 요청된 데이터를 현재 리모트 프로세서(자신)가 사용하고 있는 것으로 결정하면, 리모트 프로세서는 간섭이 검출된다고 결정하고(YES) 블록(815)에서 리모트 프로세서에서 처리 중인 로컬 트랜잭션을 리모트 프로세서(CPU 2)는 폐기한다. 일단 리모트 프로세서(CPU 2)에서 로컬 트랜잭션이 폐기되면, 리모트 프로세서는 블록(1205)에서 트랜잭션 상태 필드(1010)와 함께 리드 응답(READ RESPONSE)을 갖는 데이터(이는 요청이 (이전에 실행 중인) 트랜잭션을 그 요청을 충족시키기 위해 리모트/수신 프로세서(CPU 2)에서 폐기 하도록 하였음을 통지한다)를 요청 프로세서(CPU 1)에 전송한다. 다른 실시 예에서, 리모트 프로세서는 라이트 응답(1105)을 갖는 라이트 요청을 수신 할 수 있다. 최신 시스템들에서, 트랜잭션 상태 필드(1010)는 (이전에 자기 자신의 트랜잭션을 실행하고 있었고 이제는 폐기한) 리모트 프로세서(CPU 2)로부터 (요청(505 및/또는 605)을 내보낸) 요청 프로세서(CPU 1)로 돌려 보내진 응답(RESPONSE) 내에 포함되지 않을 수도 있다. 리모트 프로세서(CPU 2)는 블록(825)에서 데이터 상태를 변경하고 선택에 따라 필요하다면 자신의 로컬 캐시들로부터 데이터를 제거한다. 리모트 프로세서(CPU 2)는 블록(830)에서 트랜잭션 실패 처리를 개시하고 플로는 종료한다. 리모트 프로세서(CPU 2(112b))는 블록(810)에서 요청 프로세서(CPU 1(112a))에 의해서 요청된 데이터를 리모트 프로세서가 현재 사용하고 있지 않다고 결정하면, 리모트 프로세서는 간섭이 검출되지 않았다고 결정하고(NO) 리모트 프로세서는 블록(1210)에서 트랜잭션 상태 필드(1010)와 함께 리드 응답(READ RESPONSE)을 갖는 데이터(이는 요청이 트랜잭션이 폐기되도록 하지 않았음을 표시한다)를 전송한다. 리모트 프로세서 (CPU 2)는 블록(840)에서 데이터 상태를 변경하고 선택에 따라 필요한 경우 로컬 캐시들로부터 데이터를 제거하고, 플로는 종료한다.
도 13은 본 발명의 한 실시 예에 따라 요청 프로세서(CPU 1(112a)에 의한 프로토콜 요청 시작 및 처리(protocol request origination and processing)를 예시하는 흐름도(1300)를 도시한다. 도 13은 도 7에서 위에서 논의한 블록들을 포함하고 도 7의 논의는 반복되지 않는다. 추가로, 흐름도(1300)는 새로운 블록들(1305 및 1310)을 포함한다. 예를 들어, 요청 프로세서(CPU1)는 블록(1305)에서 새로운 트랜잭션 폐기 상태 필드(1010)와 함께 리모트 프로세서 (CPU 2)로부터의 데이터를 갖는 XI 응답을 수신한다(블록(725)). 요청 프로세서(CPU 1)는 블록(730)에서 그 데이터를 (L1 및/또는 L2 캐시들과 같은) 로컬 캐시들 내에 배치한다. 블록(1310)에서, 요청 프로세서(CPU 1)는 수신된 상태(예를 들어, 트랜잭션 상태 필드(1010) 내의 정보)를 데이터 캐시(118a) (및/또는 메모리(310)) 내의 로컬 트랜잭션 간섭 추적 테이블(1350a)에 추가한다. 로컬 트랜잭션 간섭 추적 테이블(1350a)은 요청 프로세서(CPU 1)가 (리모트 프로세서(CPU 2)에서 트랜잭션 폐기를 초래하는) 간섭을 일으킬 때 그 간섭을 추적하는 스토리지 위치일 수 있으며 로컬 트랜잭션 간섭 추적 테이블(1350a)은 이 정보의 로그를 포함할 수 있다. 로컬 트랜잭션 간섭 추적 테이블(1350a)은 증가 통계 값(increment statistics)과 현재 트랜잭션 상태를 포함한다. 상기 증가 통계 값(수신 프로세서 (CPU 1)에 보고된)은 각각의 트랜잭션 폐기에 대해 증가하고 상기 증가 통계 값은 공유/배타(R/W) 요청들 및 누계 요청들(aggregated requests)로 분리될 수 있다. 로컬 트랜잭션 간섭 추적 테이블(1350a)은 요청 프로세서 (CPU 1)에 트랜잭션 폐기가 일어날 때마다 그리고 요청 프로세서(CPU 1)에서 폐기된 트랜잭션이 없을 때 마다 증가하는(increment) 카운터(a counter)를 포함할 수 있다. 일부 실시 예들에서, 블록(1310)과 관련하여 수신된 트랜잭션 폐기 상태는 또한, 동적 최적화기들(dynamic optimizers), 저스트 인 타임(just in time: JIT) 컴파일러들을 위해 정보를 이용 가능하게 하기 위해, 또는 프로그래머들에 의한 성능 튜닝(performance tuning)을 위해, 성능 모니터링 유닛(a performance monitoring unit), 런타임 계측 유닛(a runtime instrumentation unit), 및/또는 다른 성능 추적 논리(another performance tracking logic)에서 집계될 수 있다. 정보는 스토리지에, 성능 모니터링에 특화된 구조들(structures directed at performance monitoring)에 로그함으로써, 그리고/또는 통지들, 예를 들어 파워 ISA(Power ISA™)에 따른PMU 이벤트 기반 분기들을 통지함으로써 기록될 수 있다. 보고에는 간섭의 성격, 간섭하는 및/또는 간섭되는 트랜잭션의 식별, 프로세서 ID들, 그러한 간섭에 종속하는 어드레스들, 등이 포함될 수 있다.
여기서 논의한 바와 같이, 일관성 프로토콜들은 다수의 비트들 ― 어드레스, 데이터, 및 상태 그리고 컨트롤 비트들을 사용한다. 이들 데이터는 데이터 요청을 발행하기 위해서, 그리고 그것의 소유권(예를 들어, 공유, 배타)과 상태(예를 들어, 더티, 클린)를 표시하기 위해서 사용된다. (트랜잭션 폐기 상태 필드(1010)를 위해) 추가의 하나 또는 그 이상의 비트들이 추가되는데, 이는 요청이 트랜잭션을 폐기시켰거나 그리고/또는 트랜잭션을 폐기시킬 수도 있었음을 표시하기 위해서이다. 예를 들어, 상태 비트(트랜잭션 폐기 상태 필드(1010))는 요청된 데이터가 리모트 프로세서(CPU2)에 의해서 포기되었을 때, 그 데이터는 트랜잭션 실행에 대해서 충돌을 일으켰음을 표시한다. 전술한 바와 같이, 요청에 대한 응답은 트랜잭션이 진행 중이라는 표시와, 그 요청이 트랜잭션을 폐기되게 하였다는 표시로 되돌아 올 수 있다.
한 실시 예에서, 폐기된 트랜잭션에서 명령들의 수와 같은 추가의 측정값(additional metrics)이 트랜잭션 폐기 상태 필드(1010)에 전송된다. 한 실시 예에서, 표시들은 무한반복의 시나리오를 피하려고, 연기(a holdoff)를 결정하기 위해서, 예를 들어 성공적인 트랜잭션(the winning transaction)이 나중에 폐기되고 재시작되는 경우 트랜잭션의 재시작에 관해서 결정하기 위해 사용된다. 요청 프로세서(CPU 1)가 로컬 트랜잭션 폐기 상태 필드(1010)를 확인함으로써 리모트/수신 프로세서(CPU 2)에서 너무 많은(예를 들어, 미리 정의된 양보다 많은) 트랜잭션 폐기들을 요청프로세서가 일으킨다고 결정할 때, 요청 프로세서(CPU 1)는 전체 시스템 스루풋(throughput)을 증가시키기 위해서 너무 많은 리모트 트랜잭션들을 폐기하는 것에 응답하여 또한 자신의 요청 속도를 조절할 수 있다(감소할 수 있다).
또 다른 실시 예에서, (트랜잭션 폐기 상태 필드(1010)에서의) 그러한 통지들은 로그들에서 수집되어서 그리고/또는 통제 메커니즘(예를 들어, 예외)을 통해서 동적 재최적화 컴포넌트(a dynamic reoptimization component)에 통지된다; 동적 재최적화 컴포넌트는 코드를 간섭을 감소시키기 위해 동적으로 재최적화 할 수 있고 그리고/또는 트랜잭션들 대신에 락들을 사용하기 위해 대체 코드를 생성할 수 있다.
이제, 도 9의 블록들은 도 14에 포함되지만, 그들에 관한 논의는 반복되지 않을 것이다. 도 14는 또한 도 9에 대한 수정도 포함한다. 도 14는 본 발명의 한 실시 예에 따라 프로세서가 처리하는 트랜잭션을 예시하는 흐름도(1400)를 도시한다. 여기서 프로세서는 요청 프로세서(CPU 1)로 가정될 수 있다. 도 14는, 블록(1405)와 함께, 도 9의 블록들을 포함한다. 블록(1405)에서, 요청 프로세서(CPU 1)은 블록(1405)에서 레지스터(334), 캐시(118a), 및/또는 메모리(310)에 (새로운 트랜잭션 폐기 상태 필드(1010)로부터 획득되고 로컬 추적 트랜잭션 간섭 스토리지 테이블(1350a)에 저장되는) 트랜잭션 간섭 통계 정보를 포함하는 (트랜잭션 진단 블록(TDB) 같은)트랜잭션 정보를 라이트한다. 한 실시 예에서, 트랜잭션이 완료되면, 그 트랜잭션이 하나 또는 그 이상의 트랜잭션들을 결과 코드(a result code), 예를 들어, 결과 레지스터(a result register), 결과 조건 레지스터(result condition register), 등의 일부로서 폐기 되도록 (예를 들어, 레지스터들(334a, 334b)에서) 하였는지에 관한 표시를 그 트랜잭션은 포함할 수 있다. 한 실시 예에서, 트랜잭션이 하나 또는 그 이상의 레지스터들(예를 들어, 레지스터들(334a, 334b)) 및/또는 메모리 위치들에 결과 상태(a result status)를 세트하면, 하나 또는 그 이상의 레지스터들(예를 들어, 레지스터들(334a, 334b)에서) 및/또는 메모리 위치들(예를 들어, 메모리(310), 캐시들(118a, 118b)에서)은 그 트랜잭션에 대해 데이터, 즉 간섭의 성격(라이트 세트와 함께 하는 리드 요청, 또는 리드 혹은 라이트 세트와 함께 하는 라이트 요청, 등)을 제공하기 위해 간섭이 있어서 폐기되었던 트랜잭션들의 수를 포함할 수 있다. 한 실시 예에서, 그렇게 저장된 정보는 트랜잭션들의 각각에 관한 구체적인 정보를 포함할 수 있는데, 이는 (예를 들어, 트랜잭션 시작 XBEGIN 또는 TBEGIN의 어드레스, 토큰(a token), 트랜잭션 ID, 등을 명시함으로써) 간섭이 일어난 프로세서, 폐기된 트랜잭션, 폐기되기 전에 그 트랜잭션에 의해 수행되었던 작업의 측정값, 등을 식별하기 위한 방법을 포함한다. 한 실시 예에서, 간섭과 트랜잭션 폐기 상태에 대응하는 추가 필드들을 갖기 위해 본 발명에 따라 최신 트랜잭션 진단 블록이 확장될 때, 하나 또는 그 이상의 메모리 위치들에 저장된 정보는, 예를 들어, (여기서 참조로 포함된) z/아키텍처에 따른 트랜잭션 진단 블록(TDB)의 메모리 위치들에 대응하고, 그리고 본 발명에 따른 트랜잭션 진단 블록의 필드들에 대응하는데, 본 발명에 따른 트랜잭션 진단 블록의 필드들은 새롭게 도입된 프로토콜 필드들에 의해서, 그리고/또는 복수의 그러한 필드들로부터 집계된 정보에 의해서 개별적으로 전송된 정보에 대응한다. 다른 실시 예에서, 레지스터들 및/또는 메모리 위치들에 저장된 정보는 최신 기술의 TDB와 구별되고(distinct), 분리되며(separate) 그리고 독립적(independent)으로 제공된다.
블록(1405)에서, 요청 프로세서(CPU 1)는 성능 감시 유닛 및/또는 런타임 계측 유닛을 통해 간섭 통계 정보를 프로그래머에게 제공하고, 간섭 정보를 펌웨어, 밀리코드, 등에게 제공하도록 구성된다. 밀리코드에서, 밀리코드 코드는 무한 반복을 피하기 위해 간섭 통계 정보를 사용하고, 그리고/또는 간섭 통계 정보를 트랜잭션 재시작을 최적화하기 위해 사용할 수 있다. 애플리케이션에서, 애플리케이션은 무한반복을 피하고 트랜잭션 재시작을 최적화 하기 위해 간섭 통계 정보를 사용할 수 있다.
본 발명의 실시 예에 따라, 코드의 예가 설명 목적으로 아래에서 제공된다.
다음의 슈 코드(pseudo code)(프로세서들 (112a, 112b)에서 실행되는)는 트랜잭션이 폐기되었고, 특히 무한 반복 시나리오를 피하기 위해 최적화 되었을 때 트랜잭션을 재시작하기 위해서 밀리코드로 투명하게 하든지 및/또는 프로세서 상에서 실행하는 애플리케이션에 통합된 코드에 의해서 하든지 어느 쪽으로도 트랜잭션 재시작의 최적화를 수행하는 하나의 형식을 제공한다. 코드의 예는 TDM에 저장된 정보를 예를 설명하기 위해 사용하지만, 그러나 통상의 지식을 가진 자는, 메모리 위치들(예를 들어, 메모리(310)), 레지스터들(334a, 334b), 상태 코드들, 및/또는 성능 감시 유닛, 런타임 계측 유닛, 등으로부터 획득되는 정보를 사용할 수 있지만, 이에 한정되지 않는다:
본 발명의 예시적인 코드에 따라서, 트랜잭션 재시작 코드는 그것이 스스로 폐기되었는지 그리고 차례로 다른 트랜잭션을 폐기하였는지를 확인하는 수단들을 포함한다. 한 실시 예에서, 무한 반복 가능성(a possible livelock)은 즉시 진단된다. 다른 실시 예에서, 현재 트랜잭션과 간섭을 받는 트랜잭션이 사이클 간섭 그래프(a cyclical interference graph)의 일부인지(즉, 각각의 트랜잭션은 직접적으로든지 또는 간접적으로든지 어느 경우든지 다른 트랜잭션을 폐기 시키는지)에 대한 테스트가 수행된다(도시되지 않음). 한 실시 예에서, 상호 격추(a mutual shootdown)가 진단될 때, 간섭 회피 액션들이 취해진다. 한 실시 예에서, 상호 격추가 진단될 때, 무한 반복 회피 액션들이 취해진다. 한 실시 예에서, 간섭 회피 액션들을 "avoid_livelock() 기능[무한 반복을 피한다() 기능]"을 호출함으로써 작동된다. 일부 실시 예들에서, 이들 액션들은 다음과 같은 현재 트랜잭션의 하나 또는 그 이상의 하위 우선순위(one or more of lower priority of present transaction)를 포함할 수 있지만, 이에 한정하는 것은 아니다; 백오프 기간 동안 대기한다(wait for backoff period); 락들을 사용하여 동기화 한다(synchronize using locks); 등등.
[000204] 다른 예시적 실시 예에서, 다음의 슈도 코드는, 트랜잭션이 폐기되고, 특히 무한반복 시나리오를 피하도록 최적화되었을 때 트랜잭션을 재시작하기 위해서 트랜잭션 재시작 최적화를 (밀리코드에서 투명하게든지 또는 프로세서 상에서 실행하는 애플리케이션에 통합된 코드에 의해서든지 어느 쪽으로든지) 수행하는 한 형식을 제공한다. 예시적인 코드는 예시적인 방식으로 TDB에 저장된 정보를 사용한다: 그러나 통상의 지식을 가진 자들은, 메모리 위치들, 레지스터들, 상태 코드들, 또는 성능 감시 유닛, 런타임 계측 유닛, 등(이들을 포함하지만 이에 한정하는 것은 아니다)으로부터 획득된 정보를 사용할 수 있을 것이다. 예시적인 코드에서, 트랜잭션이 (있을 수 있는) 상호 격추들의 임계 값을 초과한 트랜잭션에 대응될 때 그것은 무한반복 방지 연산들을 취한다:
예시적인 코드에 따라서, 트랜잭션 재시작 코드는 트랜잭션이 스스로 폐기되었는지 그리고 차례로 다른 트랜잭션을 폐기하였는지를 확인하는 수단들(checks)을 포함한다. 한 실시 예에서, 무한 반복 가능성(a possible livelock)은 즉시 진단된다. 다른 실시 예에서, 현재 트랜잭션과 간섭을 받는 트랜잭션이 사이클 간섭 그래프(a cyclical interference graph)의 일부인지(즉, 각각의 트랜잭션이 직접적으로든지 또는 간접적으로든지 어느 경우든지 다른 트랜잭션을 폐기시키는지)에 대한 테스트가 수행된다(도시되지 않음). 한 실시 예에서, 상호 격추(a mutual shootdown)가 진단될 때, 간섭 회피 액션들이 취해진다. 한 실시 예에서, 상호 격추들의 수가 임계 값 이상으로 진단될 때(상호 격추의 수 > 임계 값 일 때), 간섭 회피 액션들이 취해진다. 한 실시 예에서, 상호 격추들의 수가 임계 값 이상으로 진단되었을 때(상호 격추의 수 > 임계 값 일 때), 무한반복 회피 액션들이 취해진다. 한 실시 예에서, 간섭 회피 액션들을 "avoid_livelock() 기능"을 호출함으로써 작동된다. 일부 실시 예들에서, 이들 액션들은 다음과 같은 현재 트랜잭션의 하나 또는 그 이상의 하위 우선순위(one or more of lower priority of present transaction)를 포함할 수 있지만, 이에 한정하는 것은 아니다; 백오프 기간 동안 대기한다(wait for backoff period); 락들을 사용하여 동기화 한다(synchronize using locks); 등등.
재시작 최적화(밀리코드에서 투명하게 또는 애플리케이션에서):
예시적인 코드에 따라서, 트랜잭션 재시작 코드는 트랜잭션이 스스로 폐기되었는지 그리고 차례로 다른 트랜잭션을 폐기하였는지를 확인하는 수단들(checking)을 포함한다. 한 실시 예에서, 무한 반복 가능성(a possible livelock)은 즉시 진단된다. 한 실시 예에서, 상호 격추들의 수가 임계값 이상으로 진단될 때(상호 격추의 수 > 임계값 일 때), 한 테스트 live_lock_loop_detected()가 수행되는데, 이는 만일 현재 트랜잭션과 간섭된 트랜잭션이 사이클 간섭 그래프(a cyclical interference graph)의 일부라면(즉, 각각의 트랜잭션이 직접적으로든지 또는 간접적으로든지 어느 경우든지 다른 트랜잭션을 폐기시킨다면) ― 다른 실시 예에서는 일부 일 수 있다면 ― 응답 폐기 상태 메시지들(response abort status messages)을 통해 그리고 선택적으로 다른 수단들과 관련하여 수신된 추가의 정보에 액세스할 수 있다. 만일 그러하다면, 무한반복 액션들이 취해진다. 한 실시 예에서, 무한반복 회피 액션들을 "avoid_livelock() 기능"을 호출함으로써 작동된다. 일부 실시 예들에서, 이들 액션들은 다음과 같은 현재 트랜잭션의 하나 또는 그 이상의 하위 우선순위(one or more of lower priority of present transaction)를 포함할 수 있지만, 이에 한정하는 것은 아니다; 백오프 기간 동안 대기한다(wait for backoff period); 락들을 사용하여 동기화 한다(synchronize using locks); 등등.
본 발명의 실시 예에 따라, 도 15는 프로세서(예를 들어, 요청 프로세서 CPU 1)가 간섭 표시, 예를 들어 트랜잭션 폐기 상태 필드(1010) 내의 정보로부터 로컬 추적 트랜잭션 간섭 스토리지 테이블(1350a)에 저장된(그리고 증가된/추적된) 간섭 표시에 대해 어떻게 반응하는지를 예시하는 흐름도(1500)를 도시한다. 요청 프로세서(CPU 1)는 블록(1505)에서 간섭 통계 정보를 보고한다. 간섭 통계 정보를 보고하는 것에는 블록(1405)에서 논의한 바와 같이 트랜잭션을 라이트하는 것이 포함될 수 있다. 블록(1510)에서, 요청 프로세서(CPU 1)는 반복된 간섭을 피하기 위해 간섭 비용이 언제 너무 높게 되는지를 결정함에 의해 추가의 동기화가 가능한지를 결정한다. 간섭 비용은 요청 프로세서(CPU 1)가 미리 정의된 횟수로(예를 들어, 4회) 반복적으로 수신/리모트 프로세서(CPU 2) 상에서 실행 중인 (동일) 트랜잭션을 폐기할 때 및/또는 트랜잭션이 폐기되기 전에 명령들의 미리 정의된 수의 클록 사이클들(예를 들어, 10,000 클록 사이클들)을 완료하였을 때 너무 높게 된다.
요청 프로세서(CPU 1)가 블록(1510)에서 반복된 간섭(요청 프로세서(CPU 1)로부터의 데이터에 대한 요청에 의해서 일어난 리모트 프로세서(CPU 2) 상의 반복된 트랜잭션 폐기들)을 피하기 위한 추가의 동기화가 가능하지 않다고 결정하면, 요청 프로세서(CPU 1)는 블록(1515)에서 코드 재최적화가 가능한지 확인한다. 요청 프로세서(CPU 1)가 재최적화가 가능하다고 결정하면, 요청 프로세서는 블록(1520)에서 코드를 재최적화한다. 요청 프로세서(CPU 1)가 재최적화는 가능하지 않다고 결정하면, 요청 프로세서는 블록(1525)에서 (백오프와 같은 관용 조치들을 포함하는) 현재 코드로 진행한다. 백오프(Backoff)는 수신/리모트 프로세서(CPU 2)가 (폐기해야 함이 없이) 실행을 완료할 트래잭션을 위한 시간을 수신/리모트 프로세서(CPU 2)가 갖도록 하기 위해서 요청 프로세서가 데이터에 대한 요청을 하기 전에 미리 정의된 시간의 기간 동안 기다려야 한다고 결정할 때 필요하다.
요청 프로세서(CPU 1)가 블록(1510)에서 반복된 간섭(요청 프로세서(CPU 1)로부터의 데이터에 대한 요청에 의해서 일어난 리모트 프로세서(CPU 2) 상의 반복된 트랜잭션 폐기들)을 피하기 위해 추가의 동기화가 가능하다고 결정하면, 요청 프로세서(CPU 1)는 블록(1530)에서 대체 동기화를 이용한다. (동일 트랜잭션(즉, 동일 캐시/메모리 어드레스를 갖는)의) 반복된 간섭이 리모트/수신 프로세서(CPU 2) 상에서 언제 일어났는지를 결정하기 위해 요청 프로세서(CPU 1)는 블록(1535)에서, 예를 들어 로컬 추적 트랜잭션 간섭 스토리지 테이블(1350a) 내의 로그를 확인한다. 반복된 간섭이 존재하지 않으면, 플로는 블록(1525)로 진행한다. 요청 프로세서(CPU 1)가 (리모트/수신 프로세서(CPU 2) 상의 동일 폐기된 트랜잭션에 대하여) 반복된 간섭이 존재한다고 결정하면, 요청 프로세서는 블록(1540)에서 코드 재최적화가 가능한지를 확인한다. 재최적화가 가능하면, 요청 프로세서(CPU 1)는 블록(1545)에서 코드를 재최적화 한다.
요청 프로세서(CPU 1)가 코드 재최적화가 가능하지 않다고 결정하면, 요청 프로세서(CPU 1)는 블록(1550)에서 리모트/수신 프로세서(CPU 2)로부터 데이터를 요청하는 (요청 프로세서(CPU 1) 상에서 실행하는) 이 특정 트랜잭션을 위해 영구적으로 (및/또는 정의된 기간 동안) 대체 동기화 방법을 선택하도록 구성된다.
본 발명의 한 실시 예에 따라, 도 16은, 예를 들어 트랜잭션 폐기 상태 필드(1010) 내의 정보로부터 로컬 추적 트랜잭션 간섭 스토리지 테이블(1350a)에 저장되는 (그리고 증가되고/추적되는) 간섭 표시에 대해 프로세서(예를 들어, 요청 프로세서 (CPU 1))가 어떻게 반응하는지를 예시하는 흐름도(1600)를 도시한다. 도 16은, 블록(1605)가 블록(1540)을 대체하는 것을 제외하고는, 도 15의 블록들을 포함한다. 도 15의 블록들이 반복되지는 않는다.
블록(1535)이 YES이면, 플로는 도 16에서 블록(1605)로 진행한다. 블록(1605)에서, 요청 프로세서(CPU 1)는 재최적화 또는 대체 동기화가 바람직한지 확인한다. 블록(1605)에서 결정이 YES라면, 플로는 블록(1545)로 진행한다. 블록(1605)에서 결정이 NO라면, 플로는 블록(1550)으로 진행한다. 도 15의 블록(1540)에서, 코드 재최적화가 가능하다고 할 때, 코드 재최적화는 항상 수행된다. 블록(1605)에서, 코드 재최적화 또는 대체 동기화 방법(예를 들어, 락들)이 바람직한지를 결정하기 위해 측정기준(a metric)이 계산되고, 그리고 하나 또는 다른 것이 선택된다. 이것은, 예를 들어, 대체 동기화 방법을 사용하는 것의 총 비용과 재최적화를 수행하는 비용 플러스 재최적화된 비용을 사용하는 것의 비용을 비교하여 어느 것이 바람직한지를 결정하는 테스트에 기초할 수 있다. 예를 들어 재최적화 비용을 임계값과 비교함으로써, 재최적화 오버헤드의 비용을 최소화하는 것과 같은 다른 측정 기준들도 가능하며 본 발명에서도 고려하였다.
도 17은 본 발명의 한 실시 예에 따라 일관성 프로토콜을 구현하기 위한 방법(프로세서들(112a, 112b)에 의해서 실행되는)의 흐름도(1700)를 도시한다.
블록(1705)에서, 요청 프로세서(112a)(CPU 1)는 데이터에 대한 (요청들(505, 605)와 같은) 요청을 인터커넥트(122)를 통해 리모트 프로세서(112b)(CPU 2)로 내보낸다. 블록(1710)에서, 요청 프로세서(112a)(CPU 1)는 리모트 프로세서(112b)(CPU 2)로부터 (응답들(1005, 1105)와 같은) 응답을 수신하는데, 상기 응답은 리모트 프로세서(112b) 상의 리모트 트랜잭션(예를 들어 트랜잭션(320b))의 트랜잭션 상태(예를 들어, 트랜잭션 폐기 상태(1010))를 포함한다. 블록(1715)에서, 요청 프로세서(112a)는 리모트 프로세서 상의 리모트 트랜잭션의 트랜잭션 상태(필드(1010)로부터의 정보)를 로컬 트랜잭션 간섭 추적 테이블(예를 들어, 테이블(1350a)에 추가한다.
전술한 하나 또는 그 이상의 특징들에 더하여, 또는 대안으로서, 본 발명의 실시 예들은 리모트 트랜잭션의 트랜잭션 상태가 (요청 프로세서(112a)에 의하여) 트랜잭션 진단 블록(TDB)에 추가되는 것을 더 포함할 수 있다. 리모트 트랜잭션은 리모트 프로세서(112b) 상에서 실행하고 데이터에 대한 요청을 리모트 프로세서에 내보내는 것에 기초하여 실행을 폐기한다. 상기 요청은 요청 트랜잭션(예를 들어 트랜잭션(320a))에 의한 것이고, 상기 요청 트랜잭션은 상기 요청을 내보내는 요청 프로세서(112a) 상에서 실행 중이다.
전술한 하나 또는 그 이상의 특징들에 더하여, 또는 대안으로서, 본 발명의 실시 예들은 리모트 트랜잭션(예를 들어 트랜잭션(320b))이 리모트 프로세서(112b)에서 폐기되도록 하는 요청 트랜잭션에 의한 요청에 기초하여, 요청 프로세서(112a)는 리모트 트랜잭션의 트랜잭션 상태(필드(1010)로부터 획득된)를 로컬 트랜잭션 간섭 추적 테이블(1350a)에 추가하고 리모트 트랜잭션(폐기되는 각 특정 트랜잭션(320b))에 대해 일어났던 트랜잭션 폐기들의 카운트를 증가하는 것을 더 포함할 수 있다.
전술한 하나 또는 그 이상의 특징들에 더하여, 또는 대안으로서, 본 발명의 실시 예들은 리모트 프로세서(112b)로부터 응답(1005, 1105) 내의 요청 프로세서(112a)에 의해 수신된, 리모트 트랜잭션의 트랜잭션 상태는 요청 프로세서(112a)로부터의 요청(505, 605)을 수신하는 것에 기초하여 리모트 트랜잭션(트랜잭션(320b))이 폐기되어야 했음을 표시하는 것을 더 포함할 수 있다.
전술한 하나 또는 그 이상의 특징들에 더하여, 또는 하나의 대안으로서, 본 발명의 실시 예들은 추가적으로 로컬 트랜잭션 간섭 추적 테이블(1350a)을 포함하는데, 이는 요청 프로세서(112a) 상에서 실행 중인 요청 트랜잭션(320a)에 의해서 간섭되고 폐기된 다수의 트랜잭션들을 유지한다. 로컬 트랜잭션 간섭 추적 테이블(1350a)은 리모트 프로세서들(112b)(및 기타 프로세서들) 상의 리모트 트랜잭션들(320b)을 기술하는 정보를 유지한다. 리모트 프로세서들(112a) 상의 리모트 트랜잭션들(320b)을 기술하는 정보는 다음 중 적어도 하나를 포함한다: 상기 프로세서 상에 실행 중인 요청 트랜잭션에 의해서 일어난 간섭의 타입, 요청 트랜잭션에 의해서 폐기된 리모트 트랜잭션들 각각의 식별 정보(identification) 또는 어드레스, 간섭이 발생한 리모트 프로세서들 각각의 식별정보, 폐기된 리모트 트랜잭션들 각각의 어드레스, 및/또는 폐기되기 전에 리모트 트랜잭션들의 각각에 의해서 수행된 작업 량(a measure of work).
기술적 효과들 및 장점들에는 트랜잭션 상태에 관한 추가적인 정보를 포함하도록 확장된 일관성 프로토콜(a coherence protocol)이 포함된다. 프로세서가 트랜잭션 실행 중일 때, 일관성 요청은 수신 프로세서의 트랜잭션 실행이 폐기되도록 할 수 있는데, 충돌이 검출되기 때문이다. 일관성 프로토콜 요청은 본 발명의 실시 예들에 따라 수신 프로세서가 자신의 트랜잭션 실행을 폐기했다는 추가의 정보로 확장된다.
여기서 사용된 용어는 특정 실시 예들을 기술할 목적으로만 사용된 것이며 발명의 범위를 제한하려 의도된 것이 아니다. 여기서 사용된 바와 같이, 단수 형식들은, 달리 문맥 상 명백하게 표시하지 않는 한, 복수의 형식들도 또한 포함하도록 의도 되었다. "포함하다" 및/또는 "포함하는" 이라는 용어들은, 이 명세서에서 사용되었을 때, 진술된 특징들, 정수들, 단계들, 연산들, 엘리먼트들, 및/또는 컴포넌트들의 존재를 명시하지만, 하나 혹은 그 이상의 다른 특징들, 정수들, 단계들, 연산들, 엘리먼트들, 컴포넌트들 및/또는 그들의 그룹들의 존재 혹은 추가를 배제하는 것이 아님을 이해하여야 한다.
아래 청구항들 내의 대응 구조들, 재료들, 동작들, 및 모든 수단들 혹은 단계 플러스 기능 엘리먼트들의 균등물들은 명시적으로 청구된 다른 엘리먼트들과 조합하여 기능을 수행하기 위한 모든 구조, 재료, 혹은 동작을 포함하도록 의도된다. 본 발명의 상세한 설명은 예시와 설명의 목적으로 제공되었지만, 개시된 형식 내의 발명이 전부라거나 혹은 한정되도록 의도되지 않았다. 본 발명의 범위와 정신을 벗어남이 없이 많은 수정들과 변경들이 당업자들에게 명백하다. 실시 예는 본 발명의 원리들과 실용적 응용을 최선으로 설명하기 위해서, 그리고 당업자들이 고려된 특정 사용에 적합한 다양한 수정들을 갖는 다양한 실시 예들에 대해 본 발명을 이해할 수 있도록 하기 위해서 선택되고 기술되었다.
본 발명의 다양한 실시 예들에 관한 상세한 설명은 예시의 목적으로 제공되었지만, 개시된 실시 예들이 전부라거나 혹은 한정되도록 의도되지 않았다. 기술된 실시 예들의 범위와 정신을 벗어남이 없이 많은 수정들과 변경들이 당업자들에게 명백하다. 여기서 사용된 용어들은 실시 예들의 원리들, 실용적 응용 또는 시장에서 발견된 기술들에 관한 기술적 개선을 최선으로 설명하기 위해서, 또는 여기서 개시된 실시 예들을 당업자들이 이해할 수 있도록 하기 위해서 선택되고 기술되었다.
이제 도 18을 참조하면, 컴퓨터 판독 가능 스토리지 매체(1802) 및 프로그램 명령들(1804)을 포함하는 본 발명의 한 실시 예에 따른 컴퓨터 프로그램 제품(1800)이 일반적으로 도시되어 있다.
본 발명은 시스템, 방법, 및/혹은 컴퓨터 프로그램 제품이 될 수 있다. 컴퓨터 프로그램 제품은 프로세서가 본 발명의 특징들을 수행하도록 그 위에 컴퓨터 판독가능 프로그램 명령들을 갖는 컴퓨터 판독가능 스토리지 매체들(또는 매체)을 포함할 수 있다.
컴퓨터 판독 가능 스토리지 매체는 명령 실행 디바이스에 의한 사용을 위해 명령들을 보유하고 저장할 수 있는 유형의 디바이스일 수 있다. 컴퓨터 판독 가능 스토리지 매체는, 예를 들어, 전자 스토리지 디바이스, 자기 스토리지 디바이스, 광 스토리지 디바이스, 전자기 스토리지 디바이스, 반도체 스토리지 디바이스, 혹은 모든 이들의 적절한 조합이 될 수 있으며, 이에 한정되지 않는다. 컴퓨터 판독 가능 스토리지 매체의 더 구체적인 예들은 다음을 포함할 수 있다: 휴대용 컴퓨터 디스켓, 하드 디스크, 랜덤 액세스 메모리(RAM), 판독-전용 메모리(ROM), 지울 수 있고 프로그램 가능한 판독-전용 메모리(EPROM 혹은 플래시 메모리), 정적 랜덤 액세스 메모리(SRAM), 휴대용 콤팩트 디스크 판독-전용 메모리(CD-ROM), 디지털 다목적 디스크(DVD), 메모리 스틱, 플로피 디스크, 홈에 명령들을 기록하는 펀치-카드들 또는 융기된 구조물들과 같은 기계적으로 인코드된 디바이스, 및 이들의 모든 적절한 조합. 여기서 사용되는, 컴퓨터 판독 가능 스토리지 매체는 라디오 전파들 또는 기타 자유롭게 전파되는 전자파들, 도파관 또는 기타 전송 매체를 통해서 전파되는 전자파들과 같은 전송 신호들 그 자체(예를 들어, 광-섬유 케이블을 통해 전송되는 광 펄스들), 또는 전선을 통해 전달되는 전기 신호들인 것으로 해석되지는 않는다.
여기서 기술한 컴퓨터 판독 가능 프로그램 명령들은 컴퓨터 판독 가능 스토리지 매체로부터 각 컴퓨팅/처리 디바이스들로 다운로드될 수 있거나 또는, 예를 들어 인터넷, 근거리 통신 네트워크, 원거리 통신 네트워크 및/또는 무선 네트워크와 같은 네트워크를 통해 외부 컴퓨터 또는 외부 스토리지 디바이스에 다운로드될 수 있다. 상기 네트워크에는 구리 전송 케이블들, 광 전송 섬유들, 무선 전송, 라우터들, 방화벽들, 스위치들, 게이트웨이, 컴퓨터들 및/또는 엣지 서버들이 포함될 수 있다. 각 컴퓨팅/처리 디바이스 내 네트워크 어댑터 카드 또는 네트워크 인터페이스는 네트워크로부터 컴퓨터 판독 가능 프로그램 명령들을 수신하여, 그 컴퓨터 판독 가능 프로그램 명령들을 각 컴퓨팅/처리 디바이스 내의 컴퓨터 판독 가능 스토리지 매체 내에 저장하기 위해 전송한다.
본 발명의 연산들을 수행하기 위한 컴퓨터 판독가능 프로그램 명령들은 하나 이상의 프로그래밍 언어들의 조합으로 작성된, 어셈블러 명령들, 명령-세트-아키텍처(ISA) 명령들, 머신 명령들, 머신 종속 명령들, 마이크로코드, 펌웨어 명령들, 상태-세팅 데이터, 또는 소스 코드 또는 객체 코드가 될 수 있으며, 이들 언어들은 Smalltalk, C++ 혹은 이와 유사한 것과 같은 객체 지향 프로그래밍 언어와, "C" 프로그래밍 언어 혹은 유사한 프로그래밍 언어들과 같은 종래의 절차적 프로그래밍 언어들을 포함한다. 컴퓨터 판독가능 프로그램 명령들은 전적으로 유저의 컴퓨터 상에서, 부분적으로 유저의 컴퓨터 상에서, 독립형 소프트웨어 패키지로서, 실행될 수 있고, 부분적으로 유저의 컴퓨터 상에서 그리고 부분적으로 원격 컴퓨터 상에서 또는 전적으로 원격 컴퓨터 혹은 서버 상에서 실행될 수 있다. 후자의 시나리오에서, 원격 컴퓨터는 유저의 컴퓨터와 연결될 수 있는데, 이는 근거리 네트워크(LAN) 혹은 광역 네트워크(WAN)를 포함하는 모든 종류의 네트워크를 통해서 할 수 있거나, 또는 연결이, 예를 들어 인터넷 서비스 제공자를 사용하는 인터넷을 통해서, 외부 컴퓨터로 이루어질 수 있다. 일부 실시 예들에서, 예를 들어, 프로그램 가능 논리 회로, 필드-프로그램 가능 게이트 어레이(FPGA), 또는 프로그램 가능 논리 어레이들(PLA)을 포함하는, 전자 회로가, 본 발명의 특징들을 수행하기 위해서, 컴퓨터 판독 가능 프로그램 명령들을 수행할 수 있는데, 상기 전자회로를 맞춤형으로 구성(personalize) 하도록 컴퓨터 판독가능 프로그램 명령들의 상태 정보를 이용함으로써 할 수 있다.
본 발명의 여러 특징들이 본 발명의 실시 예들에 따른 방법들, 장치(시스템들) 및 컴퓨터 프로그램 제품들의 흐름도 예시들 및/또는 블록도들을 참조하여 기술되었다. 흐름도 예시들 및/또는 블록도들의 각 블록 및, 흐름도 예시들 및/또는 블록도들 내의 블록들의 조합들은 컴퓨터 판독가능 프로그램 명령들에 의해서 구현될 수 있음을 이해하여야 한다.
이들 컴퓨터 판독 가능 프로그램 명령들은 범용 컴퓨터, 특별 컴퓨터, 혹은 프로그램 가능 데이터 처리 장치의 프로세서에 제공되어, 컴퓨터 혹은 기타 프로그램 가능 데이터 처리 장치의 프로세서를 통해서 실행하는, 명령들이 흐름도 및/또는 블록도 블록 또는 블록들 내에 명시된 기능들/동작들을 구현하는 수단들을 생성하도록 머신을 생산할 수 있다. 이들 컴퓨터 판독 가능 프로그램 명령들은 또한 컴퓨터 판독가능 매체 내에 저장될 수 있고, 상기 명령들은 컴퓨터, 프로그램 가능 데이터 처리 장치, 및/또는 기타 디바이스들이 특정 방식으로 기능을 수행하도록 지시할 수 있으며, 따라서 컴퓨터 판독가능 스토리지 매체 내에 저장된 명령들을 갖는 컴퓨터 판독가능 스토리지 매체가 흐름도 및/또는 블록도 블록 또는 블록들 내에 명시된 기능/동작의 특징들을 구현하는 명령들을 포함하는 제품을 포함한다.
컴퓨터 판독 가능 프로그램 명령들은 또한 컴퓨터, 기타 프로그램 가능 데이터 처리 장치, 혹은 기타 디바이스들에 로드되어 컴퓨터, 기타 프로그램 가능 데이터 처리 장치, 혹은 기타 디바이스들 상에서 실행하는 명령들이 흐름도 및/또는 블록도 블록 또는 블록들 내에 명시된 기능들/동작들을 구현하도록, 컴퓨터 구현된 프로세스를 생산하기 위해서 컴퓨터, 기타 프로그램 가능 데이터 처리 장치, 혹은 기타 디바이스들 상에서 일련의 동작 단계들이 수행되게 할 수 있다.
도면들 내 흐름도 및 블록도들은 본 발명의 여러 실시 예들에 따른 시스템들, 방법들 및 컴퓨터 프로그램 제품들의 가능한 구현들의 아키텍처, 기능성, 및 연산을 예시한다. 이와 관련하여, 상기 흐름도 또는 블록도들 내 각 블록은 상기 명시된 논리 기능(들)을 구현하기 위한 하나 또는 그 이상의 실행 가능한 명령들을 포함한 모듈, 세그먼트 또는 명령들의 일부분을 나타낼 수 있다. 일부 다른 구현들에서, 상기 블록에 언급되는 기능들은 도면들에 언급된 순서와 다르게 일어날 수도 있다. 예를 들면, 연속으로 도시된 두 개의 블록들은, 실제로는, 사실상 동시에 실행될 수 있고, 또는 이 두 블록들은 때때로 관련된 기능성에 따라서는 역순으로 실행될 수도 있다. 블록도들 및/또는 흐름도 예시도의 각 블록, 및 블록도들 및/또는 흐름도 예시도 내 블록들의 조합들은 특수목적용 하드웨어 및 컴퓨터 명령들의 명시된 기능들 또는 동작들, 또는 이들의 조합들을 수행하는 특수목적용 하드웨어-기반 시스템들에 의해 구현될 수 있다는 것에 또한 유의한다.
Claims (20)
- 프로세서에 의해서 판독가능하고, 상기 프로세서가 일관성 프로토콜(a coherence protocol)을 구현하기 위한 방법을 수행하도록 하는, 구체화된 프로그램 명령들을 갖는 컴퓨터 판독 가능 저장 매체에 있어서, 상기 방법은:
상기 프로세서에 의해, 데이터에 대한 요청을 리모트 프로세서에 내보내는 단계(sending);
상기 프로세서에 의해, 상기 리모트 프로세서로부터의 응답을 수신하는 단계(receiving) ― 상기 응답은 상기 리모트 프로세서 상의 리모트 트랜잭션의 트랜잭션 상태를 포함하고, 상기 리모트 프로세서로부터의 응답에서 수신된 상기 트랜잭션 상태는 상기 프로세서 상에서 실행하는 요청 트랜잭션에 의해서 일어난 상기 리모트 프로세서에서의 간섭의 타입(a type of interference), 상기 리모트 프로세서 상에서 폐기되기 전에 상기 리모트 트랜잭션에 의해서 수행된 다수 클럭 사이클의 작업(a number of clock cycles of work), 및 상기 리모트 프로세서로 상기 요청을 내보내는 것에 의해서 상기 리모트 프로세서 상에서 롤백(a rollback)이 일어났는지에 관한 표시(indication)를 포함함 ―; 및
상기 프로세서에 의해서, 상기 리모트 프로세서 상의 상기 리모트 트랜잭션의 트랜잭션 상태를 로컬 트랜잭션 간섭 추적 테이블(a local transaction interference tracking table)에 추가하는 단계(adding) ― 상기 프로세서는 상기 리모트 프로세서와는 분리된 별도의 프로세서임 ― 를 포함하는
컴퓨터 판독 가능 저장 매체. - 제1항에 있어서, 상기 리모트 트랜잭션의 트랜잭션 상태는 트랜잭션 진단 블록(a transaction diagnostic block)에 추가되는
컴퓨터 판독 가능 저장 매체. - 제1항에 있어서, 상기 리모트 트랜잭션은 상기 리모트 프로세서 상에서 실행하고 상기 데이터에 대한 요청을 상기 리모트 프로세서에 내보내는 것에 기초하여 실행을 폐기하는
컴퓨터 판독 가능 저장 매체. - 제1항에 있어서, 상기 요청은 상기 요청을 내보내는 상기 프로세서 상에서 실행 중인 요청 트랜잭션에 의해서 이루어지는
컴퓨터 판독 가능 저장 매체. - 제1항에 있어서, 상기 리모트 트랜잭션을 상기 리모트 프로세서 상에서 폐기시키는 상기 요청 트랜잭션에 의한 상기 요청에 기초하여, 상기 프로세서는 상기 리모트 트랜잭션의 트랜잭션 상태를 상기 로컬 트랜잭션 간섭 추적 테이블에 추가하고 상기 리모트 트랜잭션에 대해서 발생한 트랜잭션 폐기들의 카운트(count)를 증가시키는(increment)
컴퓨터 판독 가능 저장 매체. - 제1항에 있어서, 상기 리모트 프로세서로부터의 응답에서 상기 프로세서에 의해서 수신된, 상기 리모트 트랜잭션의 트랜잭션 상태는 상기 리모트 트랜잭션이 상기 프로세서로부터 상기 요청을 수신하는 것에 기초하여 폐기되었음을 표시하는
컴퓨터 판독 가능 저장 매체. - 제1항에 있어서, 상기 로컬 트랜잭션 간섭 추적 테이블은 상기 프로세서 상에서 실행 중인 상기 요청 트랜잭션과 간섭을 일으켜서 상기 요청 트랜잭션에 의해서 폐기된 다수의 트랜잭션들을 유지하는
컴퓨터 판독 가능 저장 매체. - 제1항에 있어서, 상기 로컬 트랜잭션 간섭 추적 테이블은 리모트 프로세서들 상에서의 리모트 트랜잭션들을 기술하는 정보를 유지하고; 그리고
상기 리모트 프로세서들 상에서의 상기 리모트 트랜잭션들을 기술하는 상기 정보는: 상기 요청 트랜잭션에 의해서 폐기되었던 상기 리모트 트랜잭션들의 각각의 식별정보(an identification), 상기 간섭이 발생한 상기 리모트 프로세서들의 각각의 식별정보, 및 폐기된 상기 리모트 트랜잭션들의 각각의 어드레스를 더 포함하는
컴퓨터 판독 가능 저장 매체. - 일관성 프로토콜(a coherence protocol)을 구현하기 위한 컴퓨터 시스템에 있어서, 상기 시스템은: 메모리 및 상기 메모리와 통신하도록 결합된 프로세서를 포함하고, 상기 컴퓨터 시스템은 방법을 수행하도록 구성되며, 상기 방법은:
상기 프로세서에 의해, 데이터에 대한 요청을 리모트 프로세서에 내보내는 단계(sending);
상기 프로세서에 의해, 상기 리모트 프로세서로부터의 응답을 수신하는 단계(receiving) ― 상기 응답은 상기 리모트 프로세서 상의 리모트 트랜잭션의 트랜잭션 상태를 포함하고, 상기 리모트 프로세서로부터의 응답에서 수신된 상기 트랜잭션 상태는 상기 프로세서 상에서 실행하는 요청 트랜잭션에 의해서 일어난 상기 리모트 프로세서에서의 간섭의 타입(a type of interference), 상기 리모트 프로세서 상에서 폐기되기 전에 상기 리모트 트랜잭션에 의해서 수행된 다수 클럭 사이클의 작업(a number of clock cycles of work), 및 상기 리모트 프로세서로 상기 요청을 내보내는 것에 의해서 상기 리모트 프로세서 상에서 롤백(a rollback)이 일어났는지에 관한 표시(indication)을 포함함 ―; 및
상기 프로세서에 의해서, 상기 리모트 프로세서 상의 상기 리모트 트랜잭션의 트랜잭션 상태를 로컬 트랜잭션 간섭 추적 테이블(a local transaction interference tracking table)에 추가하는 단계(adding) ― 상기 프로세서는 상기 리모트 프로세서와는 분리된 별도의 프로세서임 ― 를 포함하는
컴퓨터 시스템. - 제9항에 있어서, 상기 리모트 트랜잭션의 트랜잭션 상태는 트랜잭션 진단 블록(a transaction diagnostic block)에 추가되는
컴퓨터 시스템. - 제9항에 있어서, 상기 리모트 트랜잭션은 상기 리모트 프로세서 상에서 실행하고 상기 데이터에 대한 요청을 상기 리모트 프로세서에 내보내는 단계에 기초하여 실행을 폐기하는
컴퓨터 시스템. - 제9항에 있어서, 상기 요청은 상기 요청을 내보내는 상기 프로세서 상에서 실행 중인 요청 트랜잭션에 의해서 이루어지는
컴퓨터 시스템. - 제9항에 있어서, 상기 리모트 트랜잭션을 상기 리모트 프로세서 상에서 폐기시키는 상기 요청 트랜잭션에 의한 상기 요청에 기초하여, 상기 프로세서는 리모트 트랜잭션의 트랜잭션 상태를 상기 로컬 트랜잭션 간섭 추적 테이블에 추가하고 상기 리모트 트랜잭션에 대해서 발생한 트랜잭션 폐기들의 카운트(count)를 증가시키는(increment)
컴퓨터 시스템. - 제9항에 있어서, 상기 리모트 프로세서로부터의 응답에서 상기 프로세서에 의해서 수신된, 상기 리모트 트랜잭션의 트랜잭션 상태는 상기 리모트 트랜잭션이 상기 프로세서로부터 상기 요청을 수신하는 것에 기초하여 폐기되었음을 표시하는
컴퓨터 시스템. - 제9항에 있어서, 상기 로컬 트랜잭션 간섭 추적 테이블은 상기 프로세서 상에서 실행하는 상기 요청 트랜잭션과 간섭을 일으켜서 상기 요청 트랜잭션에 의해서 폐기된 다수의 트랜잭션들을 유지하는
컴퓨터 시스템. - 일관성 프로토콜(a coherence protocol)을 구현하기 위한 컴퓨터 구현 방법에 있어서, 상기 방법은:
프로세서에 의해, 데이터에 대한 요청을 리모트 프로세서에 내보내는 단계(sending);
상기 프로세서에 의해, 상기 리모트 프로세서로부터의 응답을 수신하는 단계(receiving) ― 상기 응답은 상기 리모트 프로세서 상의 리모트 트랜잭션의 트랜잭션 상태를 포함하고, 상기 리모트 프로세서로부터의 응답에서 수신된 상기 트랜잭션 상태는 상기 프로세서 상에서 실행하는 요청 트랜잭션에 의해서 일어난 상기 리모트 프로세서에서의 간섭의 타입(a type of interference), 상기 리모트 프로세서 상에서 폐기되기 전에 상기 리모트 트랜잭션에 의해서 수행된 다수 클럭 사이클의 작업(a number of clock cycles of work), 및 상기 리모트 프로세서로 상기 요청을 내보내는 것에 의해서 상기 리모트 프로세서 상에서 롤백(a rollback)이 일어났는지에 관한 표시(indication)을 포함함 ―; 및
상기 프로세서에 의해서, 상기 리모트 프로세서 상의 상기 리모트 트랜잭션의 트랜잭션 상태를 로컬 트랜잭션 간섭 추적 테이블(a local transaction interference tracking table)에 추가하는 단계(adding) ― 상기 프로세서는 상기 리모트 프로세서와는 분리된 별도의 프로세서임 ― 를 포함하는
컴퓨터 구현 방법. - 제16항에 있어서, 상기 리모트 트랜잭션의 트랜잭션 상태는 트랜잭션 진단 블록(a transaction diagnostic block)에 추가되는
컴퓨터 구현 방법. - 제16항에 있어서, 상기 리모트 트랜잭션은 상기 리모트 프로세서 상에서 실행하고 상기 데이터에 대한 요청을 상기 리모트 프로세서에 내보내는 단계에 기초하여 실행을 폐기하는
컴퓨터 구현 방법. - 제16항에 있어서, 상기 요청은 상기 요청을 내보내는 상기 프로세서 상에서 실행하는 요청 트랜잭션에 의해서 이루어지는
컴퓨터 구현 방법. - 제16항에 있어서, 상기 리모트 트랜잭션을 상기 리모트 프로세서 상에서 폐기시키는 상기 요청 트랜잭션에 의한 상기 요청에 기초하여, 상기 프로세서는 상기 리모트 트랜잭션의 트랜잭션 상태를 상기 로컬 트랜잭션 간섭 추적 테이블에 추가하고 상기 리모트 트랜잭션에 대해 발생한 트랜잭션 폐기들의 카운트(count)를 증가시키는(increment)
컴퓨터 구현 방법.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14/212,217 US9817693B2 (en) | 2014-03-14 | 2014-03-14 | Coherence protocol augmentation to indicate transaction status |
| US14/212,217 | 2014-03-14 | ||
| PCT/EP2015/055019 WO2015135967A1 (en) | 2014-03-14 | 2015-03-11 | Coherence protocol augmentation to indicate transaction status |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20160088432A KR20160088432A (ko) | 2016-07-25 |
| KR101843671B1 true KR101843671B1 (ko) | 2018-03-29 |
Family
ID=52684217
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020167017373A KR101843671B1 (ko) | 2014-03-14 | 2015-03-11 | 트랜잭션 상태를 표시하기 위한 일관성 프로토콜 증대 |
Country Status (16)
| Country | Link |
|---|---|
| US (2) | US9817693B2 (ko) |
| EP (1) | EP3117323B1 (ko) |
| JP (1) | JP6490092B2 (ko) |
| KR (1) | KR101843671B1 (ko) |
| CN (1) | CN106133705B (ko) |
| AU (1) | AU2015228889B2 (ko) |
| BR (1) | BR112016021217B1 (ko) |
| CA (1) | CA2940915C (ko) |
| ES (1) | ES2764954T3 (ko) |
| IL (1) | IL247803B (ko) |
| MX (1) | MX2016011905A (ko) |
| RU (1) | RU2665306C2 (ko) |
| SG (1) | SG11201606098YA (ko) |
| TW (1) | TWI652574B (ko) |
| WO (1) | WO2015135967A1 (ko) |
| ZA (1) | ZA201606670B (ko) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9817693B2 (en) * | 2014-03-14 | 2017-11-14 | International Business Machines Corporation | Coherence protocol augmentation to indicate transaction status |
| US9639276B2 (en) * | 2015-03-27 | 2017-05-02 | Intel Corporation | Implied directory state updates |
| GB2539641B (en) * | 2015-06-11 | 2019-04-03 | Advanced Risc Mach Ltd | Coherency between a data processing device and interconnect |
| US20180004521A1 (en) * | 2016-07-01 | 2018-01-04 | Intel Corporation | Processors, methods, and systems to identify stores that cause remote transactional execution aborts |
| KR101946135B1 (ko) * | 2017-01-11 | 2019-02-08 | 울산과학기술원 | 비휘발성 메모리를 이용하는 데이터베이스 관리 시스템 및 방법 |
| US10521351B2 (en) | 2017-01-12 | 2019-12-31 | International Business Machines Corporation | Temporarily suppressing processing of a restrained storage operand request |
| US10621090B2 (en) * | 2017-01-12 | 2020-04-14 | International Business Machines Corporation | Facility for extending exclusive hold of a cache line in private cache |
| US20180365070A1 (en) * | 2017-06-16 | 2018-12-20 | International Business Machines Corporation | Dynamic throttling of broadcasts in a tiered multi-node symmetric multiprocessing computer system |
| US10585800B2 (en) | 2017-06-16 | 2020-03-10 | International Business Machines Corporation | Reducing cache transfer overhead in a system |
| EP3462312B1 (en) * | 2017-09-29 | 2022-08-17 | ARM Limited | Permitting unaborted processing of transaction after exception mask update instruction |
| US10996888B2 (en) * | 2017-10-31 | 2021-05-04 | Qualcomm Incorporated | Write credits management for non-volatile memory |
| US20190155985A1 (en) * | 2017-11-22 | 2019-05-23 | Mentor Graphics Corporation | Communication protocols design verification through database systems for hardware-based emulation platforms |
| CN108427576B (zh) * | 2018-02-12 | 2022-04-01 | 华夏芯（北京）通用处理器技术有限公司 | 一种免受Spectre攻击的高性能推测执行算法 |
| GB2572578B (en) * | 2018-04-04 | 2020-09-16 | Advanced Risc Mach Ltd | Cache annotations to indicate specultative side-channel condition |
| US10877895B2 (en) | 2018-08-27 | 2020-12-29 | Qualcomm Incorporated | Method, apparatus, and system for prefetching exclusive cache coherence state for store instructions |
| KR102165860B1 (ko) | 2018-12-31 | 2020-10-14 | 성균관대학교산학협력단 | 슬로티드 페이지의 더블 헤더 로깅 방법 및 데이터베이스 장치 |
| JP2020135391A (ja) | 2019-02-19 | 2020-08-31 | キオクシア株式会社 | メモリシステム |
| US11914511B2 (en) | 2020-06-22 | 2024-02-27 | Apple Inc. | Decoupling atomicity from operation size |
| CN112118296B (zh) * | 2020-08-30 | 2023-12-29 | 浪潮金融信息技术有限公司 | 一种基于mqtt协议的物联网文件传输方法 |
| US20230176956A1 (en) * | 2021-12-08 | 2023-06-08 | Hcl Technologies Limited | Method and system for performing dataload protocol operation testing in an avionics unit |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070239915A1 (en) * | 2006-03-29 | 2007-10-11 | Bratin Saha | Increasing functionality of a reader-writer lock |
| US20100169579A1 (en) * | 2008-12-30 | 2010-07-01 | Gad Sheaffer | Read and write monitoring attributes in transactional memory (tm) systems |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2727222B1 (fr) | 1994-11-21 | 1996-12-27 | Cit Alcatel | Protocole transactionnel, et systeme pour la mise en oeuvre de ce protocole |
| GB2302966A (en) | 1995-06-30 | 1997-02-05 | Ibm | Transaction processing with a reduced-kernel operating system |
| US6697935B1 (en) * | 1997-10-23 | 2004-02-24 | International Business Machines Corporation | Method and apparatus for selecting thread switch events in a multithreaded processor |
| US6567839B1 (en) * | 1997-10-23 | 2003-05-20 | International Business Machines Corporation | Thread switch control in a multithreaded processor system |
| US6081874A (en) * | 1998-09-29 | 2000-06-27 | International Business Machines Corporation | Non-uniform memory access (NUMA) data processing system that speculatively issues requests on a node interconnect |
| US6449699B2 (en) | 1999-03-29 | 2002-09-10 | International Business Machines Corporation | Apparatus and method for partitioned memory protection in cache coherent symmetric multiprocessor systems |
| US6484240B1 (en) | 1999-07-30 | 2002-11-19 | Sun Microsystems, Inc. | Mechanism for reordering transactions in computer systems with snoop-based cache consistency protocols |
| US6349361B1 (en) | 2000-03-31 | 2002-02-19 | International Business Machines Corporation | Methods and apparatus for reordering and renaming memory references in a multiprocessor computer system |
| US6990559B2 (en) | 2002-10-03 | 2006-01-24 | Hewlett-Packard Development Company, L.P. | Mechanism for resolving ambiguous invalidates in a computer system |
| US7398355B1 (en) | 2003-02-13 | 2008-07-08 | Sun Microsystems, Inc. | Avoiding locks by transactionally executing critical sections |
| US7421544B1 (en) | 2005-04-04 | 2008-09-02 | Sun Microsystems, Inc. | Facilitating concurrent non-transactional execution in a transactional memory system |
| US8924653B2 (en) * | 2006-10-31 | 2014-12-30 | Hewlett-Packard Development Company, L.P. | Transactional cache memory system |
| US7827357B2 (en) * | 2007-07-31 | 2010-11-02 | Intel Corporation | Providing an inclusive shared cache among multiple core-cache clusters |
| US8402464B2 (en) | 2008-12-01 | 2013-03-19 | Oracle America, Inc. | System and method for managing contention in transactional memory using global execution data |
| US8250331B2 (en) | 2009-06-26 | 2012-08-21 | Microsoft Corporation | Operating system virtual memory management for hardware transactional memory |
| US9569254B2 (en) * | 2009-07-28 | 2017-02-14 | International Business Machines Corporation | Automatic checkpointing and partial rollback in software transaction memory |
| US8516202B2 (en) * | 2009-11-16 | 2013-08-20 | International Business Machines Corporation | Hybrid transactional memory system (HybridTM) and method |
| US8402218B2 (en) | 2009-12-15 | 2013-03-19 | Microsoft Corporation | Efficient garbage collection and exception handling in a hardware accelerated transactional memory system |
| US20120227045A1 (en) * | 2009-12-26 | 2012-09-06 | Knauth Laura A | Method, apparatus, and system for speculative execution event counter checkpointing and restoring |
| US8719828B2 (en) * | 2011-10-14 | 2014-05-06 | Intel Corporation | Method, apparatus, and system for adaptive thread scheduling in transactional memory systems |
| US20130159653A1 (en) * | 2011-12-20 | 2013-06-20 | Martin T. Pohlack | Predictive Lock Elision |
| WO2013101078A1 (en) * | 2011-12-29 | 2013-07-04 | Intel Corporation | Support for speculative ownership without data |
| US9336046B2 (en) * | 2012-06-15 | 2016-05-10 | International Business Machines Corporation | Transaction abort processing |
| US9396115B2 (en) | 2012-08-02 | 2016-07-19 | International Business Machines Corporation | Rewind only transactions in a data processing system supporting transactional storage accesses |
| US9817693B2 (en) * | 2014-03-14 | 2017-11-14 | International Business Machines Corporation | Coherence protocol augmentation to indicate transaction status |
-
2014
- 2014-03-14 US US14/212,217 patent/US9817693B2/en active Active
- 2014-09-30 US US14/501,875 patent/US9971626B2/en active Active
-
2015
- 2015-03-11 ES ES15710158T patent/ES2764954T3/es active Active
- 2015-03-11 CN CN201580013621.6A patent/CN106133705B/zh active Active
- 2015-03-11 SG SG11201606098YA patent/SG11201606098YA/en unknown
- 2015-03-11 CA CA2940915A patent/CA2940915C/en active Active
- 2015-03-11 AU AU2015228889A patent/AU2015228889B2/en active Active
- 2015-03-11 BR BR112016021217-7A patent/BR112016021217B1/pt active IP Right Grant
- 2015-03-11 MX MX2016011905A patent/MX2016011905A/es unknown
- 2015-03-11 WO PCT/EP2015/055019 patent/WO2015135967A1/en active Application Filing
- 2015-03-11 EP EP15710158.5A patent/EP3117323B1/en active Active
- 2015-03-11 JP JP2016554864A patent/JP6490092B2/ja active Active
- 2015-03-11 KR KR1020167017373A patent/KR101843671B1/ko active IP Right Grant
- 2015-03-11 RU RU2016126977A patent/RU2665306C2/ru active
- 2015-03-13 TW TW104108221A patent/TWI652574B/zh active
-
2016
- 2016-09-13 IL IL247803A patent/IL247803B/en active IP Right Grant
- 2016-09-27 ZA ZA2016/06670A patent/ZA201606670B/en unknown
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070239915A1 (en) * | 2006-03-29 | 2007-10-11 | Bratin Saha | Increasing functionality of a reader-writer lock |
| US20100169579A1 (en) * | 2008-12-30 | 2010-07-01 | Gad Sheaffer | Read and write monitoring attributes in transactional memory (tm) systems |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3117323B1 (en) | 2019-12-04 |
| US20150261564A1 (en) | 2015-09-17 |
| WO2015135967A1 (en) | 2015-09-17 |
| US20150261676A1 (en) | 2015-09-17 |
| CA2940915A1 (en) | 2015-09-17 |
| ES2764954T3 (es) | 2020-06-05 |
| BR112016021217B1 (pt) | 2022-08-09 |
| CN106133705B (zh) | 2019-02-22 |
| KR20160088432A (ko) | 2016-07-25 |
| TW201610677A (zh) | 2016-03-16 |
| ZA201606670B (en) | 2018-05-30 |
| BR112016021217A2 (ko) | 2017-08-15 |
| AU2015228889A1 (en) | 2016-08-04 |
| RU2665306C2 (ru) | 2018-08-28 |
| EP3117323A1 (en) | 2017-01-18 |
| CN106133705A (zh) | 2016-11-16 |
| AU2015228889B2 (en) | 2018-02-01 |
| MX2016011905A (es) | 2016-12-02 |
| IL247803B (en) | 2019-03-31 |
| SG11201606098YA (en) | 2016-08-30 |
| JP6490092B2 (ja) | 2019-03-27 |
| TWI652574B (zh) | 2019-03-01 |
| JP2017514206A (ja) | 2017-06-01 |
| US9971626B2 (en) | 2018-05-15 |
| CA2940915C (en) | 2022-10-11 |
| US9817693B2 (en) | 2017-11-14 |
| RU2016126977A (ru) | 2018-04-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101843671B1 (ko) | 트랜잭션 상태를 표시하기 위한 일관성 프로토콜 증대 | |
| US10565117B2 (en) | Instruction to cancel outstanding cache prefetches | |
| US10235201B2 (en) | Dynamic releasing of cache lines | |
| US9514006B1 (en) | Transaction tracking within a microprocessor | |
| US10365927B2 (en) | Non-default instruction handling within transaction | |
| US20180067762A1 (en) | Multithreaded transactions | |
| WO2015055083A1 (en) | Adaptive process for data sharing with selection of lock elision and locking | |
| US20190236012A1 (en) | Interprocessor memory status communication | |
| US10261828B2 (en) | Interprocessor memory status communication | |
| US10120803B2 (en) | Transactional memory coherence control | |
| US9916179B2 (en) | Interprocessor memory status communication | |
| US20170123841A1 (en) | Interprocessor memory status communication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| E902 | Notification of reason for refusal | ||
| GRNT | Written decision to grant |