Notice
Recent Posts
Recent Comments
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
Tags
- 기아 상태
- 프로세스
- 운영체제
- 부동소수점
- 페이지 부재율
- ALU
- 컴퓨터구조
- Oracle
- concurrency
- 백준
- 알고리즘
- 동기화
- 우선순위
- mips
- Algorithm
- BOJ
- 단편화
- PYTHON
- 세마포어
- 스레드
- 스케줄링
- 페이지 대치
- 가상 메모리
- 페이징
- mutex
- 인터럽트
- fork()
- 교착상태
- 추상화
- 트랩
Archives
- Today
- Total
목록concurrency control (1)
봉황대 in CS
[Concurrency Control] Optimistic Version Locking
버전 락, (대개) 낙관적 락(Optimistic Locking)이라고 부르는 locking 개념에 대해서 정리해보고자 한다.진행하고 있는 연구 구현에서 최근에 이 친구를 추가했다 ㅎ__ㅎ Main idea어떤 데이터에 대해서 reader가 writer 보다 훨씬 많은 상황을 생각해 보자.즉, 갱신이 자주 발생하지는 않으며, 읽기 연산은 많이 발생하는 데이터라는 것이다. 여기서 비관적 락(Pessimistic Lock)처럼, 연산을 진행하기 위해서는 무조건 lock을 잡아야 한다면 매우 큰 성능 저하가 발생할 수 있다. 읽기 연산은 여러 reader가 동시에 진행할 수 있는데, 그것을 아예 막아버렸기 때문이다. 따라서 버전 락(낙관적 락)은 '우선 그냥 읽어! → 읽는 동안 쓰기가 발생했다면, 다시 읽..
Database
2024. 6. 10. 00:19