tag:blogger.com,1999:blog-5084302589052586355.post4776771444537601498..comments2011-06-15T22:14:53.980-07:00Comments on placeholder: Blame the Managementbretthttp://www.blogger.com/profile/01838925956817921960noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5084302589052586355.post-56193989040422723352008-07-10T09:54:00.000-07:002008-07-10T09:54:00.000-07:00I never said that atomic ops are god awful. Just ...I never said that atomic ops are <I> god awful</I>. Just that messing with the reference count via the atomic ops requires many more cycles, three to four times as many in my experience, then not having to worry about the reference count at all. Atomic ops like these are definitely preferable over locking a mutex when you can get away with it. We're probably talking 10X slow down versus 4x slowdown since the locking of the mutex will require more cache synchronization on top of the synchronization that is already being done on the reference count.<BR/><BR/>I would also expect that the Boehm collector has to do some sort of thread synchronization when running in a multi-threaded program. Due to the amount of legacy code I've got at work integrating the Boehm collector isn't really an option so giving it a good look hasn't been to high of a priority. Sounds like they have some form of lock-free algorithm for the collection if they're using atomic ops though.bretthttps://www.blogger.com/profile/01838925956817921960noreply@blogger.comtag:blogger.com,1999:blog-5084302589052586355.post-47702265826448496972008-06-30T19:34:00.000-07:002008-06-30T19:34:00.000-07:00...The Boehm-Demers-Weiser GC uses these apparentl......<BR/>The Boehm-Demers-Weiser GC uses these apparently <I>god awful</I> atomic operations.<BR/><BR/><A HREF="http://www.hpl.hp.com/research/linux/atomic_ops/" REL="nofollow">http://www.hpl.hp.com/research/linux/atomic_ops/</A>Gavin Beattyhttps://www.blogger.com/profile/04637429903073555689noreply@blogger.com