Re: [Boost-users] Why is boost::thread::mutex noncopyable?
Can someone help me to understand why boost::thread::mutex is noncopyable? I expect that there is a good reason, but I can't see it at the moment.
Thanks for the link. Here is the text: Why do Mutexes have noncopyable semantics? To ensure that deadlocks don't occur. The only logical form of copy would be to use some sort of shallow copy semantics in which multiple mutex objects could refer to the same mutex state. This means that if ObjA has a mutex object as part of its state and ObjB is copy constructed from it, then when ObjB::foo() locks the mutex it has effectively locked ObjA as well. This behavior can result in deadlock. Other copy semantics result in similar problems (if you think you can prove this to be wrong then supply us with an alternative and we'll reconsider). I disagree with the first comment: "The only logical form of copy would be to use some sort of shallow copy semantics in which multiple mutex objects could refer to the same mutex state." What's wrong with the copy of a mutex being a new independent mutex? (There's a problem if you copy a locked mutex, but I don't propose to do that.) --Phil.
Phil Endecott wrote:
Can someone help me to understand why boost::thread::mutex is noncopyable? I expect that there is a good reason, but I can't see it at the moment.
Thanks for the link. Here is the text:
Why do Mutexes have noncopyable semantics?
I disagree with the first comment: "The only logical form of copy would be to use some sort of shallow copy semantics in which multiple mutex objects could refer to the same mutex state." What's wrong with the copy of a mutex being a new independent mutex?
Because then it's not a copy semantic, but a plain new construction.
(There's a problem if you copy a locked mutex, but I don't propose to do that.)
But what you propose will work for you only. It won't work for anyone else. By the way you should read further down, item #6, on the FAQ for how to put a member mutex in a class and have the copy semantics you want. There even an example ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On 01/01/06, Phil Endecott <spam_from_boost_users@chezphil.org> wrote:
I disagree with the first comment: "The only logical form of copy would be to use some sort of shallow copy semantics in which multiple mutex objects could refer to the same mutex state." What's wrong with the copy of a mutex being a new independent mutex? (There's a problem if you copy a locked mutex, but I don't propose to do that.)
I think that would be more confusing, personally, since it wouldn't be making a copy. With non-copyable you get a compiler error if you try to copy it; with a do-nothing copy things would compile but not copy any sort of state or behaviour, which a copy would intuitively be expected to do. - Scott
participants (3)
-
me22 -
Phil Endecott -
Rene Rivera