2024년 12월 2일 (월) 08:19에 Ahn9807님의 편집

2024-12-02T08:19:03Z

← 이전 판		2024년 12월 2일 (월) 08:19 판
26번째 줄:		26번째 줄:
	; TxOS Overview		; 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는 <code>sys_xbegin()</code>와 <code>sys_xend()</code>사이에 존재하는 selective한 150개 정도의 시스템콜이 transaction하다는 것을 보장하였다. 굳이 보장할 필요가 없는 시스템콜은(e.g., reboot, mount, mremap, mprotect ... etc) Future work으로 남겨두었다.		: 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는 <code>sys_xbegin()</code>와 <code>sys_xend()</code>사이에 존재하는 selective한 150개 정도의 시스템콜이 transaction하다는 것을 보장하였다. 굳이 보장할 필요가 없는 시스템콜은(e.g., reboot, mount, mremap, mprotect ... etc) Future work으로 남겨두었다.

	~~== Challenges ==~~

	== Design ==		== Design ==
33번째 줄:		31번째 줄:
	# Managing transactional state: 보통 DB나 transactional OS에서는 data를 바로 작성하고 대신 undo log를 지니고 있는다. 그러나 이러한 방식은 deadlock에 취약하며 큰 오버헤드를 가진다. 이를 해결하기 위해서 lazy version management를 사용하였다. lazy version management에서는 모든 concurrent access thread들이 변경사항을 내부 buffer에만 반영하며 최종적으로 winner만이 data를 커널에 작성할 수 있다.		# 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해주어야 한다.		# Integration with transactional memory: 보통 User-level application에서 Transaction한 부분의 내분에서는 시스템콜을 사용하지 못하였다. TxOS는 이러한 부분에서도 System call을 사용할 수 있도록 하였다. 즉 Application은 스스로의 memory state를 roll-back해주어야 한다.

	~~== Implementation ==~~

	~~== Conclusion ==~~

Ahn9807: 새 문서: 분류: ACM SOSP 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로 이어질 수 있다...

2024-12-02T06:56:13Z

새 문서: 분류: ACM SOSP 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로 이어질 수 있다...

새 문서

[[분류: ACM SOSP]]

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는 <code>sys_xbegin()</code>와 <code>sys_xend()</code>사이에 존재하는 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해주어야 한다.

== Implementation ==

== Conclusion ==

Operating System Transactions - 편집 역사

2024년 12월 2일 (월) 08:19에 Ahn9807님의 편집