[DO NOT MERGE] Poor main attempt to battle thread safety #31
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.
Instead of approach in #24 (basically synchronize all access to
ObjectContainer
), i tried another approach.Idea is to instead of container to synchronize access itself, it attempts synchronize access to parent container between other child containers. It not 100% solution (because those who use parent container directly will have to be careful to participate in synchronization, but in theory it will be more performant than #24 (because if you only one using container, you don't need to pay for synchronization). I need to way to check if this is actually win for Specflow's usecase (may be not, cause Specflow use a long chain of containers).
I'm planning to benchmark every solution, but I have not settled on right profile.
This and #24 has a problem of holding the container-wide lock during construction of object. It could be very costly if your constructors are heavy.