Re: Will Modern C++ Design ever get fixed?
On Oct 23, 11:32 am, Miles Bader <mi...@gnu.org> wrote:
Witold Kuzminski <witold.kuzmin...@gmail.com> writes:
Please see the quote from the article you provided the link to,
and which you co-authored; it is from the introduction:
"This article explains why Singleton isn?t thread safe, how DCLP
attempts to address that problem, why DCLP may fail on both
uni- and multiprocessor architectures, and why you can?t
(portably) do anything about it."
How can one do something about it _non-portably_?
E.g., if the single-time initialization of `shared_field' (only called
when shared_field == NULL) looks like:
{
LockGuard guard (lock);
if (! shared_field)
{
local_variable = make_expensive_data_structure ();
MEMORY_BARRIER ();
shared_field = local_variable;
}
}
where "MEMORY_BARRIER" is __sync_synchronize or equivalent (both acts
as a compiler memory-barrier and emits an appropriate CPU-specific
memory-barrier instruction or whatever).
Then I guess one could encapsulate that in a class that used the
efficient technique on systems where some MEMORY_BARRIER was available
(90% ?), and an explicit lock or something on anything else.
Thanks,
I would count that as portable. Any hardware that has multiple cores
offers memory barriers in some form or another. The trick is then to
coerce the compiler, linker, et al, to not mess with it, and if your
compiler doesn't already understand threading, this is probably an
exercise doomed to fail. The compiler must understand threading issues
to some degree, otherwise it can and will generate thread-unsafe
code.
I think the quote meant to say "And why you can't do anything about it
portably /and reliably in pure C++/." As soon as you go outside pure C+
+03, such as to POSIX, win32, C++0x, a library which you implemented
with assembly for each platform, Boost, etc., then you can do stuff
about it portably.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]