소프트웨어 트랜잭션 메모리

Software transactional memory

컴퓨터 과학에서 소프트웨어 트랜잭션 메모리(STM)는 동시 컴퓨팅에서 공유 메모리에 대한 액세스를 제어하기 위한 데이터베이스 트랜잭션과 유사한 동시성 제어 메커니즘입니다.잠금 기반 동기 대신 사용할 수 있습니다.STM은 하드웨어 컴포넌트가 아닌 소프트웨어로 구현되는 전략입니다.이 컨텍스트에서의 트랜잭션은 코드 조각이 공유 메모리에 대한 일련의 읽기 및 쓰기를 실행할 때 발생합니다.이러한 읽기 및 쓰기는 논리적으로 한 순간에 발생합니다. 중간 상태는 다른 (성공한) 트랜잭션에서는 볼 수 없습니다.트랜잭션에 하드웨어 지원을 제공하는 아이디어는 1986년 Tom [1]Knight의 논문에서 시작되었습니다.그 생각은 모리스 헐리와 J. 엘리엇 B.에 의해 대중화 되었다. Moss.[2] 1995년 Nir Shavit와 Dan Touitou는 이 아이디어를 소프트웨어 전용 트랜잭션 메모리(STM)[3]로 확장했습니다.2005년 이후 STM은 집중적인[4] 연구와 실제 구현 지원에 주력하고 있습니다.

성능

대부분의 현대 멀티스레드 어플리케이션에서 사용되는 잠금테크놀로지와는 달리 STM은 매우 낙관적인 경우가 많습니다.다른 스레드의 동작에 관계없이 스레드는 공유 메모리의 변경을 완료하고 실행 중인 모든 읽기 및 쓰기를 로그에 기록합니다.진행 중인 다른 작업에 악영향을 미치지 않도록 작성자에게 책임을 지우는 대신, 전체 트랜잭션을 완료한 후 다른 스레드가 이전에 액세스한 메모리를 동시에 변경하지 않았는지 확인하는 독자에게 책임을 지웁니다.트랜잭션의 변경이 검증되고 검증이 성공했을 경우 영속적으로 이루어지는 이 최종 조작을 커밋이라고 합니다.트랜잭션은 언제든지 중단될 수 있으며, 이로 인해 이전의 모든 변경 내용이 롤백되거나 취소될 수 있습니다.변경 내용이 충돌하여 트랜잭션을 커밋할 수 없는 경우 일반적으로 트랜잭션은 처음부터 중단되고 성공할 때까지 다시 실행됩니다.

이 낙관적인 접근방식의 장점은 동시성이 향상된다는 것입니다.즉, 스레드는 리소스에 대한 접근을 기다릴 필요가 없으며, 다른 스레드는 일반적으로 동일한 잠금으로 보호되는 데이터 구조의 분리된 부분을 안전하고 동시에 수정할 수 있습니다.

그러나 실제로는 STM 시스템도 소수의 프로세서(어플리케이션에 따라 1~4)에서 세밀한 잠금 기반 시스템과 비교하여 퍼포먼스에 타격을 입습니다.이는 주로 로그 유지보수와 관련된 오버헤드와 트랜잭션 커밋에 소요된 시간에 기인합니다.이 경우에도 퍼포먼스는 보통2배 이상 [5]느려지지 않습니다.STM의 지지자들은 이 벌칙이 STM의[citation needed] 개념적인 이점에 의해 정당화된다고 믿는다.

이론적으로 n개의 동시 트랜잭션에서 최악의 경우 공간과 시간의 복잡성은 O(n)입니다.실제 요구는 구현 세부 사항에 따라 다르지만(트랜잭션이 오버헤드를 회피할 수 있을 만큼 충분히 조기에 실패할 수 있음), 잠금 기반 알고리즘이 소프트웨어 트랜잭션 메모리보다 시간이 더 복잡한 경우도 있습니다.

개념상의 장점과 단점

