On 05/18/11 03:25, Vlad Khorsun wrote: >> On 17-05-2011 19:58, Vlad Khorsun wrote: >>>> PS: There is a paper >>>> (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott >>>> Meyers and Andrei Alexandrescu showing even or volatile usage in base >>>> classes are wrong. Unfortunately it's down. >>> With MSVC we are safe as we use "volatile" and compiler used read\write >>> memory >>> barriers (or acquire\release semantics) for access to volatile variables : >>> >>> http://msdn.microsoft.com/en-us/library/ms686355.aspx >>> >>> Can't said for other compilers (GCC at the first place). >>> gcc does not treat volatile as memory barrier i.e. we should better do something with it >> Most usage of volatile to implement double-check locking pattern is in >> platform neutral code, hence wrong. > We can or use compiler-\arch- specific read\write barriers, or use > interlocked access > for InitMutex::flag and InitInstance::flag. At first look i'm not found very > hot singletons at > our code, so cost of full memory barriers (because of interlocked access) > could be > acceptable for us. We can also have MemBar in our classes. And use release/acquire barriers where needed (hmm, for intel it will anyway be full membar, but probably for something like sparc this can provide better code).
------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
