3 ms·
C++11 is finally saying that this is not ok, as it really breaks the const contract, and can produce varying behavior in a threaded situation. You could also a
by dbcfd 13y ago
C++11 is finally saying that this is not ok, as it really breaks the const contract, and can produce varying behavior in a threaded situation.
You could also argue that read/write locks aren't legitimate applications (starvation, increased contention, alternate solutions).
- stingraycharles 13y agoBut the const function could still accept a non-const reference to a mutex, and still produce varying behavior in a threaded situation. In other words, what you're describing as the const contract sounds a lot like a pure function, which it definitely is not.
- dbcfd 13y agoI'm not sure how it would produce varying behavior if it satisfies the const contract, in regards to the object itself. You're passing in a non-const reference, so wherever that came from would be expected to change. However the object itself would not change. Your object would be at StateA regardless of who gets the mutex first.
- deleted 13y ago[deleted]