STM은 성능상의[citation needed] 이점 외에도 멀티스레드 프로그램의 개념적 이해를 크게 간소화하고 객체나 모듈 등의 기존 고급 추상화와 연계하여 프로그램을 보다 쉽게 유지 관리할 수 있도록 지원합니다.잠금 기반 프로그래밍에는 실제로 자주 발생하는 많은 알려진 문제가 있습니다.

  • 잠금에는 멀리 떨어져 있고 관련이 없어 보이는 코드 섹션의 중복된 조작과 부분적인 조작을 고려해야 합니다.이 작업은 매우 어렵고 오류가 발생하기 쉬운 작업입니다.
  • 잠금을 수행하려면 프로그래머가 잠금 정책을 채택하여 교착 상태, 라이브 잠금 및 기타 장애를 방지해야 합니다.이러한 정책은 종종 비공식적으로 시행되어 오류가 발생할 수 있으며, 이러한 문제가 발생했을 때 암암리에 재현 및 디버깅이 어렵습니다.
  • 잠금으로 인해 priority가 높은 스레드가 필요한 리소스에 대한 배타적 액세스를 보유하는 낮은 priority 스레드를 대기하도록 강제되는 현상인 priority 반전이 발생할 수 있습니다.

반면, 각 트랜잭션은 단일 스레드 계산으로 분리하여 볼 수 있기 때문에 메모리 트랜잭션의 개념은 훨씬 더 단순합니다.데드록과 라이브록은 완전히 방지되거나 외부 트랜잭션 관리자에 의해 처리되므로 프로그래머는 이에 대해 걱정할 필요가 없습니다.priority 반전이 문제가 될 수 있지만 priority가 높은 트랜잭션에서는 아직 커밋되지 않은 priority가 낮은 트랜잭션이 경합하는 것을 중단할 수 있습니다.

한편 실패한 트랜잭션을 중단해야 하므로 트랜잭션 동작에도 제한이 있습니다. 대부분의 I/O를 포함하여 취소할 수 없는 작업은 수행할 수 없습니다.이러한 제한은 일반적으로 되돌릴 수 없는 조작을 큐잉하여 나중에 트랜잭션 외부에서 실행하는 버퍼를 생성하여 극복됩니다.Haskell에서는 이 제한이 컴파일 시 유형 시스템에 의해 적용됩니다.

컴포지터블 조작

2005년, 팀 해리스, 사이먼 말로, 사이먼 페이튼 존스, 모리스 헐리히는 임의 원자 연산을 더 큰 원자 연산으로 구성할 수 있는 Concurrent Haskell에 구축된 STM 시스템을 설명했습니다.이것은 잠금 기반 프로그래밍에서는 불가능한 유용한 개념입니다.작성자의 말을 인용하면:

아마도 가장 근본적인 반대는 잠금 기반 프로그램이 구성되지 않는다는 것입니다. 올바른 조각이 결합되면 실패할 수 있습니다.예를 들어 스레드 세이프 삽입 및 삭제 작업이 있는 해시 테이블을 고려합니다.이제 테이블 t1에서 항목 A를 하나 삭제하고 테이블 t2에 삽입한다고 가정합니다. 단, 중간 상태(테이블에 항목이 포함되어 있지 않음)는 다른 스레드에 표시되지 않아야 합니다.해시 테이블의 구현자가 이러한 요구를 예상하지 않는 한 이 요건을 충족할 방법은 없습니다.[...] 즉, 개별적으로 올바른(삽입, 삭제) 작업은 더 큰 규모의 올바른 작업으로 구성할 수 없습니다.
- Tim Harris 등, "Composable Memory Transactions", 섹션 2: 배경, 페이지[6] 2

STM을 사용하면 이 문제를 쉽게 해결할 수 있습니다.트랜잭션에서 2개의 조작을 랩하는 것만으로 조합된 조작을 원자적으로 실행할 수 있습니다.유일한 걸림돌은 컴포넌트 메서드의 구현 세부사항을 모르는 발신자에게 트랜잭션이 실패했을 때 언제 재실행을 시도해야 하는지 불분명하다는 것입니다.이에 대해 저자들은 실패한 트랜잭션에 의해 생성된 트랜잭션 로그를 사용하여 어떤 메모리 셀을 읽었는지 결정하고, 이러한 셀 중 하나가 변경되었을 때 트랜잭션이 적어도 하나의 값이 변경될 때까지 다르게 동작하지 않는다는 논리에 기초하여 트랜잭션을 자동으로 재시도하는 재시도 명령을 제안했다.

