tag:blogger.com,1999:blog-6042417775578107106.post3466591531286163865..comments2023-08-05T11:30:32.754-04:00Comments on The Hacks of Life: Second. Worst. Lock. Ever.Chrishttp://www.blogger.com/profile/14648675681957285299noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6042417775578107106.post-650471719804070272021-02-28T16:55:53.098-05:002021-02-28T16:55:53.098-05:00I think you're right that a move operation wou...I think you're right that a move operation would be fast. The problem is: sometimes the client can't use move semantics. For example: the scene graph has an entity (and holds a strong reference). <br /><br />The rendering code is going to "collect" visible scene graph entities for drawing, and in doing so, _must_ take out its own references because it (1) cannot steal a reference from the scene graph (which lives on) and (2) cannot guarantee that later, while the collection is being drawn, the scene graph won't be mutated, releasing the reference.<br /><br />This is a real case in our code that requires us to not have a smart handle copy constructor take a lock.Benjamin Supnikhttps://www.blogger.com/profile/04886313844644521178noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-88132876352038599412020-06-21T10:22:37.391-04:002020-06-21T10:22:37.391-04:00> moving around ownership of the reference woul...> moving around ownership of the reference would be a "slow" operation ...<br /><br />Wouldn't a move constructor/assignment that does not fiddle with the reference count fix this? It would imply that "moved-from" objects are invalid, but should not be a big deal.Anonymoushttps://www.blogger.com/profile/09850704674446665779noreply@blogger.com