Skip to content

Conversation

@WZhuo
Copy link
Contributor

@WZhuo WZhuo commented Dec 10, 2025

No description provided.

Status InMemoryCatalog::CreateNamespace(
const Namespace& ns, const std::unordered_map<std::string, std::string>& properties) {
std::lock_guard guard(mutex_);
std::unique_lock lock(mutex_);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep std::lock_guard if you only need write guard here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

std::lock_guard cannot be used to acquire a write lock on a std::shared_mutex

Copy link
Contributor

@HuaHuaY HuaHuaY Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

std::lock_guard is a template wrapper (cppreference link). Any lock which meets BasicLockable can be used in std::lock_guard, including std::shared_mutex.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wrong — lock_guard can indeed lock a shared_mutex, but it is still recommended to use unique_lock and shared_lock for read-write locking on a shared_mutex for better code readability.

Copy link
Contributor

@HuaHuaY HuaHuaY Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there are some differences about code readability here. std::unique_lock has additional overhead but std::scoped_lock and std::lock_guard don't. It should not be compared with std::scoped_lock or std::lock_guard.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using unique_lock and shared_lock with shared_mutex makes it clear that this is a read-write lock, as seeing unique_lock immediately indicates that exclusive (write) access is being acquired. And, in other mutex scenarios, use lock_guard.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on std::lock_guard if we care the performance here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compiler can optimize the simple scene (godbolt). But I still suggest to keep the code from doing unnecessary things. The simpler the better.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's unnecessary, and I recommend use the unique_lock/shared_lock pair for locking shared_mutex

@WZhuo WZhuo force-pushed the read_write_lock branch 3 times, most recently from db5d805 to fe4b32d Compare December 10, 2025 05:53
Comment on lines +450 to +454
ICEBERG_ASSIGN_OR_RAISE(auto metadata,
TableMetadataUtil::Read(*file_io_, metadata_file_location));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be delayed until register is successful. Or we can add a new lockless LoadTableImpl to wrap the internal.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's an issue: if a file is invalid, register returns failure, but the map may already contain an entry. Subsequent calls to register will then return "already exists".
Therefore, I think we should validate the file's legitimacy in advance, ensuring that only valid table metadata can be successfully registered.

#include <mutex>
#include <shared_mutex>

#include "iceberg/exception.h"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please not add this since we cannot throw in most of the codebase.

Status InMemoryCatalog::CreateNamespace(
const Namespace& ns, const std::unordered_map<std::string, std::string>& properties) {
std::lock_guard guard(mutex_);
std::unique_lock lock(mutex_);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on std::lock_guard if we care the performance here.

@WZhuo WZhuo requested a review from wgtmac December 12, 2025 04:17
@wgtmac wgtmac merged commit 898d862 into apache:main Dec 12, 2025
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants