shared state management
sylvi
Prof. Park,
I would like to know your plan about shared state management for
multicluster system.
Are we going to use the current implementation of shared state
implemented by Dr. Kim? or Do you plan to implement other mechanishm
for sharing state among clusters?
Till now, I have used the current shared state management in
nvmVirtualPhysics and nvmOSGART. I havent implemented shared state in
nvmVRPNClient.
Please let me know your plan for shared state management.
Related with cleanup the NAVER codes to make it scenegraph
independent.
In order to do that I think we need to implement some basic class
derived from OSG class. In the current source code, I use a lot of OSG
class, such as osg::Vec3, osg::Matrix, and also functions to calculate
the matrix and so on. In my opinion, if we want to make NAVER module
scenegraph independent, we should not use OSG class directly inside
NAVER module.
Thank you,
sylvi
Changhoon Park
You are right. We need to crate new class to access OSG indirectly.
Actually, there is a design pattern named bridge to support what we want to do.
This will be included in my next project.
http://en.wikipedia.org/wiki/Bridge_pattern
Relating to shared state, I'd like to use existing code if there is no problem.
And, I will cleanup share state with the kernel.
Please feel free to call me if you have any question or comments.
010-3300-7837 I have a class staring at 4:00 PM.
Changhoon Park
sylvi
I have implemented shared state for nvmVRPNClient.
The codes have been upload in CVS server. For example how to use, see
clusterPhysicsDevice.xml in bin directory.
I have modified the kernel little bit to support the shared state.
In the previous version implemented by Dr. Kim,
Master: send data to slave, wait for ack
Slave: receive data from Master, send ack
This works fine in Physics module, however it doesnt work for device
because in the device I use windows timer callback function for each
device.
'wait for ack' causes some callback functions for device have never
been called.
Therefore I modified the kernel,
Master: send data to the slace, NO WAIT ACK
Client: receive data from master, NO SEND ACK.
I have tested this,
it seems working well (which means the slave can get the data sent by
server) for nvVRPNTracker, nvVRPNAnalog, nvVRPNButton, nvVRPNForce,
nvVRPNSpeech.
I havent implemented shared state for nvVRPNSound because I am not
sure what data need to be shared among clusters. Therefore, defining
cluster for nvVRPNSound means Master will connect to vrpn server and
be responsible for managing sound but no sharing data among clusters.
Another remaining work, sendEvent for speech interpretation result
have not been implemented.
For this, I think I need to modify the kernel (nvField), add new class
for storing speech interpretation result, so it can be routed to other
modules.
sylvi
On Mar 29, 2:06 pm, "Changhoon Park" <changhoonp...@gmail.com> wrote:
> Sylvi
>
> You are right. We need to crate new class to access OSG indirectly.
> Actually, there is a design pattern named bridge to support what we want to
> do.
> This will be included in my next project.http://en.wikipedia.org/wiki/Bridge_pattern
>
> Relating to shared state, I'd like to use existing code if there is no
> problem.
> And, I will cleanup share state with the kernel.
>
> Please feel free to call me if you have any question or comments.
> 010-3300-7837 I have a class staring at 4:00 PM.
>
> Changhoon Park
>
> On 3/29/07, sylvi <sylv...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Prof. Park,
>
> > I would like to know your plan about shared state management for
> > multicluster system.
> > Are we going to use the current implementation of shared state
> > implemented by Dr. Kim? or Do you plan to implement other mechanishm
> > for sharing state among clusters?
> > Till now, I have used the current shared state management in
> > nvmVirtualPhysics and nvmOSGART. I havent implemented shared state in
> > nvmVRPNClient.
>
> > Please let me know your plan for shared state management.
>
> > Related with cleanup the NAVER codes to make it scenegraph
> > independent.
> > In order to do that I think we need to implement some basic class
> > derived from OSG class. In the current source code, I use a lot of OSG
> > class, such as osg::Vec3, osg::Matrix, and also functions to calculate
> > the matrix and so on. In my opinion, if we want to make NAVER module
> > scenegraph independent, we should not use OSG class directly inside
> > NAVER module.
>
> > Thank you,
>
> > sylvi
>
> --
> Changhoon PARK- Hide quoted text -
>
> - Show quoted text -
Changhoon Park
Would you check the below code?
I wonder that why we need to implement like Part 1. As you know, run() is a loop for visual rendering not timer.
In my thinking, timerFunc will be invorked by timeSetEvent like Part 2.
I'd like to know your comment about this?
C. Park.
Part 1
void
nvViewer::run(float time)
{
while( !mOSGViewer->done() )
{
///////////////////////////////////////////////////////////////////////////////
// for cluster by Jinwook
for ( unsigned int i = 0; i < mListModules.size(); i++ )
if ( !mListModules[i]->isTimerEnabled() )
{
if ( mListModules[i]->getClusterMode() != nvModule::SLAVE ) mListModules[i]->syncCluster();
mListModules[i]->syncClusterData();
}
Part 2
if ( _clstFrequency )
{
TIMECAPS tc;
if ( timeGetDevCaps(&tc, sizeof(TIMECAPS)) == TIMERR_NOERROR )
{
UINT delay = max(1, (int)(1000.0 / _clstFrequency));
UINT wTimerRes = min(max(tc.wPeriodMin, delay), tc.wPeriodMax);
if ( timeBeginPeriod(wTimerRes) != TIMERR_NOERROR ) printf("ERROR::error in timeBeginPeriod\n");
timeSetEvent(delay, wTimerRes, _timerFunc, (DWORD_PTR)this, TIME_PERIODIC);
}
}
void CALLBACK _timerFunc(UINT uID, UINT uMsg, DWORD_PTR dwUser, DWORD_PTR dw1, DWORD_PTR dw2)
{
nvModule *pModule = (nvModule *)dwUser;
if ( pModule->getClusterMode() != nvModule::SLAVE ) pModule->syncCluster();
pModule->syncClusterData();
Changhoon Park
What do you think about seperating the code of timer from cluster ?
I mean i'd like to make a virtual function in the nvModule that will be invoked by timer without realting to cluster.
I wonder that if we want to use high frequently updated function, we need to use a cluster or not ?
Let me know what you understand.
C. Park
Changhoon PARK
sylvi
Prof Park,
Part 1 is used if the user doesnt specify updateFrequency in the XML
file.
So by default, syncCluster and syncClusterData will be invoked in
run().
If the user defines an updateFrequency in the cluster (Part 2)
timerCallbackFunction will be registered and will be invoked dependent
on the updateFrequency which is defined.
About your next question,
with current implementation, it is possible to use high
frequencyUpdate rate in standalone computer.
What we need to do is define cluster but without defining master and
slave.
So this module will work as standalone application but with high
frequency update rate.
<module class="nvmNewClass" ... >
<cluster updateFrequency="500" />
...
</module>
I hope this explanation could answer your questions.
sylvi
On Apr 1, 12:57 am, "Changhoon Park" <changhoonp...@gmail.com> wrote:
> What do you think about seperating the code of timer from cluster ?
> I mean i'd like to make a virtual function in the nvModule that will be
> invoked by timer without realting to cluster.
>
> I wonder that if we want to use high frequently updated function, we need to
> use a cluster or not ?
> Let me know what you understand.
>
> C. Park
>
> On 3/31/07, Changhoon Park <changhoonp...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Sylvi
>
> > Would you check the below code?
>
> > I wonder that why we need to implement like Part 1. As you know, run() is
> > a loop for visual rendering not timer.
> > In my thinking, timerFunc will be invorked by timeSetEvent like Part 2.
>
> > I'd like to know your comment about this?
>
> > C. Park.
>
> > Part 1
>
> > void
> > nvViewer::run(float time)
> > {
> > while( !mOSGViewer->done() )
> > {
>
> > ///////////////////////////////////////////////////////////////////////////////
Changhoon Park
Thanks for your answer.
I understood.
C. Park