Quote Originally Posted by superbonzo View Post
exactly, and the question is, are locking properties the right way of encapsulating synchronization ? ( note that you mentioned locking as a *reason* for using getters/setters ) I don't think so. Such an approach focuses on a narrow view of thread "safety" meant just as "it does not crash with threads". Thread safety means more than that ...
of course, I'm not against protecting methods with locks per se ( eventually offering multiple levels of granularity ), but getters/setters often are just public fields ( badly ) disguised, politically correct POD struct fields ...
I mentioned locking as 'another' reason for using getters/setters, not as the *only* reason. Locking on properties are a way to achieve fine grain synchronization for an object, but using this approach depends on what you need (as you know). If you have one lock object and are synchronizing multiple fields with get/set methods, it isn't too efficient - a better approach would be to have a single get/set method pair that acts on the range of properties. However, if you have multiple lock objects within the object and wish to access different fields simultaneously, then the get/set approach could be a valid approach.

At any rate, I always attempt to encapsulate the locking whenever possible. It always bugs me when I see locking on an object performed by a caller of the object. Sometimes, it is unavoidable, but coding like this is fragile in my opinion because it forces the callee to always lock when accessing the object. Even worse is when there is external locking and the manual release of the lock (vs. using RAII).

All of this depends on what the usage of the code is. I imagine it would be different if coding for a general purpose library used by thousands vs. coding objects used by a small team.