Replies: 1 comment
-
Just general comments: I didn't write the original disk manager, so I'm not sure what the original design motivations were. There was a version of the buffer pool project where we had a scoreboard for buffer pool performance. You might want to try writing and running some local benchmarks for fun. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I would like to ask a simple question: Is disk manager in bustub thread safe?
I would try to give my answer: it is not thread safe.
int
attributes.std::fstream
is not thread safe, refering to C++ StandardFollowing words are under the assumption, that disk manager is not thread safe. If the assumption is not the truth, please ignore the following words.
Then I would like to ask: why to design the disk manager not to be thread safe?
Yes. We can have a mutex outside of the disk manager doing the protection. In the Project 1, we should have a mutex to protect the disk manager inside of buffer manager.
There is a way maybe better than that: to use POXIS
pread
,pwrite
to implement theReadPage
andWritePage
functions. Since thepage_id
represents a unique part of a file and differentpage_id
s share no overlap in file. POSIXpread
,pwrite
would be thread safe and easy tobe implemented. (Possible disadvantage: not modern C++.)
I am hoping and being grateful to see an answer. 😄
The motivation of the question:
I want to have low lock(mutex) granularity in my implementation: the buffer manager have to release it's
global_mutex
duringReadPage
andWritePage
these I/O operations. Then I came to this question and did some reading. I even have upload a version to gradescope and passed the concurrency test, in which the disk manager is not protected by any mutex.Beta Was this translation helpful? Give feedback.
All reactions