Re: [simspark-devel] about multi-thread implementation

[Yuan X. <xuy...@gm...>]

Hi Hedayat,

Thanks for your reply.

>  You should know better than me. When I was writing the code, my main focus
> was on correctness. I was not sure about those functions and I didn't look
> further to see if they are redundant. I decided to wait for people who know
> it already! :). Yes, regarding to your description about
> Pre/PostPhysicsUpdate() functions, it seems that they are redundant. So, if
> updating GameControlServer is unnecessary too, Step() can be removed and
> using mSceneServer->PhysicsUpdate(mSimStep) before call to
> PostPhysicsUpdate() (with all required time calculations) should be enough.
>  So, please let me know if updating GameControlServer is necessary and I'll
> remove redundant calls. I have not investigated it thoroughly, but it seems
> that there is no need to update GameControlServer here. Am I right?

GameControlServer should be updated after the PostPhysicsUpdate.
So the loop of the main thread should be:
mSceneServer->PrePhysicsUpdate
mSceneServer->PhysicsUpdate
mSceneServer->PostPhysicsUpdate
GameControlServer->Update

>  I'm using Mesa 7.0.1 with nvidia binary driver 169.09 and the problem still
> exists.
>  Yes, the main reason was rendering, but there is another problem too. FRP
> sensor calls dJointGetFeedback(). ODE is not thread safe and this call will
> generate segmentation faults some times. Also, this call should happen
> before next physics update since the feedback information will not be
> available then (I think!).

Bad news, the OpenGL should be thread-safe.

You can call dJointGetFeedback() in PostPhysicsUpdateInternal(), and
cache the feedback information.
It just likes cache the actions and realize them in PrePhysicsUpdateInternal().


>
>  I don't think so. As far as I know, it is just another synchronization
> method. It doesn't affect thread execution model and they run in parallel.
> The only thing which it does is in it's wait function. According to boost
> docs:
> [...]
>
>  As all of the threads will be placed in a ready state, they should run in
> parallel. Please correct me if I'm wrong.
>

Ah, I see! It is OK, and much simpler and clear than the old code, great job!
But there may be a small problem in current code:
The scene tree should not be accessed by the main thread and
SimCtrThreads at the same time.
(May be the problem will come after you remove the Step().)
So when call the follow functions, the SimCtrThreads should be blocked.
mSceneServer->PrePhysicsUpdate
mSceneServer->PostPhysicsUpdate
GameControlServer->Update
So the lines in RunMultiThreaded() needs adjustment, I think it is easy for you.

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------