소프트웨어 트랜잭션 메모리를 사용한 실제 경험?

Question

최근에 STM (소프트웨어 트랜잭션 메모리) 프레임 워크 및 언어 확장에 대한 관심이 증가한 것으로 보입니다. 특히 Clojure은 롤링 커밋 로그가 아닌 MVCC (multi-version concurrency control)을 사용하는 우수한 구현을 가지고 있습니다. GHC Haskell은 또한 거래 구성을 허용하는 an extremely elegant STM monad을 보유하고 있습니다. 마지막으로, 혼자만의 경적을 울리기 위해 최근 참조 제한을 정적으로 적용하는 STM framework for Scala을 구현했습니다.

이 모든 것들은 흥미로운 실험이지만, 그것만이 그 구체에만 국한되어있는 것처럼 보입니다 (실험). 그래서 제 질문은 : 실제 세계에서 STM을 보았거나 사용 했나요? 그렇다면 왜? 어떤 종류의 이익을 가져 왔습니까? 실적은 어떻습니까? (이 점에 대해 많은 상충되는 정보가있는 것 같습니다.) STM을 다시 사용 하시겠습니까? 아니면 배우와 같은 다른 동시성 추상화를 사용 하시겠습니까?

Answer 1

하스켈에서 BitTorrent 클라이언트의 애호가 개발에 참여했습니다 (이름이 지어 짐). STM을 사용하여 서로 다른 스레드를 조정합니다 (피어 당 1 개 + 저장소 관리 + 1 개 전체 관리).

장점 : 잠금 장치, 읽을 수있는 코드가 적습니다.

속도는 문제가되지 않았습니다. 적어도 STM 사용으로 인한 문제는 아닙니다.

희망이

Answer 2

기사 도움 "소프트웨어 트랜잭션 메모리 : 왜만을 연구 장난감을입니다" 하스켈 구현을 보지 못했는데, 이것은 정말 큰 누락입니다. 기사에서 지적한 바와 같이 STM의 문제점은 컴파일러가 안전하다는 것을 증명할 수 없거나 성능을 떨어 뜨리는 프로그래머가 아니라면 어떤 변수가 트랜잭션이되어야 하는지를 명시하지 않는 한 모든 변수 액세스를 트랜잭션으로 만드는 것 사이에서 구현을 선택해야한다는 것입니다. 신뢰성). 그러나 Haskell 구현은 Haskell의 순도를 사용하여 대부분의 변수 사용을 트랜잭션 적으로 만드는 필요성을 피하는 반면 타입 시스템은 트랜잭션 변경 작업에 대한 효과적인 적용과 함께 간단한 모델을 제공합니다. 따라서 Haskell 프로그램은 비 트랜잭션 메모리 사용을 안전하게 유지하면서 스레드간에 진정으로 공유되는 변수에 대해 STM을 사용할 수 있습니다.

Answer 3

우리는 Galois (하스켈)의 높은 동시성 응용 프로그램에 대해 규칙적으로 사용합니다. 그것은 작동하며 Haskell 세계에서 광범위하게 사용되며 교착 상태가되지 않습니다 (물론 너무 많은 경합이있을 수 있습니다). 때때로 우리는 디자인 권리가 있다면 MVars를 사용하도록 다시 작성합니다.

그냥 사용하십시오. 별거 아니야. 내가 아는 한 하스켈에 소재한 STM은 "해결되었습니다". 더 이상 할 일이 없습니다. 그래서 우리는 그것을 사용합니다.

Answer 4

저는 현재 일부 PGAS 시스템 연구에서 Akka를 사용하고 있습니다. Akka은 Erlang의 "Let It Fail/Crash/Crater/ROFL"철학을 모델로 한 액터, STM 및 내장 된 내결함성 기능을 사용하여 확장 가능한 동시 시스템을 개발하기위한 스칼라 라이브러리입니다. Akka의 STM 구현은 Clojure의 STM 구현 스칼라 포트를 기반으로 구현됩니다. Akka의 STM 모듈에 대한 개요는 here입니다.

Answer 5

We, factis research GmbH은 생산시 GHC가있는 Haskell STM을 사용하고 있습니다. 우리 서버는 clincal "데이터 서버"에서 새롭고 수정 된 "객체"에 대한 메시지 스트림을 수신하고,이 이벤트 스트림을 즉각적으로 변환하고 (새 객체 생성, 객체 수정, 객체 집계 등) 개체가 연결된 iPad로 동기화되어야합니다. 또한 처리 된 iPad의 양식 입력을 수신하고 "메인 스트림"과 병합되며 다른 iPads와 동기화됩니다. 우리는 스레드간에 공유되어야하는 모든 채널과 변경 가능한 데이터 구조에 STM을 사용하고 있습니다.쓰레드는 Haskell에서 매우 가볍기 때문에 퍼포먼스에 영향을주지 않으면 서 스레드를 많이 가질 수 있습니다 (iPad 연결 당 순간 5). 대규모 응용 프로그램을 작성하는 것은 항상 어려운 일이며 많은 교훈을 얻을 수 있지만 STM에는 전혀 문제가 없었습니다. 당신이 순진하게 기대했던 것처럼 항상 효과가있었습니다. 심각한 성능 튜닝을해야했지만 STM은 결코 문제가되지 않았습니다. (단정 한 할당과 전반적인 메모리 사용을 줄이기 위해 노력한 시간의 80 %)

STM은 하스켈과 GHC 런타임이 실제로 빛나는 곳 중 하나입니다. 그것은 단지 장난감 프로그램을위한 것이 아니며 실험이 아닙니다.

우리는 스칼라에 clincal 시스템의 다른 구성 요소를 구축하고 있으며 지금까지는 액터를 사용해 왔지만 실제로 STM이 누락되었습니다. 스칼라 STM 구현 중 하나를 프로덕션에서 사용하는 것과 같은 경험이있는 사람이라면 누구든지 여러분의 의견을 듣고 싶습니다. :-)

Answer 6

우리는 system (메모리 내 데이터베이스와 런타임)을 C의 STM 구현 위에 구현했습니다. 이전에는 동시성을 처리 할 수있는 몇 가지 로그 및 잠금 기반 메커니즘이 있었지만이 유지하는 고통이었다. 모든 작업을 동일한 방식으로 처리 할 수 ​​있으므로 STM에 매우 만족합니다. 거의 모든 자물쇠를 제거 할 수 있습니다. 어떤 크기의 것이라도 거의 모든 것을 STM으로 사용할 수 있으며, 메모리 관리자를 구현할 수도 있습니다.

성능은 좋지만 속도를 높이기 위해 ETH Zurich와의 공동 작업으로 맞춤형 operating system을 개발했습니다. 이 시스템은 기본적으로 트랜잭션 메모리를 지원합니다.

그러나 STM으로 인한 몇 가지 문제가 있습니다. 특히 불필요한 트랜잭션 충돌을 일으키는 대규모 트랜잭션 및 핫 스폿의 경우. 예를 들어 두 트랜잭션이 항목을 연결된 목록에 넣으면 잠금없는 데이터 구조를 사용하여 피할 수있는 불필요한 충돌이 발생합니다.