-
Notifications
You must be signed in to change notification settings - Fork 285
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dbconnector] protect db information with mutex #423
Conversation
STL containers are only thread safe for reads. But not for writes. protect the db information variables with rwlock. Signed-off-by: Ying Xie <[email protected]>
This change is intended to address issue sonic-net/sonic-buildimage#6103. However, after added this tentative protection, I realized that there is no code removing anything from m_db_info. So I guess this protection won't really protect us against the issue above? |
common/dbconnector.h
Outdated
@@ -54,6 +55,7 @@ class SonicDBConfig | |||
static bool isGlobalInit() { return m_global_init; }; | |||
|
|||
private: | |||
static pthread_rwlock_t db_info_lock; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make this static seems like bad idea to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the information under protection are static variables. That is why this lock is also static.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea, entire class is static, which is bad XD
@yxieca What is main motivation for this change? You are manually locking/unlocking lock in many places and it could be easy to forget to do that when code will grow. At least wrapping that to class and release in destructor. Also is std::shared_lock what you are looking for? also mistake in title "dbconnectgor" |
Is issue related to m_inst_info/m_db_info ? those are static map, and in general it's advised to not uses statics, since they "wired" things can happen process is shutdown, depends on complexity, and threads running, it could happen that some destroyed data is still in use which can lead to some really hard to track errors |
This SonicDBConfig class don't see to me as critical performance class, so std::recursive_mutex would make more sense and more clean solution. Also, i know not the scope of this PR, but i don't see a reason to make this normal non static class, not even a singleton. |
All the Refers to: common/dbconnector.cpp:70 in 74cf24e. [](commit_id = 74cf24e, deletion_comment = False) |
common/dbconnector.cpp
Outdated
@@ -141,11 +142,13 @@ void SonicDBConfig::initializeGlobalConfig(const string &file) | |||
catch (domain_error& e) | |||
{ | |||
SWSS_LOG_ERROR("key doesn't exist in json object, NULL value has no iterator >> %s\n", e.what()); | |||
pthread_rwlock_unlock(&db_info_lock); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pthread_rwlock_unlock [](start = 12, length = 21)
Better to use std::lock_guard
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great idea. If we decide to move forward. I'll make change accordingly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea, and use recursive_mutex as discussed
common/dbconnector.h
Outdated
@@ -6,6 +6,8 @@ | |||
#include <unordered_map> | |||
#include <utility> | |||
#include <memory> | |||
#include <pthread.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you dont need probably this include
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes. I added that earlier. it is no longer needed now.
STL containers are only thread safe for reads. But not for writes. protect the db information variables with rwlock.
Signed-off-by: Ying Xie [email protected]