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

fix: fix multi-threading problems #11

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Conversation

DaymareOn
Copy link
Owner

Make access to ActorManager::m_skeletons and ActorManager::Skeleton::m_armors thread-safe.
CTDs might have happened when using 'smp' commands and Dynamic HDT.

Make access to ActorManager::m_skeletons and ActorManager::Skeleton::m_armors
thread-safe.
CTDs might have happened when using 'smp' commands and Dynamic HDT.
return _deprefix(a->cstr()) == _deprefix(b->cstr());
}

void hdt::util::transferCurrentPosesBetweenSystems(hdt::SkyrimSystem* src, hdt::SkyrimSystem* dst)
Copy link
Collaborator

Choose a reason for hiding this comment

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

There is a function declaration in DynamicHDT.h, please also delete it

Copy link
Owner Author

Choose a reason for hiding this comment

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

Thanks, will do.

Copy link
Owner Author

Choose a reason for hiding this comment

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

Done.


static bool _match_name(hdt::IDStr& a, hdt::IDStr& b);

static std::string _deprefix(std::string str_with_prefix);
Copy link
Collaborator

Choose a reason for hiding this comment

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

You might want to move these two static methods to utilities. Just a suggestion.

Copy link
Owner Author

@DaymareOn DaymareOn Feb 23, 2022

Choose a reason for hiding this comment

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

Good idea, thanks, will do.

Copy link
Owner Author

Choose a reason for hiding this comment

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

Done.

{
std::lock_guard<decltype(m_lock)> l(m_lock);

auto p = findArmor(on_actor_formID, on_item_formID, new_physics_file_path);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Shouldn't new_physics_file_path be NULL or ""?

Copy link
Owner Author

Choose a reason for hiding this comment

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

I'll check.

Copy link
Collaborator

Choose a reason for hiding this comment

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

You can push another commit with these changes to threadsafingArmors branch. So I can give you an approving review. :)

Copy link
Owner Author

Choose a reason for hiding this comment

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

Ok, checked, no I pass the physics_file_path, as you did in ReloadPysicsFileImpl.
Seems correct to me.

@@ -64,8 +64,7 @@ namespace hdt

if (timeStep <= RESET_PHYSICS)
{
if (!this->block_resetting)
updateTransformUpDown(m_skeleton, true);
updateTransformUpDown(m_skeleton, true);
Copy link
Collaborator

Choose a reason for hiding this comment

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

If an armor tries to read its initial position or runs into any situation that triggers the above function, flickers may occur. block_resetting was used to keep this function from being used when replacing the old system with the new one.

Please confirm that this will not lead to any flickers during the transition of physics files.

Copy link
Owner Author

Choose a reason for hiding this comment

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

My understanding at the time was that the lock in ActorManager, once set, was protecting against all these kinds of things.
I think a test is required. I personally witnessed no flicker at all, but could you please test yourself when I will have integrated all your suggestions, as you know how to reproduce flickers and what they look like?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm ok with it.

@@ -53,9 +53,6 @@ namespace hdt
}
}

void suspendSimulationUntilFinished(std::function<void(void)> process);
std::atomic_bool m_isStasis = false;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there a method for us to suspend the simulation while game is not paused besides this?

Copy link
Owner Author

Choose a reason for hiding this comment

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

I'll look at it.

Copy link
Owner Author

Choose a reason for hiding this comment

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

I want to deepen my analysis on this.

@DaymareOn DaymareOn marked this pull request as draft February 26, 2022 22:16
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