Robert, > The issue brought up in the original thread has been already > been addressed in recent OSG versions, so the getRefMutex no > longer returns > NULL, but returns the shared global mutex. So I don't believe this > is an issue any more.
Many apologies. I did not mean to bring this out as a crash bug needing to be fixed, but rather wanted to know the reason behind using a global mutex. > I'm not clear on how this example would cause a problem with > a single mutex lock being used in this context. Do you have > an actual crash/error in behavior that you have observed? No crash to report but more of a behavioral problem. If the main thread is constructing objects while the database pager is constructing sections of the terrain, there is the possibility for the main thread to be blocked by the database thread. The more database threads there are, I would assume the greater the chance any one of the threads will be blocked. The argument here isn't that the operation is not thread safe. The argument here is that addParent is serializing itself across multiple threads, even when the data is unrelated. > Speed of creation and deletion objects and memory consumption > is the reason not to have a Mutex per Referenced object. > Mutex's are relatively large and slow to create/destroy which > is amoung the reasons why using atomic ref counts where > possible is desirable. Makes perfect sense. Currently, I do not have an idea on how to change this. I just wanted to make this known. Ryan H. Kawicki The Boeing Company Training Systems & Services Software Engineer _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