저자들은 또한 대안 구성 메커니즘인 OrElse 함수를 제안했다.하나의 트랜잭션을 실행하고 해당 트랜잭션이 재시도하면 두 번째 트랜잭션을 실행합니다.둘 다 재시도하면 관련된 변경이 이루어지는 즉시 [clarification needed]둘 다 재시도합니다.POSIX 네트워크 선택() 콜 등의 기능에 필적하는 이 기능을 통해 발신자는 여러 이벤트 중 하나를 동시에 대기할 수 있습니다.또한 블로킹 조작과 논블로킹 조작을 변환하는 간단한 메커니즘을 제공함으로써 프로그래밍 인터페이스를 간소화합니다.

이 스킴은 글래스고 해스켈 컴파일러에 실장되어 있습니다.

언어 지원 제안

STM은 개념적으로 단순하기 때문에 비교적 단순한 언어 구문을 사용하여 프로그래머에게 노출될 수 있습니다.Tim Harris와 Keir Fraser의 "Language Support for Lightweight Transactions(Language Support for Lightweight Transactions)"는 트랜잭션을 나타내기 위해 기존의 CCR(Conditional Critical Region)을 사용하는 아이디어를 제안했습니다.가장 단순한 형태로, 이것은 논리적으로 한 순간에 발생하는 코드 블록인 "원자 블록"일 뿐입니다.

// 원자적으로 연결된 이중 목록에 노드를 삽입합니다{ newNode - > prev = node ; newNode - > next = next ; node - > next = newNode ; }

블록의 끝에 도달하면 트랜잭션이 가능한 경우 커밋되거나 중단되고 재시도됩니다.(이것은 단순한 개념적인 예이며 올바른 코드가 아닙니다.예를 들어, 트랜잭션 중에 노드가 목록에서 삭제되면 올바르게 동작하지 않습니다.)

CCR 에서는, 가드 조건도 허가됩니다.이를 통해 트랜잭션은 다음 작업을 수행할 때까지 대기할 수 있습니다.

atomic(queueSize > 0) {큐에서 항목을 제거하고 사용}

조건이 충족되지 않으면 트랜잭션 관리자는 조건에 영향을 미치는 다른 트랜잭션이 커밋될 때까지 기다렸다가 다시 시도합니다.생산자와 소비자 간의 이러한 느슨한 결합은 스레드 간의 명시적 시그널링에 비해 모듈성을 향상시킵니다."컴포터블 메모리 트랜잭션"[6]은 위에서 설명한 재시도 명령으로 이 문제를 한 단계 더 발전시켰습니다. 이 명령어는 트랜잭션을 언제든지 중단하고 트랜잭션에서 이전에 읽은 값이 변경될 때까지 기다린 후 재시도할 수 있습니다.예를 들어 다음과 같습니다.

atomic { if (queueSize > 0) { 대기열에서 항목을 제거하고 사용 } 그렇지 않으면 {retry} } }

트랜잭션 후반에 동적으로 재시도할 수 있는 이 기능은 프로그래밍 모델을 단순화하고 새로운 가능성을 열어줍니다.

한 가지 문제는 예외가 트랜잭션 외부로 전파될 때의 동작 방식입니다."Composable Memory Transactions"[6]에서는 예외는 일반적으로 Concurrent Haskell에서 예기치 않은 오류를 나타내기 때문에 트랜잭션을 중단해야 하지만 예외는 트랜잭션 중에 할당되고 읽히는 정보를 진단 목적으로 유지할 수 있다고 판단했습니다.이들은 다른 환경에서 다른 설계 결정이 합리적일 수 있다고 강조합니다.

