Menu
▾
▴
Re: [simspark-devel] about multi-thread implementation
|
From: Hedayat V. <hed...@ai...> - 2008-03-07 10:41:02
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
<span><br>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;} blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important} blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important} blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important} blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>"Yuan
Xu" <a class="moz-txt-link-rfc2396E" href="mailto:xuy...@gm..."><xuy...@gm...></a></b></i> wrote on 03/07/2008 11:59:43 AM:</span><br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;" cite="mid:18a...@ma..." type="cite">
<pre wrap="">Hi Hedayat and all,
I take a look at current multi-thread implementation.
</pre>
</blockquote>
Hi Yuan,<br>
Thanks a lot for looking at the code and for your comments.<br>
<br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;" cite="mid:18a...@ma..." type="cite">
<pre wrap="">But I can not understand it exactly, could you help me?
1). in simulationserver.cpp
00491 Step();
00492 ControlEvent(CE_EndCycle);
The Step() calls mSceneServer->Pre/PostPhysicsUpdate() again,
I think it is redundant, what should be called maybe
mSceneServer->PhysicsUpdate(mSimStep),
right?
</pre>
</blockquote>
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. <br>
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?<br>
<br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;" cite="mid:18a...@ma..." type="cite">
<pre wrap="">
Place ControlEvent(CE_EndCycle) here is for rendering function in the
main thread?
The original code can not work with Mesa-6.4.1, it can work with
Mesa-6.5.21 and ATI fglrx 8.31.5 .
I checked the ChanegeLog of Mesa, there are some bug-fixes of thread
safe in Mesa-6.5.
Can you test that?
</pre>
</blockquote>
I'm using Mesa 7.0.1 with nvidia binary driver 169.09 and the problem
still exists.<br>
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!). <br>
In fact, at first I decided to treat RenderControl as an exception (to
call its EndCycle() function in the main thread and other EndCycle
functions in their own thread), but because of the above problem I
decided to call all of them in the main thread. I put it in my TODO
list for future to consider a better implementation.<br>
<br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;" cite="mid:18a...@ma..." type="cite">
<pre wrap="">
2). Synchronization by the barrier just make all the threads run one
by one, it is not the real parallel.
</pre>
</blockquote>
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:<br>
<br>
"When a barrier is created, it is initialized with a thread count N.
The first N-1 calls to <code class="computeroutput">wait()</code> will
all cause their threads to be blocked. The Nth call to <code class="computeroutput">wait()</code> will allow all of the waiting
threads, including the Nth thread, to be placed in a ready state. The
Nth call will also "reset" the barrier[...]. This functionality allows
the same set of N threads to re-use a barrier object to synchronize
their execution at multiple points during their execution."<br>
<br>
As all of the threads will be placed in a ready state, they should run
in parallel. Please correct me if I'm wrong.<br>
<br>
Thanks again,<br>
Hedayat<br>
<br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;" cite="mid:18a...@ma..." type="cite">
<pre wrap="">The original idea is make SimControlNodes run parallel, and
PhysicsUpdate can also run at the same time.
Since the scene tree can be used as cache.
PrePhysicsUpdate copy data from scene tree to ODE, PosPhysicsUpdate
copy data from ODE to scene tree.
PhysicsUpdate only effects ODE internal data.
( To Joschka,
Sorry, I do not finished the document work about single-thread and multi-thread.
I want to make things clear firstly.)
</pre>
</blockquote>
</body>
</html>
|
