소프트웨어 트랜잭션 메모리를 사용한 실제 경험이 있습니까?
최근 STM (소프트웨어 트랜잭션 메모리) 프레임 워크 및 언어 확장에 대한 관심이 높아지고있는 것 같습니다. 특히 Clojure 는 롤링 커밋 로그가 아닌 MVCC (다중 버전 동시성 제어) 를 사용하는 뛰어난 구현을 가지고 있습니다. GHC Haskell에는 트랜잭션 구성을 허용 하는 매우 우아한 STM 모나드 도 있습니다. 마지막으로, 내 자신의 경적을 조금만 울리기 위해 최근에 참조 제한을 정적으로 적용하는 Scala 용 STM 프레임 워크를 구현했습니다 .
이 모든 것들은 흥미로운 실험이지만 그 영역에만 국한된 것 같습니다 (실험). 그래서 제 질문은 : 실세계에서 STM을 보거나 사용한 사람이 있습니까? 그렇다면 그 이유는 무엇입니까? 어떤 이점이 있었습니까? 성능은 어떻습니까? (이 점에 대해 많은 상충되는 정보가있는 것 같습니다.) STM을 다시 사용 하시겠습니까, 아니면 행위자와 같은 다른 동시성 추상화를 사용 하시겠습니까?
저는 Haskell (conjure)에서 BitTorrent 클라이언트의 취미 개발에 참여했습니다. 다양한 스레드를 조정하기 위해 STM을 상당히 많이 사용합니다 (피어 당 1 개 + 스토리지 관리 용 1 개 + 전체 관리 용 1 개).
이점 : 잠금이 적고 코드를 읽을 수 있습니다.
속도는 적어도 STM 사용으로 인한 문제가 아니 었습니다.
도움이 되었기를 바랍니다
Galois (Haskell에서)의 높은 동시성 앱에 대해 꽤 일상적으로 사용합니다. 그것은 작동하고 Haskell 세계에서 널리 사용되며 교착 상태가 아닙니다 (물론 너무 많은 경합을 가질 수 있습니다). 때때로 우리는 디자인이 옳다면 MVar를 사용하기 위해 재 작성합니다.
그냥 사용하세요. 별거 아니야. 내가 아는 한 Haskell의 STM은 "해결"되었습니다. 더 이상 할 일이 없습니다. 그래서 우리는 그것을 사용합니다.
" 소프트웨어 트랜잭션 메모리 : 왜 연구용 장난감 일 뿐입니 까? " 기사 (Călin Caşcaval et al., Communications of the ACM, 2008 년 11 월), Haskell 구현을 보지 못하는 것은 정말 큰 누락입니다. 기사에서 지적했듯이 STM의 문제는 컴파일러가 성능을 저하시키는 컴파일러가 안전하다고 증명할 수없는 경우 모든 변수 액세스를 트랜잭션 방식으로 만들거나 프로그래머가 트랜잭션을 표시하도록하는 것 (단순성을 없애는 방식) 중에서 선택해야한다는 것입니다. 및 신뢰성). 그러나 Haskell 구현은 대부분의 가변 사용을 트랜잭션으로 만들 필요가 없도록 Haskell의 순수성을 사용하는 반면, 유형 시스템은 트랜잭션 변형 작업에 대한 효과적인 시행과 함께 간단한 모델을 제공합니다. 따라서 Haskell 프로그램은 스레드간에 공유되는 변수에 대해 STM을 사용할 수 있으며 비 트랜잭션 메모리 사용이 안전하게 유지되도록 보장합니다.
우리 factis Research GmbH, 프로덕션에서 GHC와 함께 Haskell STM을 사용하고 있습니다. 우리 서버는 클린 컬 "데이터 서버"로부터 새롭고 수정 된 "객체"에 대한 메시지 스트림을 수신하고,이 이벤트 스트림을 즉석에서 변환하고 (새 객체 생성, 객체 수정, 사물 집계 등) 이러한 새로운 객체를 계산합니다. 개체는 연결된 iPad에 동기화되어야합니다. 또한 처리되고 "메인 스트림"과 병합되고 다른 iPad와 동기화되는 iPad에서 양식 입력을 수신합니다. 스레드간에 공유해야하는 모든 채널과 변경 가능한 데이터 구조에 STM을 사용하고 있습니다. 스레드는 Haskell에서 매우 가볍기 때문에 성능에 영향을주지 않고 많은 스레드를 가질 수 있습니다 (현재 iPad 연결 당 5 개). 대규모 애플리케이션을 구축하는 것은 항상 어려운 일이며 배워야 할 교훈이 많았지 만 STM에는 문제가 없었습니다. 순진하게 예상했던대로 항상 작동했습니다. 심각한 성능 조정을해야했지만 STM은 문제가되지 않았습니다. (단기간 할당 및 전체 메모리 사용량을 줄이려고 시도한 시간의 80 %)
STM은 Haskell과 GHC 런타임이 실제로 빛나는 영역 중 하나입니다. 그것은 단순한 실험이 아니며 장난감 프로그램만을위한 것이 아닙니다.
우리는 Scala에서 임상 시스템의 다른 구성 요소를 구축하고 있으며 지금까지 액터를 사용해 왔지만 실제로 STM이 누락되었습니다. 프로덕션에서 Scala STM 구현 중 하나를 사용하는 것이 어떤 것인지 경험이 있다면 여러분의 의견을 듣고 싶습니다. :-)
우리는 C로 자체 STM 구현을 기반으로 전체 시스템 (인 메모리 데이터베이스 및 런타임)을 구현했습니다. 그 전에는 동시성을 처리하기위한 로그 및 잠금 기반 메커니즘이 있었지만 유지 관리가 어려웠습니다. 모든 작업을 동일한 방식으로 처리 할 수 있기 때문에 STM에 매우 만족합니다. 거의 모든 잠금을 제거 할 수 있습니다. 우리는 현재 거의 모든 크기에 STM을 사용하고 있으며 메모리 관리자 구현도 있습니다.
성능은 좋지만 속도를 높이기 위해 이제 ETH Zurich와 협력 하여 맞춤형 운영 체제 를 개발했습니다 . 시스템은 기본적으로 트랜잭션 메모리를 지원합니다.
그러나 STM으로 인해 발생하는 몇 가지 문제도 있습니다. 특히 불필요한 트랜잭션 충돌을 유발하는 더 큰 트랜잭션 및 핫스팟에서. 예를 들어 두 개의 트랜잭션이 항목을 연결 목록에 넣으면 잠금없는 데이터 구조를 사용하여 피할 수있는 불필요한 충돌이 발생합니다.
저는 현재 일부 PGAS 시스템 연구에서 Akka를 사용하고 있습니다. Akka 는 Erlang의 "Let It Fail / Crash / Crater / ROFL"철학을 모델로 한 액터, STM 및 내장 된 내결함성 기능을 사용하여 확장 가능한 동시 시스템을 개발하기위한 Scala 라이브러리입니다. Akka의 STM 구현은 Clojure의 STM 구현의 Scala 포트를 중심으로 구축 된 것으로 보입니다. Akka의 STM 모듈에 대한 개요는 여기 에서 찾을 수 있습니다 .
'Program Club' 카테고리의 다른 글
| 'return await promise'와 'return promise'의 차이점 (0) | 2020.12.04 |
|---|---|
| URL에서 뒤로 버튼 / 해시 변경 감지 (0) | 2020.12.04 |
| null 포인터와 void 포인터의 차이점은 무엇입니까? (0) | 2020.12.03 |
| T-SQL을 사용하여 datetime의 시간을 얻습니까? (0) | 2020.12.03 |
| mysql 날짜 시간 비교 (0) | 2020.12.03 |