트랜잭션 잠금

STM은 록프리 알고리즘으로 실장할 수도 있고 잠금을 사용할 수도 있습니다.잠금 방식에는 두 가지 유형이 있습니다.조우 시 잠금(Ennals, Saha 및 Harris)에서는 메모리 쓰기는 우선 특정 장소에 대한 잠금을 일시적으로 취득하고 값을 직접 기입하여 실행 취소 로그에 기록함으로써 이루어집니다.commit-time locking은 커밋 단계 중에만 메모리 위치를 잠급니다.

Dice, Shalev 및 Shavit에 의해 구현된 "Transactional Locking II"라는 이름의 커밋 타임 스킴은 글로벌버전 클럭을 사용합니다.모든 트랜잭션은 클럭의 현재 값을 읽고 읽기 버전으로 저장함으로써 시작됩니다.그런 다음 읽기 또는 쓰기 때마다 특정 메모리 위치의 버전을 읽기 버전과 비교하고, 더 크면 트랜잭션이 중단됩니다.이것에 의해, 일관된 메모리의 스냅샷으로 코드가 실행되게 됩니다.커밋하는 동안 모든 쓰기 위치가 잠기고 모든 읽기 및 쓰기 위치의 버전 번호가 다시 확인됩니다.마지막으로 글로벌 버전 클럭이 증가하고 로그의 새로운 쓰기 값이 메모리에 다시 쓰여지며 새로운 클럭 버전이 스탬프됩니다.

트랜잭션 메모리, 특히 STM에서 트랜잭션 경합을 관리하기 위해 점점 더 많이 사용되는 방법은 커밋 순서(Commit Ordering; CO라고도 함)입니다.이는 "commit order"(라마단 등)에 의해 (즉, 충돌 시 차단하지 않고, 커밋을 위해 잠그는 것만으로) 낙관적으로 시리얼라이제빌리티를[2] 달성하는 데 활용됩니다.2009년,[7] 장 외 2006년[8]).시리얼라이제빌리티는 (동시 트랜잭션과) 트랜잭션메모리의 정확성의 기초가 됩니다."commit order"에 관한 수십 개의 STM 기사가 이미 발표되었으며, 이 기술은 다수의 특허로 인해 어려움을 겪고 있습니다.

CO에 의해 원하는 연속성 속성은 각 거래의 우선순위(경합에서 연산의 시간순으로 결정됨)와 호환되는 시간순으로만 거래를 커밋함으로써 달성된다.CO를 강제하기 위해서는 Generic local CO 알고리즘의 구현이 필요합니다.위에서 인용한 특허 요약은 미리 정해진 커밋 순서를 가진 알고리즘의 일반적인 구현을 기술하고 있다(이는 "실시간 제약이 있는 CO 범용 알고리즘"의 범주에 속한다).

구현 문제

소프트웨어 트랜잭션메모리를 낙관적으로 읽을 때의 문제 중 하나는 불완전한 트랜잭션이 일관성 없는 상태를 읽을 수 있다는 것입니다(즉, 다른 트랜잭션에 의해 쓰여진 오래된 값과 새로운 값의 혼합을 읽을 수 있다는 것입니다).이러한 트랜잭션은 커밋을 시도하면 중단될 수밖에 없기 때문에 트랜잭션시스템에 의해 강제되는 일관성 조건을 위반하는 것은 아닙니다만, 이 「일시적인」불일치 상태가, f와 같이 트랜잭션이 중대한 예외 조건을 트리거 하거나, 무한 루프에 들어갈 가능성이 있습니다.「Lightweight Transactions Language Support for Lightweight Transactions」의 그림 4에서 작성한 예:

atomic { if (x != y) while (true) { } }
 
원자 { x++; y++; }
트랜잭션 A
트랜잭션 B

