This is an archive of the discontinued LLVM Phabricator instance.

Fix initialization of th_task_state on each thread on expanding hot teams.
ClosedPublic

Authored by tlwilmar on Jan 20 2023, 12:19 PM.

Details

Summary

The th_task_state was initialized from the master thread's value, or from its memo stack, but this causes problems because neither of those may have the right value at the right time. However, other threads in the team are guaranteed to have the right values, so we change the initialize the new threads' th_task_state from the th_task_state of the last of the older threads in the hot team.

Fix #56307.

Diff Detail

Event Timeline

tlwilmar created this revision.Jan 20 2023, 12:19 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 20 2023, 12:19 PM
tlwilmar requested review of this revision.Jan 20 2023, 12:19 PM
jlpeyton accepted this revision.Feb 8 2023, 1:53 PM

LGTM

This revision is now accepted and ready to land.Feb 8 2023, 1:53 PM

Hi @tlwilmar could you elaborate a bit on this part as it is very unobvious at first

However, other threads in the team are guaranteed to have the right values, so we change the initialize the new threads' th_task_state from the th_task_state of the last of the older threads in the hot team.

Thanks!

@rogfer01 th_task_state is used to refer to one of two task teams that are reused for each hot team. These two task teams exist because of a need to start using a new one while there may still be activity on the old task team, so we flip between the two. Each thread has a th_task_state so it knows which task team is in use for a particular parallel region. When a hot team is expanded in size for a larger parallel region, new threads added to the team need to have their th_task_state initialized to exactly what the other threads in the team are using, so that they are all in sync. So instead, we just initialize from a thread that was in the team before the resize.

@rogfer01 th_task_state is used to refer to one of two task teams that are reused for each hot team. These two task teams exist because of a need to start using a new one while there may still be activity on the old task team, so we flip between the two. Each thread has a th_task_state so it knows which task team is in use for a particular parallel region. When a hot team is expanded in size for a larger parallel region, new threads added to the team need to have their th_task_state initialized to exactly what the other threads in the team are using, so that they are all in sync. So instead, we just initialize from a thread that was in the team before the resize.

Thanks for the explanation @tlwilmar!