Donald E. Porter, Owen S. Hofmann, Christopher J. Rossbach, Alexander Benn, and Emmett Witchel SOSP’09
개요
시스템 콜을 Transaction하게 만든 디자인을 제시한 논문이다.
Motivation
Applications developer들은 논리적으로 연관된 여러개의 시스템콜을 사용한다. 이러한 Complexity는 buggy하거나 malicious한 어플리케이션에서 Critical한 Attack point혹은 Data lose로 이어질 수 있다. 예를 들어서, Software install과정에서 Fault가 나면, 소프트웨어전체 state가 박살날수 있다. Application transaction은 Security적으로도 의미가 있다. 예를 들어서, TOCTOU와 같은 Race condition은 Application의 state가 첫번째 시스템콜 사용시와, 나중 시스템콜 사용시에 달라지는 것을 사용하는 것으로, 만약 System call들의 Atomicity를 보장한다면 TOCTOU과 같은 Race condition을 이용하는 버그를 사전에 차단 가능하다.
Importance
Operating system은 Atomicity를 위해서 race condition을 삭제하거나 fsync와 같은 시스템콜을 제공한다. 그러나, 각각의 시스템콜의 Atomicity를 보장하는 경우는 많아도, 전체 시스템콜의 Atomicity를 보장하는 법은 없다.
Main Ideas
- ACID를 보장하는 시스템을 위해서는 다음과 같은 것들을 보장해야 한다.
- Atomicity, Consistency, Isolation, and Durability
- Atomicity and Consistency: Serializable, Recoverable, Repeatable
- Isolation: 동시에 Writer는 하나만 존재해야 함
- Durability: 프로그래머가 Durable할지 말지 결정할 수 있음 (e.g., TOCTOU를 없어는 것은 Durability없어도 가능)
- Non-transactional thread와 Transactional thread간의 상호작용이 있을 경우, Serialize가 되어야 함; Strong isolation이라 부르며 제일 강력한 Serialize보장임
- Transaction이 livelock을 다른 시스템의 Transaction과 존재해서는 안됌
- Operating system의 state뿐만 아니라 Application의 state도 Transaction하게 구현해야 함. TxOS에서는 Single thread일 경우 COW를 이용해서 간단히 구현할 수 있는 API를 제공하나, 그 의외의 상황은 프로그래머가 처리해야 함.
- 만약 다른 Non-transactional thread와 Communication이 있으면, Transaction을 보장할 수 없음. 이는 프로그래머가 처리해야 함.
- TxOS Overview
- Read와 Write에 대한 접근이 분리된 memory buffer에서만 일어나고, 나중에 commit point에서 commit될때 한번에 반영하도록 하였다. TxOS는 object-based software transactional memory system이라는 Transactional기법을 사용하였으며, 이를 위해서 logging과 two-phase locking을 반영하였다. TxOS는 optimistic한 Transaction이며, conflicts이 드물다(rare)하다는 가정하에 디자인되었다. txOS는
sys_xbegin()와sys_xend()사이에 존재하는 selective한 150개 정도의 시스템콜이 transaction하다는 것을 보장하였다. 굳이 보장할 필요가 없는 시스템콜은(e.g., reboot, mount, mremap, mprotect ... etc) Future work으로 남겨두었다.
Challenges
Design
- Interoperability and fairness: 만약 transactional 그리고 non-transaction thread가 conflict이 나면 먼저들어온 스레드가 먼저 처리되도록 하였다.
- Managing transactional state: 보통 DB나 transactional OS에서는 data를 바로 작성하고 대신 undo log를 지니고 있는다. 그러나 이러한 방식은 deadlock에 취약하며 큰 오버헤드를 가진다. 이를 해결하기 위해서 lazy version management를 사용하였다. lazy version management에서는 모든 concurrent access thread들이 변경사항을 내부 buffer에만 반영하며 최종적으로 winner만이 data를 커널에 작성할 수 있다.
- Integration with transactional memory: 보통 User-level application에서 Transaction한 부분의 내분에서는 시스템콜을 사용하지 못하였다. TxOS는 이러한 부분에서도 System call을 사용할 수 있도록 하였다. 즉 Application은 스스로의 memory state를 roll-back해주어야 한다.