Transactional Memory Architectural Support for Lock-Free Data Structures

2012.11.22

성균관대학교

전자전기컴퓨터공학과

오영환 , 박효진

1. 기존의 방법론 (Lock, Lock-free 등 )

2. Transactional Memory(TM) 소개

3. Implementation of TM

4. Simulation 결과

5. Conclusion & Limitation

목차

1.1 페이지 제목

Methodology of Keeping Data Consistency

3 / 14

• Locking–공유 자원의 Consistency 를 유지하기 위해 서로 다른 프로세스의

동시 접근을 배타적으로 막는 방식 (Lock, Mutex, Semaphore 등 )

• Lock-Free Algorithm–SW 알고리즘을 이용하여 기존의 Locking 에서 발생하는 문제점을

해결하기 위해 만들어졌으나 , 오히려 알고리즘 자체의 overhead가 늘어나서 실용적으로 쓰이지 못함 .

• Transactional Memory(TM)–Lock-Free 알고리즘을 HW 적으로 Support 하여 overhead 를

낮추고 User 가 프로그램의 구현을 쉽게 하기 위해 고안됨 .

1.1 페이지 제목

Locking 의 문제점

4 / 14

• Priority inversion–낮은 우선순위의 프로세스가 Lock 을 잡고 있는 경우에 높은

우선순위의 프로세스에 의해 preempted 되는 상황

1.1 페이지 제목

Locking 의 문제점

5 / 14

• Deadlock–서로 엇갈려서 자원을 요청 , 선점하는 교착 상태

• Convoying–하나의 공유자원에 대해 다수의 프로세스가 쌓여있는 현상

1.1 페이지 제목

Lock-free Algorithm6 / 14

• Lock-Free Algorithm 이란 ?–CAS 등의 Atomic 한 Instruction 을 사용하여 Mutex 나

Semaphore 등의 Locking 을 사용하지 않고 , 공유자원의 con-sistency 를 유지 .

•대표적인 예 , CAS : Compare and Swap–주어진 메모리의 값을 읽어서 기존의 값과 Compare 하고

일치하면 , 메모리에 새로운 값을 Swap 한다 . 일치하지 않을 때는 성공할 때까지 다시 시도한다 .

Do{if( *sharedValue == knownValue )

*sharedValue = newValue;} while(!CAS (&sharedValue, knownValue, newValue));

1.1 페이지 제목

Transactional Memory7 / 14

• Transactional Memory 처리 과정–공유 데이터를 접근하는 프로세스가 하나라는 가정하에 일단 Access

함 .–TM 수행의 마지막 단계에서 다른 프로세서에 의해 공유 데이터가

바뀌었는지 확인한다 . –프로세스 간의 충돌이 없었으면 바로 메모리에 적용 (Commit) 하고 ,

충돌이 있었다면 과정을 취소한 (Abort) 뒤 , 앞서의 과정을 다시 수행(Rollback) 한다 .–공유 데이터의 충돌 빈도가 실제론 매우 적을 것이라는 아이디어 (Simulation 을 해보니 Rollback 하는 경우는 드물다고 함 . 오히려 Lock Variable 을 관리하는데 쓸데없는 overhead 가 발생한다 .)

• Transactional Memory 와 Locking 방식의 차이점• Locking : 잠금 -> 처리 -> 해제• TM : 처리 -> 비교 -> 적용 or 롤백

1.1 페이지 제목

HW Supported Instruction Set8 / 14

•제공하는 명령어–LT : memory to Cache Read–LTX : memory to Cache Read with flag setting ( 수정 예정 )–VALIDATE : 진행중인 Transaction 이 Abort 되었는지 체크–ST : LT/LTX 로 읽어들인 데이터를 수정 후 Cache 에 Write–COMMIT : Transaction 을 모두 수행한 뒤에 consistency 검사

후 TRUE 면 memory 에 write 하고 , FALSE 면 ABORT–ABORT : 진행중인 Transaction 을 무효화 ( Cache 에 flag 만

invalid 해버리면 됨 )

1.1 페이지 제목

Implementation of TM9 / 14

• Cache Protocol–Non-transactional OP 사용을 고려하여 두가지 타입의 Cache Line 을

사용함 .

• TM 캐쉬 ActionsXCOM-MIT

XABORT DATALT / LTXEMPTY NOR-

MALDATACommit

NORMAR EMPTY DATAAbortNORMAR XABORT DATAST(DIRTY)

1.1 페이지 제목

Implementation of TM : Processor Action

10 / 14

• Processor Flag bit– TACTIVE(TR in progress)– TSTATUS(TR active or aborted) bit–CPU 에서 연산 시에 Cache Protocol 과 상호작용 , Consistency 유지

• 특징적인 점 ?– Intel Haswell : HTM(Restricted), TR 영역을 대괄호로 묶어 표시– TR operation 을 위한 몇 가지 HW supported instruction 제 ( 처음 TR op 가 등장하는 구간부터 implicit 하게 TR 영역으로 )–High level 언어에 ST, LTX 등의 Assembly 명령어를 inline 으로

껴넣듯이 구현

1.1 페이지 제목

Example : doubly linked list11 / 14

Part of Doubly-Linked List Benchmark

1.1 페이지 제목

Implementation of TM : Snoopy Cache

12 / 14

•기반 기술 : Snoopy Cache (Shared memory, Bus system)–Goodman’s SCP 를 기본으로 Normal Cache 구현 , TM Cache

를 추가–TM Cache : One-way associative cache–Normal Cache : Fully associative cache( 상대적으로 작은 크기

때문 )

1.1 페이지 제목

Implementation of TM : Architec-ture

13 / 14

•생각해볼 수 있는 구체적인 Architecture:

P

Memory(L2 $)

P P

Transactional Memory 영역

Cache :

Conflicting :Memory

With Snooping!

1.1 페이지 제목 14 / 14

• Simulator–Proteus simulator(Eric Brewer, Chris Dellarocas, MIT)

• Simulated Architecture–Goodman’s Snoopy protocol with Bus-Based system–Chaiken Directory-Based protocol–Using 32 multi-processor–Compared with various SW/HW schemes– i.e. spin lock based(TTS), lock variable queing, LL/SC oper-

ation

Simulation

1.1 페이지 제목 15 / 14

Simulation

1.1 페이지 제목 16 / 14

•쉬우면서도 뛰어난 성능의 멀티 프로그래밍–다른 lock based 알고리즘에 비해 효율적인 시뮬레이션 결과 (Negative -> Positive. 관점을 변화하여 Memory Access 를 대폭 줄임 )–현재는 특정 영역을 Transaction 이라 표시만 해두는 심플함

• Transaction 의 한계 크기–Cache Size 에 영향을 받고 , 큰 Transaction 에 대해서는 오히려

성능 감소

Conclusion & Limitation

1.1 페이지 제목 17 / 14

Reference[1] 멀티코어 강의자료 , 한환수 교수님 강의자료[2] 네이버 블로그 , 백발의 개발자http://blog.naver.com/jjoommnn?Redirect=Log&logNo=130038310489

[3] 티스토리 블로그 , 김민장 . 프로그래머가 몰랐던 멀티코어 이야기 저자http://minjang.egloos.com/2907073http://minjang.egloos.com/2313699

감사합니다