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 <[email protected]> wrote: > 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 returns a >> reference to locally defined static NotifySingleton. Finally to force the >> NotifySingleton to initialize automatically rather than on first invocation >> of osg::Notify() I have used a static proxy class that simple calls the >> getNotifySingleton() to make sure that it's called right after loading the >> library. >> >> My hope that this combination will ensure that the threading problems >> relating to the initialization of the global notify variables you've seen >> will not occur. This doesn't make the noitfy() handlers themselves thread >> safe, I'll defer this to your own custom implementation. >> >> I have checked in my changes to svn/trunk and also attached the modified >> Notify.cpp. Could you please test this and let me know if this works. > > Again, thanks for the revised code, Robert. I think, the modified > version handles initialization of the notification mechanism more > clearly and the proxy prevents concurrent initialization of the global > resources. Anyway, both my working project and my test program crash > with heap corruption more or less frequently. For now, I tested it on > Win 7 x64. > > Based on the svn trunk version of Notify.cpp, I experimented with > another approach. The solution is prototype, however, here is what > worked for me: I used a thread local storage to separate access to > osg::NotifyStream for each thread. As discussed earlier in this > thread, this assumes stream classes (including std::ostream and > std::stringbuf) to be at least reentrant. According to > http://msdn.microsoft.com/en-us/library/c9ceah3b%28v=vs.100%29.aspx > this is true at least for my Visual compiler implementation. > Currently, there are some other drawbacks with this solution: As I > used QThreadStorage for now, it requires QtCore library to be linked > in core osg. Maybe, another TLS implementation would be more suitable > (does OpenThreads has one?). Although I could not recognize capital > performance loss yet, this may be another critical issue. > Nevertheless, I tried the modified version upon OSG 3.0.1 on all my > Win 7 x64 machines and the heap corruption never showed up again. > For further inspection and interest, I attached my modified version of > Notify.cpp which has a preprocessor flag OSG_NOTIFY_STREAM_PER_THREAD > to toggle the use of thread local storage. > > Cheers, > Matthias Schütze, Germany > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
