Skip to content

Refactoring: namespace#7

Open
davidklaftenegger wants to merge 8 commits into
masterfrom
refactoring
Open

Refactoring: namespace#7
davidklaftenegger wants to merge 8 commits into
masterfrom
refactoring

Conversation

@davidklaftenegger
Copy link
Copy Markdown
Owner

This pull request adds namespaces to the codebase to avoid cluttering the default namespace, and avoid potential naming conflicts with user code.

davidklaftenegger and others added 7 commits May 30, 2022 18:54
There is no good reason to put all these custom types into the global
namespace, so this commit moves all queue implementation related code
into a new namespace.
These types were re-defined by every implementation, but as they are
part of the API of the tantrum queues, they should not be part of the
individual implementations, but defined once and used by each
implementation.
Instead of a hard-to-understand template, the missing function is added
to the internal lock implementations that were missing it.
All remaining code that was in the default namespace is moved into
namespace qd by this patch. For backwards compatibility, the default
choices are exported into the default namespace, but users should switch
from qdlock to qd::qdlock.
Adopt suggestions from pylint:
 - Use 4-space indentation instead of tabs.
 - Add docstrings for module and functions.
 - Capitalize constants.
 - Avoid using the same name for variables and function names.
 - Use snake_case for some variables.
 - Split long lines into multiple ones.
In addition, use the `with ... as ...:` construct.
With the help of cpplint, the following code cleanups have been applied:
 - Use FILENAME_HPP_ to protect multiple inclusions of the header file.
 - Make sure that C headers appear before all C++ headers.
 - Include <utilty> header for move.
 - Delete unnecessary ; at the end of lines.
 - Mark with explicit constructors with a single argument.
Comment thread hqdlock.hpp
if(numa_available() != -1) {
numanodes = numa_num_configured_nodes();
/* Initialize the NUMA map */
for (int i = 0; i < num_cpus; ++i) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Since we are re-writing this code, wouldn't be a better idea to use auto (or size_t) instead of int in these loops (and in similar ones below)?

Also, sysconf() returns a long, not an int. Perhaps you want to do something about this.

Comment thread locks/mcs_futex_lock.hpp
if(found != nullptr) {
mynode->is_locked.store(mcs_node::taken, std::memory_order_release);
found->next = mynode;
for(int i = 0; i < 512; i++) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Consider moving the 512 into a define or global constannt.

Comment thread locks/mcs_lock.hpp
if(found != nullptr) {
mynode->is_locked.store(mcs_node::taken, std::memory_order_release);
found->next = mynode;
for(int i = 0; i < 512; i++) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

512 also mentioned here

Comment thread locks/mutex_lock.hpp
}
};
namespace qd {
namespace locks {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

There is really no reason to indent nested namespaces. In fact, this practice is discouraged by many style checkers.

In C++17, it's possible to write nested namespaces using namespace A::B::C { ... } instead of namespace A { namespace B { namespace C { ... } } }.
My suggestion is to adopt the C++17 style of writing these.

Comment thread locks/pthreads_lock.hpp
locked.store(true, std::memory_order_release);
}
};
namespace qd {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Ditto

Comment thread locks/tatas_lock.hpp
}
void wake() {}
};
namespace qd {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Ditto.

ticket_futex_lock() : ticket(0), serving(0) {}
ticket_futex_lock(ticket_futex_lock&) = delete; /* TODO? */
namespace qd {
namespace locks {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Another nested namespace.

Comment thread mrqdlock.hpp
static void wait_writers(base* t) {
while(reinterpret_cast<this_t>(t->__data)->writeBarrier.load() > 0) {
qd::pause();
namespace qd {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

My suggestion is to not indent after a namespace. It causes very long lines and unnecessary differences.

Comment thread queues/entry_queue.hpp
counter.store(0, std::memory_order_relaxed);
closed.store(status::OPEN, std::memory_order_relaxed);
}
namespace qd {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Nested namespace

Comment thread queues/entry_queue.hpp
template<long ENTRIES, int BUFFER_SIZE>
class entry_queue {
/** type for the size field for queue entries, loads must not be optimized away in flush */
typedef std::atomic<long> sizetype;
Copy link
Copy Markdown
Collaborator

@kostis kostis Jun 6, 2022

Choose a reason for hiding this comment

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

Use some more well-defined type (e.g. int64) instead of long here?
(Similar comment about three lines above -- and also some lines below)

Copy link
Copy Markdown
Collaborator

@kostis kostis left a comment

Choose a reason for hiding this comment

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

I have left many suggestions, but they are just suggestions for improvement; not a prerequisite for merging this.

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.

2 participants