Robert Vinluan

Hello,

Yes, the error is related to the bug fix that was committed to Houdini 21.0.464.

If you cannot update at the moment, then you can open C:\Program Files\Side Effects Software\Houdini 21.0.440/houdini/python3.11libs\hqueue\job.pyin a text editor and remove this line:

Then save the changes to the file. You should be good to go after that.

Cheers,
Rob

Hi Aleksei,

I heard back from Thinkbox and as monomonalluded to, Thinkbox said that the race condition can still happen even with the frame range format change.

Thinkbox said that no matter what frame range format (1,2,3 or 1-3) is passed into AppendJobFrameRange, the frame range string is then passed into FrameUtils.Parse(framelist, False)(https://docs.thinkboxsoftware.com/products/deadline/10.4/2_Scripting%20Reference/class_deadline_1_1_scripting_1_1_frame_utils.html#a38a00ffc9defc0c0eeb5a1e503516f9b) and the resulting int array is used by Deadline.

It's still possible your change helps reduce the frequency in which the race condition error occurs but it's hard to say. It would be great if others who have hit the race condition can confirm whether the patch improves their overall experience.

Cheers,
Rob

algarifov
Hi All,

I believe I found a workaround for the Race Condition issue which was the reason for SideFX to move from Task-based to Job-based PDG Deadline Scheduler. At least it fixed Deadline Task creation instability for us in Pixomondo.

In Pixomondo we believe in power of collaboration and I am glad to share the solution with the community!

Issue seems to be located in how Scheduler uses AppendJobFrameRange.

....

Hi Aleksei,

This is a fantastic analysis! What's even more interesting is that the code in the Deadline Scheduler, which executes the `AppendJobFrameRange` command, has a comment that reads:
frame_range should be a string with format: start-end Examples: '0-5' '1-4', '10-20'
but the actual code formats the frame range differently, i.e. 0,1,2,3,4, as you pointed out.

The comment doesn't explain why the frame range should be formatted that way (of course) but it makes me wonder if we discovered this workaround years ago when the Deadline Scheduler was first implemented, but then changed the way we specified the frame range without realizing we re-introduced the race condition? For what it's worth, the Deadline documentation doesn't even mention what the frame range format should be so it's unclear to me where we obtained information on the frame range format. Perhaps it was just based on observations of the Deadline Monitor UI at the time?

Anyway, I'll reach out to our Thinkbox contacts and get their thoughts on this workaround.

As for the proposed code change, I think your two assumptions are correct but I can't say for sure. I'll discuss this with the rest of the PDG dev team here.

Thanks for this!

Cheers,
Rob