Re: [simspark-devel] discussion

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

Hi Joschka, Oliver and All

2007/2/5, Oliver Obst <Oli...@ne...>:
> Hi,
>
> On 04/02/2007, at 3:50 PM, Yuan Xu wrote:
>

> Well, one direction to approach that would be (1) to start using
> threads anyway:
> 1.a) We decide to care about inconsistencies in sensor readings.
> We could start this by using no buffer, and for the beginning, we
> could use locks so that no 2 threads operate on the scene graph.
> Later on, if the threads are working, we can think about something to
> get rid of the big locks (like the proposed buffer).

I have done the 1.a) test in an individual program,
I attached the source file.

In my test program, I try to use three threads which Joschka mentioned:
physics-thread, agent-management-thread and the monitor-agent.

Although the test is simple, it contains what we want, I think.
There are some values be operated by only one thread at the same time :
`simTime', `nextTime', `nextRenderTime',
they are the `scene tree' in the test program.

The function doSomething(t) is just a delay function,
just like the program need something to do.

I assume some time ( the function with * operates the `scene tree' ):
a *simstep* needs 2ms,
parse the received msg needs 2ms,
*prepare the send msg* needs 2ms,
*save the actions to scene tree* needs 2ms,
send the msg through net needs 2ms,
*the monitor render* needs 2ms

and
physics step is 10ms,
agent step is 200ms,
monitor step is 150ms.

the format of stdout is
< [ real_start_time - wait_time ] function( simTime ) real_end_time >

I test it in a Pentium D 2.8G , 1G RAM computer,
you can compile the source by
> g++ threads1.cpp -lSDL -lboost_thread-mt -Wall
run the a.out
and then do
> gnuplot threads1.plt
to generate the test result in you own computer.

I think we can guarantee the correct order of events.
see the png I attached.

In the plotting,
the x-axis is the real time, which get from SDL,
the y-axis have different meanings:
the `x' is just a line y=x, it is a base line
the `physics.log' is the sim time in physics thread,
the `agent.log' is the sim time in agent thread,
and the `monitor.log' is the sim time in monitor thread;
the 'scene.log' denotes which thread is operating the `scene tree':
0 - no thread
100 - the physics thread
200 - the agent thread
300 - the monitor thread
lastly, the `stepWait.log' denotes which thread is locking the physics thread:
400 - no thread
500 - the agent thread
600 - the monitor thread

>From the plotting, we can see the simulation running smoothly.

Is everything right?

Should we implement the plan 1.a) in simspark, or do more testing ?

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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