처음에 x=y일 경우 위의 어느 트랜잭션도 이 불변성을 변경하지 않지만 트랜잭션 A가 트랜잭션 B가 업데이트한 후에는 x를 읽지만 트랜잭션 B가 업데이트하기 전에는 y를 읽어서 무한 루프로 진입할 수 있습니다.이 문제를 해결하기 위한 일반적인 전략은 치명적인 예외를 가로채고 유효하지 않은 트랜잭션을 중단하는 것입니다.

이러한 문제에 대처하는 방법 중 하나는 부정 조작을 실행하거나 트랜잭션을 완전히 종료 및 중단하지 못한 트랜잭션을 검출하는 것입니다.또 다른 방법은 트랜잭션 잠금 방식입니다.

실장

다수의 STM 실장(품질과 안정성의 다양한 척도로)이 공개되어 있으며, 많은 실장은 자유 라이선스로 실시되고 있습니다.여기에는 다음이 포함됩니다.

C/C++

  • TinySTM, 단어 기반 STM.
  • Lightweight Transaction Library (LibLTX)는 효율성에 중점을 두고 있으며 그의 논문 "Software Transaction Memory Should Not Be Free" 및 "Cache Sensitive Software Transaction Memory"에 기초한 Robert Ennals의 C 구현입니다.
  • LibCMT는 Duilio Protti가 "컴포지블 메모리 트랜잭션"[6]에 기반한 C의 오픈 소스 구현입니다.구현에는 C# 바인딩도 포함되어 있습니다.
  • TARIFA는 컴파일러의 어셈블러 출력을 계측함으로써 "atomic" 키워드를 C/C++로 가져오는 프로토타입입니다.
  • 인텔 STM 컴파일러 프로토타입 에디션은 인텔 또는 AMD 프로세서용 32비트 또는 64비트 코드를 생성하는 Linux 또는 Windows용 컴파일러에 직접 STM for C/C++를 구현합니다.atomic 키워드를 실장해, atomic 섹션에서의 사용을 제어/허가하기 위한 함수 정의를 장식(decspec)하는 방법을 제공합니다.임의의 크기의 C/C++ 프로그램에서 대규모 실험을 가능하게 하는 목적을 가진 컴파일러의 실질적인 구현입니다.인텔은 이 특별한 시험판 제품 컴파일러의 4가지 연구 발표를 했습니다.
  • stmmap 공유 메모리 매핑에 기반한 C에서의 STM 구현.트랜잭션 의미론을 사용하여 스레드 및/또는 프로세스 간(프로세스 내 스레드 간뿐만 아니라) 메모리를 공유하기 위한 것입니다.메모리 할당기의 멀티 스레드 버전은 C++입니다.
  • CTL C에서의 STM 실장.TL2에 근거하고 있지만, 다수의 확장과 최적화를 수반합니다.
  • Sun Microsystems 연구소의 Scalable Synchronization 연구 그룹의 TL2 잠금 기반 STM은 DISC 2006 기사 "Transactional Locking II"에 기재되어 있습니다.
  • Tim Harris & Keir Fraser의 몇 가지 구현은 그의 논문 "Language Support for Lightweight Transactions", "Practical Lock Freedom" 및 곧 발표될 미발표 작품에 기초한 것입니다.
  • RSTM Michael L. Scott가 이끄는 연구팀에 의해 작성된 로체스터 대학 STM.
  • GCC 4.7은 이제 컴파일러에서 직접 C/C++용 STM을 지원합니다.이 기능은 여전히 "실험적"으로 표시되어 있지만 테스트에 필요한 기능을 제공할 수 있습니다.
  • STM은 C의[9] Picotm 트랜잭션 프레임워크의 일부입니다.

