Thanks for the note. No, I don't recall that atomic count was considered; I'm not familiar with it. After we made the change to use CRITICAL_SECTION in OT, I think we had some people with thread intensive apps take some timing measurements against the old v. new OT and the difference was negligible. At the time I was primarily concerned that CRITICAL_SECTION was not more expensive than the old code, and this showed that it was not. Hardly a scientific approach, and we're definitely open to improvements. -Paul
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wittman Sent: Monday, January 15, 2007 5:31 PM To: osg users Subject: RE: [osg-users] Thread-safe reference countingviaatomicincrement/decrement Don't get me wrong, I'm certainly not suggesting a return to the old OpenThreads::Mutex implementation. In fact, I'm not suggesting any change to OpenThreads::Mutex at all. Instead I'm just asking whether the use of CPU-based interlocked instructions (a la boost::detail::atomic_count()) have been considered as an alternative to lock-based synchronization. Presumably if there is value in it, this could be added to OpenThreads as OpenThreads::AtomicCount and used independently of OpenThreads::Mutex. Did the performance measurements test the effect on node creation/destruction performance with Referenced::setThreadSafeReferenceCounting(true) vs. Referenced::setThreadSafeReferenceCounting(false)? That's the metric I'm particularly concerned about. I don't have any experimental data on performance at this point, and I don't know that this would be a significant bottleneck. I'm just interested to see if anyone has previously considered this approach in the event that it does become an issue for me. What I do know is that during osg::Referenced creation the CRITICAL_SECTION structure requires separate heap allocation of about 56 bytes of memory on 32 bit Windows and about 80 bytes on 64 bit Windows, including an allocation of a kernel handle, and requires deletion of the same at destruction. An atomic count would incur no extra allocation or deletion. -Mike _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Monday, January 15, 2007 4:43 PM To: 'osg users' Subject: RE: [osg-users] Thread-safe reference counting viaatomicincrement/decrement When the OpenThreads code was converted to use CRITICAL_SECTIONS, some performance measurements were done, and the cost was insignificant compared to the old code. Do you have some data that contradicts that? -Paul _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wittman Sent: Monday, January 15, 2007 3:37 PM To: osg users Subject: [osg-users] Thread-safe reference counting via atomicincrement/decrement Hi everybody, Has anyone considered implementing thread-safe reference counting in osg::Referenced via atomic integer increment/decrement operations, as opposed to mutexes? That would seem to be a lot lower overhead in terms of memory allocation and speed, at least on Windows. I believe thread-safe reference counting will need to be enabled globally to get OSG and the garbage collector to play nicely together for any C# wrappers, and I'm cringing at the cost of all those CRITICAL_SECTION allocations. -Mike
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
