I think this is my own fault. I'm debugging some issues with multi-threading and using boost scoped_lock. My code looks like this: { // Enqueue the notification to be processed scoped_lock(m_notifications.lock); m_notifications.sources->push(note); } Am I correct in assuming this is not going to work as expected? The compiler might not even instantiate the lock given this code? I need to write it like this? { // Enqueue the notification to be processed scoped_lock locked(m_notifications.lock); m_notifications.sources->push(note); } Kind regards, Samuel
2009/5/21 Space Ship Traveller
{ // Enqueue the notification to be processed scoped_lock(m_notifications.lock); m_notifications.sources->push(note); } Am I correct in assuming this is not going to work as expected? The compiler might not even instantiate the lock given this code?
Well, it will instantiate the temporary object, and probably won't optimize it out since it's non-trivial, but it disappears "at" the semicolon that ends the statement, so it doesn't do anything useful. I think it would actually work to do this: scoped_lock(m_notifications.lock), m_notifications.sources->push(note); But the way with the named object is the canonical way, so you really should use it instead. HTH, ~ Scott
participants (2)
-
Scott McMurray -
Space Ship Traveller