Let’s say I schedule a new job, which will alter an object’s Transform (changing its position).
This specific job is dependent on another job completing, which is taking a long time.
Can I expect my object to be moved in time for it to be rendered at its new position on that same frame?
I would assume not, since the renderer still needs to execute on the main thread every frame, regardless of what the other threads are doing.
So if I needed to guarantee that the object is moved on that frame, would I just not be able to use the job system for this?
Thanks for any knowledge. 
Ok. 
Thank you for the fast reply.
I asked this particular question, because it seems like a very common problem case.
The way I’m used to writing game code, it’s easy to think of cases in which it’s important that an object move a reliable, constant distance per frame.
Using the Job system, I’m not sure how you could gaurantee that anymore.
Joachim said in each of his talks that he believes all game code can be written this way. Surely that includes common Transform operations.
What am I missing here?
Well, as I said … I’m not that familiar with it.
Do bear in mind, even from your simple example… if you want the position to move after a long operation, you wouldn’t be expecting it to finish that/next frame, even without the job system, right? (Well, if you let the long operation execute over time… if you kept it synchronous, that’s different*).
I’d have to get familiar with the job system to get a better opinion on the subject
Hey, thank you again!
Just for clarification:
-
In boring old synchronous code, I would be expect task A (the slow one) and task B to always complete in the same frame, before that frame is rendered. The trade off would be a slower frame rate, but all of the work would be gauranteed to be done before the renderer does it’s thing.
-
in asynchronous code, if tasks A and B were both turned into jobs (with B dependent on A), I wouldn’t expect the renderer to wait. I would expect the frame to be rendered regardless of the state of any scheduled jobs, which means the user could potentially not see a change each frame.
Are those assumptions right? Wrong? I would love to know!
For sure that sounds right 
I’m hoping that someone more knowledgeable than I will come along and explain why not being able to gaurantee a constant rate of change per frame is actually just fine.
…I also suppose it’s not impossible that the renderer could be made to wait until all (or certain) scheduled jobs are done. It would just result in a lower frame rate, like the synchronous example…theoretically…
New day, fresh perspective:
Maybe I’ve been thinking about asynchronous gameplay code all wrong. I already start a lot of tasks in my code which play out over multiple frames, without predefinable end times- things like navigating between points, or playing animations. Or (although I don’t use them) the types of things that people might use Coroutines for.
Maybe the right way to think about the Job system is that it’s meant to only replace those things- persistent tasks which can play out over multiple frames. Things you can just start and wait to finish at some point. Things which don’t need to be gauranteed to finish on any particular frame.
So in my first example, like methos5k said: if I needed to gaurantee a constant rate of change per frame, that just wouldn’t be a good candidate for a Job task. It’s not meant to replace all of your synchronous code.
That sounds very sensible to me. I imagine it being used that way
Plus, I imagine it being used when it’s ‘worthwhile’. Not like just for anything/always
We’ll see lol