Hi Toben,
On 19 October 2012 22:56, Torben Dannhauer tor...@dannhauer.info wrote:
What is the current status of this issue?
Currently I'm working with openthreads and learn a lot, but as the
threadstartedreported,
the application crashes more or less frequently if I use the notify macro
Hi,
Your test program has bug in it. std::rand() is not threadsafe nor reentrant. I
don't think it can corrupt heap, but it will be better to use something else or
use mutex around rand();
Cheers,
Filip
--
Read this topic online here:
Hi,
What is the current status of this issue?
Currently I'm working with openthreads and learn a lot, but as the
threadstartedreported,
the application crashes more or less frequently if I use the notify macro
heavily.
Thank you!
Cheers,
Torben
--
Read this topic online
HI Matthias,
OpenThreads doesn't expose thread local storage but does use it
internally to provide the Thread::CurrentThread() functionality.
Might it be possible to use this in your implementation?
Robert.
On 5 July 2012 10:32, Matthias Schütze matthi.schue...@googlemail.com wrote:
Re: Using
Re: Using the notification API with multi-threading - heap corruption errors
Hi,
What I have gone for with src/osg/Notify.cpp is to use a NotifySingleton
class that holds all the global notify variables and initializes these in
it's constructor, then a static getNotifySingleton() function
Hi Mathias,
On 14 June 2012 17:29, Robert Osfield robert.osfi...@gmail.com wrote:
W.r.t static initialization, this is something we need to sort out,
and as long as there isn't a performance overhead in how we tackle it
then I have no problem with it being the only code path for
Hi,
Beyond mutexes, I am less skilled with thread synchronisation. But in
other libraries like Qt sometimes the concept of thread local storage
is used to separate resource access from parallel threads. Do you
think this concept would be applicable to provide every thread with
its own
Hi Matthias,
On 14 June 2012 15:21, Matthias Schütze matthi.schue...@googlemail.com wrote:
I agree with that too. Solution using custom osg::NotifyHandler with mutexes
is easy and it dont have to be in osg core library, what about using
NotifyHandler with mutexes if OSG_NOTIFY_LEVEL is set ?
Hi,
Beyond mutexes, I am less skilled with thread synchronisation. But in
other libraries like Qt sometimes the concept of thread local storage
is used to separate resource access from parallel threads. Do you
think this concept would be applicable to provide every thread with
its own stream?
Hi,
I am actually working on a complex project which uses OSG 3.0.1 on a
Windows 7 Professional x64 SP1 platform with Visual Studio 2010
Premium SP1. Because I encountered random heap corruption errors, I
was testing and debugging with different configurations of my program
and could state the
Hi Matthias,
osg::notify() is written on the assumption that stream are thread
safe, avoiding adding extra mutexes is desirable as the performance
would really suffer if we had to add them to all osg::notify() calls.
I can see how that osg::initNotifyLevel() method might be problem if
multiple
Hi Robert,
Thanks for your fast reply and revised code!
osg::notify() is written on the assumption that stream are thread
safe, avoiding adding extra mutexes is desirable as the performance
would really suffer if we had to add them to all osg::notify() calls.
I agree with the argument not to
12 matches
Mail list logo
