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

ThreadMonitor : Add class for monitoring threads used for processes #5425

Merged
merged 2 commits into from
Aug 18, 2023

Conversation

johnhaddon
Copy link
Member

I intend to use this to beef up our test coverage for TaskCollaboration, as part of some other work I'm doing. Hopefully it is flexibile enough to be generally useful as a debugging tool, but I may have designed it too much with my initial use case in mind. If you have any thoughts on how it might be made more useful, feel free to let me know.

Copy link
Contributor

@danieldresser-ie danieldresser-ie left a comment

Choose a reason for hiding this comment

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

LGTM, seems like a useful tool, though I don't know exactly how I'll use it


s = monitor.plugStatistics( random["outFloat"] )
self.assertEqual( len( s ), IECore.tbb_global_control.active_value( IECore.tbb_global_control.parameter.max_allowed_parallelism ) )
self.assertEqual( sum( s.values() ), 100001 )
Copy link
Contributor

Choose a reason for hiding this comment

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

This test would be a bit more convincing if there was some check of the distribution - fiddling with a Poisson distribution a little, if the selection of threads to run were independent, it should be basically guaranteed that every bucket get at least 0.5 * 100000 / max_allowed_parallelism ... maybe lack of independence breaks this though? You've probably tested it in other ways so you know it works, I was just thinking that this would pass on [ 100001, 0, 0, 0, ... ]

Copy link
Member Author

Choose a reason for hiding this comment

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

This does guarantee that each thread took at least 1 task (not 0), because otherwise there wouldn't be an entry for that thread at all (it's the processing of a task that creates the per-thread container in the first place).

I agree that we do want to test the quality of task distribution as well, but that's not really our concern when testing ThreadMonitor itself. I intend to use ThreadMonitor to provide such tests in ValuePlugTest and ComputeNodeTest in an upcoming TaskCollaboration pull request.

Copy link
Member Author

@johnhaddon johnhaddon Aug 17, 2023

Choose a reason for hiding this comment

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

I did completely mess up the process mask test though - that's fixed in f7341df.

@danieldresser-ie
Copy link
Contributor

Just to be clear, I don't see any problems with merging this ( though maybe I should be being more careful with stuff like the process mask test issues :P )

@johnhaddon johnhaddon merged commit 1ec40b0 into GafferHQ:1.3_maintenance Aug 18, 2023
4 checks passed
@johnhaddon johnhaddon deleted the threadMonitor branch August 18, 2023 13:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants