Scott McCaskill wrote:
We both seem to agree that merely grabbing a mutex (or blocking on an attempt to grab a mutex) is not changing the object's state.
You're saying acquring a mutex doesn't change its state?
It definitely changes the mutex's state. I don't think it _necessarily_ changes the state of the object that contains the mutex. A thread-safe "is the container empty?" method needs to acquire the mutex in order to check the container's empty-ness state, but it does not affect the container, itself. In a class that simply wraps a container to provide thread-safety, I think it can reasonably be argued that the state of the wrapper object is not changed. Obviously the "insert an object into the container" method requires the mutex lock AND changes the state of the container, itself. That method, IMHO, cannot be justifiably made const.
Somehow, and this is a gut feeling, the condition.wait() seems different to me. Perhaps because it requires a change in the objects state in order to continue.
In this case, I think the names of the operations are misleading as far as constness is concerned. "lock" sounds a lot like something that changes state, but "wait" doesn't--it sounds quite passive by comparison.
I agree - it sounds strange. Perhaps I'm simply wrong here. I'll need a better argument than naming conventions, which are notoriously arbitrary, to convince me though :) - Mark