C#

  • 쉴드: 에 대해 엄격하고 대부분 장애물이 없는 STM.NET, C#로 기재되어 있습니다.기능에는 조건부 트랜잭션, 변환 가능한(경합이 적은) 작업, 트랜잭션 수집 유형 및 POC 오브젝트 트랜잭션프록시 서브클래스의 자동 생성 등이 있습니다.
  • STMNet 순수 C#, 오픈소스 경량 소프트웨어 트랜잭션 메모리 API.
  • SXM, Microsoft Research에 의한 C# 트랜잭션 구현.문서, 다운로드 페이지 단종.
  • LibCMT는 Duilio Protti가 "컴포지블 메모리 트랜잭션"[6]에 기반한 C의 오픈 소스 구현입니다.구현에는 C# 바인딩도 포함되어 있습니다.
  • NSTM, .NET Software Transactional Memory는 완전히 C#으로 작성되어 완전히 중첩된 트랜잭션을 제공하며 시스템과의 통합도 가능합니다.트랜잭션입니다.
  • MikroKosmos C#에서의 STM 검증 지향 모델 구현.
  • Object Fabric cf.Java의 실장
  • Sasa.TM 소프트웨어 트랜잭션 메모리의 순수 C# 구현.

클로쥬르

  • Clojure는 핵심 언어에 STM 지원을 내장하고 있습니다.

일반적인 리스프

  • CL-STM: Common Lisp용 멀티플랫폼 STM 실장.
  • STMX Common Lisp용 소프트웨어, 하드웨어 및 하이브리드 메모리 트랜잭션을 제공하는 액티브하게 유지 보수된 오픈 소스 동시성 라이브러리.

얼랑

  • Mnesia STM 역할을 수행하는 Erlang/OTP에 내장된 분산형 트랜잭션 인메모리 DBMS. 아마도 야생에서 가장 오래된 STM 구현일 것입니다.

F#

  • F#은 [1] FSharpX - [2] F#에서 샘플로 사용

그루비

  • GPARS - Gpars 프레임워크에는 Java Multiverse 구현을 활용한STM 지원이 포함되어 있습니다.

하스켈

자바

  • SCAT 연구 그룹의 AtomJava 구현.
  • JVSTM은 소프트웨어 엔지니어링 그룹(INESC-ID)의 멤버인 Joang Cachopo와 Antonio Rito Silva가 제안한 Versioned Box 개념을 구현하고 있습니다.버전 2.0 이후 JVSTM은 완전히 잠기지 않게 되었습니다.
  • 듀스 바이트 코드 조작을 사용한 Java 소프트웨어 트랜잭션 메모리의 런타임 환경.
  • 멀티버스는 동시성 제어 메커니즘으로 Multi Version Concurrency Control(MVCC)을 사용하는 Java 1.6+ 기반의 Software Transactional Memory(STM) 구현입니다.
  • DSTM2 Sun Lab의 다이내믹 소프트웨어 트랜잭션 메모리 라이브러리
  • Object Fabric은 Java 및 를 위한 오픈소스 구현입니다.NET. 확장 메커니즘을 통해 분산 STM으로 변환할 수 있습니다.다른 확장 기능에서는 로깅, 변경 알림 및 지속성을 사용할 수 있습니다.
  • ScalaSTM - 실행 가능 개체 및 호출 가능 개체와 함께 사용할 수 있도록 Java에 초점을 맞춘 API를 추가로 제공하는 Scala로 작성된 라이브러리 기반 STM.

자바스크립트

  • Atomize JS는 단일 노드를 사용하여 웹 브라우저에 분산 소프트웨어 트랜잭션 메모리를 구현합니다.트랜잭션의 효과를 검증하기 위한 JS 서버.

OCaml

  • coThreads는 OCaml의 동시 프로그래밍 라이브러리이며 모듈로서 STM(원래 STMLib)을 제공합니다.이 라이브러리의 다른 컴포넌트와 마찬가지로 STM 모듈은 VM 수준의 스레드, 시스템 스레드 및 프로세스에서 균일하게 사용할 수 있습니다.

펄

파이썬

  • 원자 잠금 장치가 있는 CPython의 포크 - Armin Rigo는 Pypy-dev 목록에 이메일로 CPython에 대한 패치를 설명합니다.
  • Armin Rigo에서 PyPy를 위한 스레드 포함 PyPy STM 발표.
  • Popovic, Miroslav; Kordic, Branislav (2014). "PSTM: Python software transactional memory". 2014 22nd Telecommunications Forum Telfor (TELFOR). pp. 1106–1109. doi:10.1109/TELFOR.2014.7034600. ISBN 978-1-4799-6191-7.
  • Kordic, Branislav; Popovic, Miroslav; Basicevic, Ilija (2015). "DPM-PSTM: Dual-Port Memory Based Python Software Transactional Memory". 2015 4th Eastern European Regional Conference on the Engineering of Computer Based Systems. pp. 126–129. doi:10.1109/ECBS-EERC.2015.28. ISBN 978-1-4673-7967-0.

