Hello Thomas,

Thomas Kuleßa wrote:
> Am 05.02.2010 um 20:34 schrieb Carsten Neumann:
>> Thomas Kulessa wrote:
>>> which should start the osc thread with aspect 1 and then call
>>>
>>> osc_thread->getAspect()
>>>
>>> it returns 0.
>> yes, getAspect() is actually a static member function of Thread that 
>> returns the aspect of the currently running thread and since you call it 
>> from the 'main' thread you get aspect 0. Try calling it from your 
>> thread_func, it should return 1 there.
>>
> 
> thanks for your reply. Stupid me. So since there is no function to get the 
> aspect of a thread, besides tfrom he current, I assume it is also not 
> possible to sync both changelists from one thread? 

uhm, sorry I'm a little lost, which *two* changelists do you want to 
sync from one thread. Normally one applies the changes done in one 
thread to another.
You can make changes in both threads but then you need to also sync in 
both directions (and be careful not to introduce cycles). If a field is 
modified in both threads the order you perform the syncs in will 
determine which value will end up in it (last one wins).

> Since thats what I tried to do, to avoid that changes get lost or will 
> applied on objects which are already outdated I wanted to sync both 
> changelists/aspects from one thread. 
> I intended to do blocking IO in the OSC server thread. So this is probably 
> not possible because the changelist updates will occur to infrequent?

IIUC you only need to make sure that if the OSC server thread blocks the 
other thread can keep on running. A bool protected by a mutex that 
indicates the availability of updates could be used to only perform the 
sync from OSC server thread to the other one when updates are available.

>> take a look at Doc/tutorial/progs/13multithreading2.cpp, it uses a 
>> thread on aspect 1 to spin an object.
> 
> I remember that 13multithreading2.cpp as well as the tutorial both work on 
> one aspect!?

It seems I misunderstood what you meant by "work on one aspect", sorry. 
The tutorial at first glance looks as if it only makes changes to the 
scene in the thread that spins the object, however navigation happens in 
the main thread. This is a very simple case where the two threads simply 
modify disjunct sets of objects and since the "rotate" thread does not 
care about the camera beacon (which is used for the navigation) syncing 
only from the rotate thread to the main thread suffices.

        Cheers,
                Carsten


------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to