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
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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