루비

  • MagLev는 GemStone/S 가상 머신 위에 구축된 Ruby 인터프리터의 구현입니다.
  • Concurrent Ruby는 STM을 포함한 Ruby용 동시 기능을 제공하는 라이브러리입니다.
  • Ractor:TVar는 Ruby 3.0 위의 Ractor와 스레드 구현입니다.

스칼라

  • ScalaSTM – Scala 표준 라이브러리에 포함된 제안서 초안 및 참조 구현 CCSTM[10]
  • Akka STM – Akka 프레임워크는 Scala와 Java 모두에서 STM을 지원합니다.
  • MUTS – Manchester University Transactions for Scala[11]
  • ZIO – Haskell의 STM API에서 영감을 얻어 ZIO로 구현합니다.
  • Cats STM – Haskell의 stm 패키지와 유사한 소프트웨어 트랜잭션 메모리 구현으로 Cats Effect의 확장입니다.

스몰토크

  • GemStone/S [ 3 ]Smalltalk용 트랜잭션메모리 오브젝트 서버
  • 오픈소스 Smalltalk(MIT 라이선스) Pharo용 STM

기타 언어

레퍼런스

  1. ^ 톰 나이트.대부분 기능하는 언어를 위한 아키텍처.LISP 및 기능 프로그래밍에 관한 1986년 ACM 회의의 진행.
  2. ^ a b 모리스 헐리와 J. 엘리엇 B.Moss. 트랜잭션 메모리: 잠금 없는 데이터 구조를 위한 아키텍처 지원.제20회 컴퓨터 아키텍처 국제 심포지엄(ISCA '93)의 진행.제21권 제2호 1993년 5월
  3. ^ 니르 샤빗과 댄 투이투.소프트웨어 트랜잭션메모리분산 컴퓨팅제10권, 제2권1997년 2월
  4. ^ ""software transactional memory" - Google Scholar". Retrieved 10 November 2013.
  5. ^ Simon Peyton-Jones. "Programming in the Age of Concurrency: Software Transactional Memory". Channel 9. Retrieved 2007-06-09.
  6. ^ a b c d e Harris, T.; Marlow, S.; Peyton-Jones, S.; Herlihy, M. (2005). "Composable memory transactions" (PDF). Proceedings of the tenth ACM SIGPLAN symposium on Principles and practice of parallel programming - PPoPP '05. p. 48. doi:10.1145/1065944.1065952. ISBN 1595930809.
  7. ^ Hany E. 라마단, Indrajit Roy, Maurice Herlihy, Emett Witchel (2009) :제14회 병렬 프로그래밍 원칙과 실천에 관한 ACM SIGPLAN 심포지엄(PPOPP '09', ISBN 978-1-60558-397-6) 진행
  8. ^ 링리 장, 비노드 KGrover, Michael M. Magruder, David Detlefs, John Joseph Duffy, Goetz Graefe (2006) :소프트웨어 트랜잭션 커밋 순서 및 충돌 관리 미국 특허 7711678, 2010년 05월 04일 부여.
  9. ^ "picotm - Portable Integrated Customizable and Open Transaction Manager".
  10. ^ N.G. 브론슨, H. 차피, K.Olukotun, CCSTM: Scala용 라이브러리 기반 STM.2010 Scala Days 워크숍(로잔)의 진행.
  11. ^ D. Goodman, B. Khan, S. Kirkham, M. Lujann 및 Ian Watson, MUTS, Native Scala Constructions for Software Transactional Memory.2011 Scala Days 워크숍 진행(Stanford).

외부 링크