Description
Lock Table
Project Hierarchy
Project Overview
- Your task is to implement a lock table module that manages lock objects of multiple threads.
- The module doesn’t need to be compatible with your developing database in this step.
- Instead, the module should be correctly working with the given test code.
- This project is a prerequisite step for the next project, Concurrency Control.
- Design your lock table and describe it on hconnect Wiki
Overall Architecture
(mutex)
Overall Architecture
Lock Table APIs
int init_lock_table(void)
- Initialize any data structures required for implementing lock table, such as hash table, lock table latch, etc.
- If success, return 0. Otherwise, return non-zero value.
lock_t* lock_acquire(int table_id, int64_t key)
- Allocate and append a new lock object to the lock list of the record having the
- If there is a predecessor’s lock object in the lock list, sleep until the predecessor to release its lock.
- If there is no predecessor’s lock object, return the address of the new lock object.
- If an error occurs, return NULL.
int lock_release(lock_t* lock_obj)
- Remove the lock_obj from the lock list.
- If there is a successor’s lock waiting for the thread releasing the lock, wake up the successor.
- If success, return 0. Otherwise, return non-zero value.
Lock Table APIs
Hash Table
elements
Lock List
lock_acquire()
lock_acquire()
lock_release()
Lock Object
- The given test code will
- call init_lock_table() API function,
- create multiple threads each of which
- repeatedly acquire and release multiple record locks by calling lock_acquire(), lock_release().
- The test code will safely schedule the operations avoiding deadlock, so you don’t have to deal with the deadlock problem in this project.
- Analyze the test code as much as you want.
Transfer thread
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
| 77 | -20 | 100 | 55 | -120 -30 | 62 | … | 35 | 200 | 22 | 340 | -123 | -99 | 230 | 85 |
accounts 230…
table1 table2
Transfer thread
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
| 77 | -20 | 100 | 55 | -120 -30 | 62 | … | 35 | 200 | 22 | 340 | -123 | -99 | 230 | 85 |
accounts 230…
table1 table2
Transfer thread
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
| 77 | -20 | 100 | 55 | -120 -30 | 62 | … | 35 | 200 | 22 | 340 | -123 | -99 | 230 | 85 |
accounts 230…
table1 table2
Transfer thread
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
| 77 | -20 | 90 | 55 | -120 -30 | 62 | … | 35 | 210 | 22 | 340 | -123 | -99 | 230 | 85 |
accounts 230…
table1 table2
Transfer thread
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
| 77 | -20 | 90 | 55 | -120 -30 | 62 | … | 35 | 210 | 22 | 365 | -123 | -99 | 230 | 60 |
accounts 230…
table1 table2
Transfer thread
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
| 77 | -20 | 90 | 55 | -120 -30 | 62 | … | 35 | 210 | 22 | 365 | -123 | -99 | 230 | 60 |
accounts 230…
table1 table2
Scan thread
Deadline & Regulations
- Deadline: Nov 15 11:59pm
- We’ll only score your commit before the deadline, and your submission after the deadline will not be accepted.
- You must follow the given project hierarchy and the path of the
“unittest_lock_table” executable file, otherwise, you cannot get a score.
