May volatile be in user defined types to help writing thread-safe code

Question

I know, it has been made quite clear in a couple of questions/answers before, that volatile is related to the visible state of the c++ memory model and not to m

Answer 1

I don't know specifically whether Alexandrescu's advice is sound, but, for all that I respect him as a super-smart dude, his treatment of volatile's semantics suggests that he's stepped way outside his area of expertise. Volatile has absolutely no value in multithreading (see here for a good treatment of the subject) and so Alexandrescu's claim that volatile is useful for multithreaded access leads me to seriously wonder how much faith I can place in the rest of his article.

Answer 2

I think the issue is not about thread-safety provided by volatile. It dosen't and Andrei's article dosen't say it does. Here, a mutex is used to achieve that. The issue is, whether the use of volatilekeyword to provide static type-checking along with use of mutex for thread-safe code, is abuse of the volatile keyword? IMHO it's pretty smart, but i have come across developers who are not fans of strict-type-checking just for the sake of it.

IMO when you are writing code for multi-threaded environment, there is already enough caution to emphasize wherein you would expect people not to be ignorant of race-conditions and deadlocks.

A downside of this wrapped approach is that every operation on the type that is wrapped using LockingPtr must be through a member function. That will increase one level of indirection which might considerably affect developers comfort in a team.

But if you are a purist who believes in the spirit of C++ a.k.a strict-type-checking; this is a good alternative.