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.

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

Replace static_lazy<> with normal statics #471

Open
jonwis opened this issue Aug 30, 2024 · 3 comments
Open

Replace static_lazy<> with normal statics #471

jonwis opened this issue Aug 30, 2024 · 3 comments

Comments

@jonwis
Copy link
Member

jonwis commented Aug 30, 2024

template <class T>
class static_lazy
{
public:
void __cdecl cleanup() WI_NOEXCEPT
{
void* pVoid;
BOOL pending;
// If object is being constructed on another thread, wait until construction completes.
// Need a memory barrier here (see get() and ~Completer below) so use the result that we
// get from InitOnceBeginInitialize(..., &pVoid, ...)
if (::InitOnceBeginInitialize(&m_initOnce, INIT_ONCE_CHECK_ONLY, &pending, &pVoid) && !pending)
{
static_cast<T*>(pVoid)->~T();
}
}

According to https://learn.microsoft.com/en-us/cpp/cpp/storage-classes-cpp?view=msvc-170, function-local "magic statics" are fully supported.

Instead of defining a custom static_lazy type, use the built-in support.

  1. Remove static_lazy<>
  2. On line 2283ish in the Instance() method:
static TraceLoggingClassName* Instance() WI_NOEXCEPT \
{ \
    static TraceLoggingClassName wrapper; \
    return wrapper; \
} \
friend class wil::details::static_lazy<TraceLoggingClassName>;
@ChrisGuzak
Copy link
Member

magic statics have some overhead that some components, dlls that are loaded in many processes, what to avoid.
using wil::init_once avoids that, at the cost of more complicated code. is that your understanding?

@jonwis
Copy link
Member Author

jonwis commented Oct 30, 2024

magic statics have some overhead that some components, dlls that are loaded in many processes, what to avoid. using wil::init_once avoids that, at the cost of more complicated code. is that your understanding?

I'd like to understand that overhead and take feature requests to the CRT team if necessary. Magic statics are the intended language tool for this problem. Do you have examples of swapping init_once to magic statics so we can see the impact?

@sylveon
Copy link
Contributor

sylveon commented Oct 30, 2024

I was under the impression that statics use InitOnceBeginInitialize or something equivalent, and that using static_lazy would basically just be replacing automatic overhead with manual overhead.

You're also already paying that cost anyways, because this is how it's used currently:

static wil::details::static_lazy<TraceLoggingClassName> wrapper; \

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

No branches or pull requests

3 participants