Skip to content
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.

Sign up for GitHub

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

[onert] Apply inline variable to EventWriter #14652

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[onert] Apply inline variable to EventWriter #14652

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 0 additions & 3 deletions runtime/onert/core/src/util/EventWriter.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,9 +18,6 @@

#include <cassert>

// initialization
std::mutex EventWriter::_mutex;

void EventWriter::readyToFlush(std::unique_ptr<EventRecorder> &&recorder)
{
{
Expand Down
2 changes: 1 addition & 1 deletion runtime/onert/core/src/util/EventWriter.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -128,7 +128,7 @@ class EventWriter
void flush(WriteFormat write_format);

private:
static std::mutex _mutex;
static inline std::mutex _mutex;
Copy link
Contributor

Choose a reason for hiding this comment

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

@ragmani Is it OK to use static inline for mutex class variable? Doesn't it have possibility to inlining mutex object by compiler?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it's perfectly fine to use static inline for a mutex class variable. The inline keyword in this context is used to ensure that the variable has a single definition across all translation units, which allows you to define it in a header file without causing multiple definition errors. It does not cause the mutex object itself to be "inlined" or optimized away in the way that function inlining might; it merely affects linkage. The mutex will still behave as expected for synchronization.

Copy link
Contributor

@hseok-oh hseok-oh Feb 13, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

I found sentence from your link at #14647: https://en.cppreference.com/w/cpp/language/inline

  • An inline function or variable(since C++17) with external linkage (e.g. not declared static) has the following additional properties:
    • It has the same address in every translation unit.

Doesn't it mean that variable with non-external linkage (static variable) can be different address?

Copy link
Contributor

Choose a reason for hiding this comment

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

I found answer at https://en.cppreference.com/w/cpp/language/storage_duration#external_linkage

  • Any of the following names declared at namespace scope have external linkage, unless they are declared in an unnamed namespace
    • names of classes, their member functions, static data members (const or not), nested classes and enumerations, and functions first introduced with friend declarations inside class bodies;

Copy link
Contributor

Choose a reason for hiding this comment

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

This feature is hard to understand based on compiler world...

Copy link
Contributor Author

@ragmani ragmani Feb 13, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

This feature is hard to understand based on compiler world...

The two types of variables(static class member or namespace-scope variable) can be declared as inline variables. If both variables associated with inline keyword are problematic, it can be expected that the compiler will generate errors about that.
I think there is no need to overthink it and we just follow the rule at https://en.cppreference.com/w/cpp/language/inline regardless of compiler world.

Because the meaning of the keyword inline for functions came to mean "multiple definitions are permitted" rather than "inlining is preferred" since C++98, that meaning was extended to variables.


// number of observer of an executor that want to write profiling data
int32_t _ref_count;
Expand Down