Allan W schrieb:
> A very simple work-around: the first line of main() should read:
>     Foo::instance(); // Create Foo singleton
>
> The assumption is that when main() starts, there is only one thread --
> which is always true if main() (or something it calls directly) is
> responsible for creating additional threads.

however, a disadvantage is, that thus main depends on all modules
that have singletons.  this might lead to a maintanance nightmare
when adding or removing such singleton classes.

regards

 robert

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Tzvetan Mikov" <ceco@jupiter.com> wrote in message
news:abem0f$8re@dispatch.concentric.net...
> "James Dennett" <jdennett@acm.org> wrote in message
> news:3CDAD069.5000707@acm.org...
> > It certainly doesn't require going to the kernel to synchronise
> > between threads on most platforms.
>
> It does in the general case, because blocking a thread must be done in
> kernel mode.

This is not necessarily the case. The Compaq (or is that HP..) C++ compiler
uses a simple CPU spin-wait technique to implement this synchronization in
user-level code. It provides minimal performance overhead in the 99.9% of
circumstances when the initialization is not simultaneous between multiple
threads. Of course, any platform could be free to do it with any relevant
cheap or expensive synchronization mechanism makes most sense (or none at
all).

>
> It seems to me that the issue here is that, even though the Standard might
> not provide thread primitives, it must account for the fact that most C++
> programs will be running in a multi-thread environment. As far as I can
see,
> initializing a static object in a function is one of the few parts of the
> language that must address the issue of multi-threading.

Thread-safety for a static local object can be accomplished from user code
on a non-thread-safe compiler by using an available mutex (pthread_mutex,
boost::mutex, whatever) to synchronize initialization and access of the
singleton object on the heap behind a static pointer. However, it is much
more convenient and portable and likely more efficient when the compiler
handles it automatically on a mulitthreaded platform, especially if it can
implement low-level platform-specific optimizations.

hys
--
Hillel Y. Sims
hsims AT factset.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

The alternative just doesn't really make any sense, imo. Compaq (HP :-) C++
is a good reference implementation which (already) provides meaningful
integrated support for thread-safety.

http://www.openvms.compaq.com/commercial/cplus/alpha_doc/ugvstl.html#index_x
_401
[..]
According to the C++ standard, results of recursive initialization are
undefined. To guarantee thread safety, the compiler inserts code to
implement a spinlock if another thread is initializing local static data. If
recursive initialization occurs, the code deadlocks even if threads are not
used.



thanks,

hys


"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:wylNllCGb528EwMI@robinton.demon.co.uk...
> Hm... multi-threading is not one of my areas of expertise, but I wonder
> if it would be reasonable to require static/global/namespace scope
> variables to be initialised 'atomically' as part of future support for
> multi-threading.
>

--
Hillel Y. Sims
hsims AT factset.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

It's implementation-specific, really -- on the Compaq C++ compiler, for
example, this construct is properly synchronized and thread-safe. See your
compiler docs (or do some testing to be sure).

hys

"Tzvetan Mikov" <ceco@jupiter.com> wrote in message
news:aasat8$7rp@dispatch.concentric.net...
>
> > Foo & Foo::instance()
> > {
> >     static Foo instance;
> >     return instance;
> > }
> >
>
> This isn't thread safe, so it is not exactly the same thing as having a
> global object initialized on program startup. This is OK in some
situations,
> but could create a terrible, almost untrackable bug in a multithread
> application.
>

--
Hillel Y. Sims
hsims AT factset.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tzvetan Mikov wrote:

> "Ole Reinartz" <ole.reinartz@gmx.de> wrote in message
> news:3CD13453.83E6C414@gmx.de...
> > Foo & Foo::instance()
> > {
> >     static Foo instance;
> >     return instance;
> > }
> >
> > This way your Foo singleton instance will be created the first time
> > Foo::instance() gets called to. It is not guaranteed that it exists before
> > main() gets executed, but it is guaranteed that it exists after someone
> called
> > for it.
>
> This isn't thread safe,

Yes, did I state something else? AFAIR Marco did not ask for thread safety.

> so it is not exactly the same thing as having a
> global object initialized on program startup.

Yes, it is not the same also for other reasons, but I wrote that...

> This is OK in some situations,
> but could create a terrible, almost untrackable bug in a multithread
> application.

There are many ways to fight race conditions, even some that make my example
above work in such a multithreaded environment.

Ole

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]