Add fiber safety to crystal/once #15370
Draft
+239
−131
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Replaces the implicit initialization of Thread and Fiber class variables with an explicit initializer since both should be initialized before `__crystal_once_init` is called. This is working for now because the `class_[getter|property]` macros in Thread and Fiber don't protect against either recursion nor parallel initializations, but we plan to protect them (using Mutex) which would immediately break with an infinite recursion: Mutex#lock -> Fiber#current -> Thread#current -> Mutex#lock -> ...
Prefer a def explictly called by `Crystal.init_runtime` over the implicit `__crystal_once_init` fun injected by the compiler. The fun is no longer defined for new compiler builds, however it's still defined to support older compiler releases.
So we can use the getter and property macros in crystal/once
Removes the global mutex that prevents concurrent initializers to run, while still being able to detect reentrancy, by keeping a list of pending operations, protected by a global lock that doesn't block other initializers from running. Using a linked-list of stack allocated operations may sound inefficient compared to a `Hash` but there should usually not be many concurrent or parallel lazy initialization that following a few pointers will matter much in practice. This isn't very important for the eager initialization of class vars and constants that happen sequentially at the start of the program and before we even start threads, but we plan to reuse the feature to protect lazy initialization of class variables (i.e. the `class_getter` and `class_property` macros) when it would matter more. Introduces the `Crystal::Once` namespace. The initialization entry is now `Crystal::Once.init` instead of `Crystal.once_init`. Co-authored-by: David Keller <[email protected]>
ysbaddaden
force-pushed
the
refactor/add-fiber-safety-to-crystal-once
branch
from
02e70e6 to
d3eb541
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Removes the global
Mutex(previously only used when thepreview_mtflag is defined) that would prevent concurrent initializers to run in parallel, while still being able to detect reentrancy.It works by keeping a list of pending operations (one per
flagpointer) protected by a global lock that doesn't block other initializers from running.Using a linked-list of stack allocated structs may sound inefficient compared to a
Hashbut there should usually not be many concurrent / parallel / nested lazy initializations that following a few pointers would be significant compared to calculating a hash and (re)allocating memory.This isn't very important for the initialization of class vars and constants (happens sequentially at the start of the program, before we even start threads) but we plan to reuse the feature to implement #14905 where the lazy initialization can kick in at any time.
Follow up to #15369 and #15371
CREDITS: @BlobCodes wrote the initial implementation in master...BlobCodes:crystal:perf/crystal-once-v2. I mostly removed the fences (SpinLock already deals with memory order), made it compatible with both the enum or bool variants, where the enum allows to skip over checking the operations when processing —maybe not very significant?
I shall read his code much more carefully now 🙇