ich habe gerade den Artikel in Evelissimo's
Footer gelesen (http://uint32t.blogspot.com/2007/12/you-lazy-bastard-part-1.html).
Dort steht dass boost mutex nicht statically initializable sind.
Jetzt frag ich mich, welche Bedingungen müssen dafür erfüllt sein?
Meine einzige Erklärung, wann etwas schief gehen könnte wäre, wenn ein Objekt
aus einem statischen Kontext erzeugt wird und dieses auf andere statische
Objekte zugreift. Da es keine Reihenfolgedefinition gibt, könnten diese anderen
statischen Objekte noch nicht erzeugt worden sein.
Liege ich da richtig oder gibt es noch andere Kriterien?

Gruß,
Braun-Bär Bruno

Or "Portable, thread-safe, lazily initialized singletons with Boost."

Hier dachte ich mir: OMFG.

Portable, efficient, lazily initialized thread-safe singletons are something that are needed fairly often in the C++ wild.

Bis hier hin bin ich gekommen und habe aufgehoert zu lesen.

Ich weiss, es hilft dir nicht viel.

Or "Portable, thread-safe, lazily initialized singletons with Boost."

Hier dachte ich mir: OMFG.

Portable, efficient, lazily initialized thread-safe singletons are something that are needed fairly often in the C++ wild.

Bis hier hin bin ich gekommen und habe aufgehoert zu lesen.

Ein total sinnloses Statement, solange du nicht dazu schreibst was genau dir da nicht passt.

Allein die Tatsache, dass man Singletons haeufig benoetigt

Du liest nicht, du schaust nur Worte an.

Singletons braucht man. Wenn du nur einmal in deinem Leben einen Singleton brauchst, solltest du das den Artikel lesen.

Du liest nicht, du schaust nur Worte an.

Stimmt, habe ihn jetzt gelesen. Ich kann nicht sagen, wann ein Objekt statisch initializierbar ist, aber ich kann sagen, warum Mutex es nicht ist. Ganz einfach: Es ist eine Betriebssystemresource die ueber einen Funktionsaufruf angefordert/initialisiert wird. Ob dieser vor oder nach der Initialisierung des Singletons beim Programmstart passiert, ist ungewiss. Deswegen sind wohl nur "primitive" Datentypen statisch initialisierbar, bei denen nichts wirklich spannendes im Konstruktor (Initialisierungsliste) passiert.

wenn ihr multithreaded-Singletons benötigt,
löst ihr das auch mit
boost::call_once oder wie macht ihr das?
Also ich glaube wenn ich vor dem Problem stünde, würde ich ganz zu
Beginn in main eine Initialisierungsfunktion aufrufen, die mir ein statisches
Mutex-Objekt auf dem Heap erstellt. Initial ist der Zeiger auf dieses Objekt 0.
Über diesen Mutex würde ich dann nach Aufruf der Initialisierungsfunktion alle

initSingletonMutex(); // tut nur etwas wenn der Zeiger == 0 ist
scoped_lock lock(*globalSingletonMutex);

Singletons erstellen.
Der zusätzliche Aufruf von initSingletonMutex(); hat den Zweck, dass
auch in einem statischen Kontext auf den Singleton zugegriffen werden kann.
Alle Aufrufe von statischen Funktionen & Konstruktoren vor main geschehen doch
(garantiert?) singlethreaded, oder? Man sollte natürlich keinen zusätzlichen
Thread statisch, sondern nur indirekt über main, starten. Klar, dass es dann in die Fritten gehen kann.

Gruß,
Braun-Bär Bruno

Programmierst du also eine Library die für den Einsatz in beliebigen Projekten gedacht ist (denk z.B. an die Boost Libraries), dann musst du entweder auf Singletons verzichten, oder sie thread-safe initialisieren. Alles andere ist Murks.

Verzichten ist nun aber oft doof. Denk an Fälle wo du bestimmte vorberechnete Daten hast, Lookup Tables für Hashberechnungen z.B. Sowas ohne Singleton zu machen halte ich für Verschwendung. Bzw. auch andere Dinge. Pooling von diversen aufwendig zu erzeugenden oder zerstörenden Objekten. Tracking von Instanzen (z.B. zu debugging Zwecken). Logging.

Also doch Singletons für bestimmte Dinge. Diese nun beim Programmstart zu initialisieren löst zwar das Initialisierungsproblem, dafür hat es andere Nachteile.
Zum einen kann man dann die Funktionen die diese Daten benötigen in der Initialisierungsphase nicht verwenden, da keine Reihenfolge garantiert ist. Kann man natürlich wieder über eine Init-Funktion lösen, nur Init-Funktionen sind IMO ganz schlimm pfui (auf die Gründe will ich nicht näher eingehen, das würde etwas zu weit führen).
Und zum anderen entspricht es oft nicht dem "nur für das zahlen was man verwendet" Prinzip. Was wenn die Initialisierung teuer ist (viel CPU Zeit oder RAM benötigt)? Was wenn der User der Library aber nur einen kleinen Teil der Library verwendet, der das Singleton gar nicht braucht?

Und so landen wir beim thread-safe lazy initialized singleton. Ist nicht etwas was jeder C++ Entwickler jede Woche mal braucht, aber für bestimmte Gruppen von Programmierern, u.a. Library-Entwickler, ist es etwas wo man ab und an mal froh wäre eine gute Lösung zu haben.

Keine Ahnung wie schnell oder langsam boost::call_once mit PTHREADS ist, aber wenn die Jungs nicht ganz gepennt haben gibt es da kein Problem.

Die Implementierung für Windows ist auf jedem Fall ab dem 2. Aufruf wieselflink, schneller geht's nicht (genau 1 Interlocked Befehl + Kleingeld). Der erste Aufruf ist dafür - relativ - teuer. Absolut gesehen nichts aufregendes, aber es wird immerhin aus der Prozess-ID + einer GUID ein eindeutiger Name für eine Mutex gebastelt, dann eine benannte Win32-Mutex mit CreateMutex angelegt, und diese gelockt. CreateMutex, WaitForSingleObject und ReleaseMutex sind alles Kernel-Calls, und damit ziemlich lahm. Also verglichen mit 1x InterlockedCompareExchange.

Ich hatte allerdings noch nie einen Fall, wo diese (absolut betrachtet minimalen) Kosten des 1. Aufruf derart wichtig gewesen wären, dass man nicht direkt boost::call_once hätte verwenden können.

p.S.: bevor ich dem Client eine Init-Funktion aufzwinge, löse ich das lieber über "simple" Spin-Locks (mit Backoff). Dafür reicht unter Windows ein volatile LONG , welches man auch super statisch initialisieren kann.

Now we did drop efficiency, and that makes you very very sad, Mr Premature Optimizer. There is good news and bad news. The bad news is that the Boost Thread implementation of boost::call_once is slow on Windows. The good news is that it is fast on everything else.

ist Bullshit.
Wie erwähnt kostet boost::call_once unter Windows ab dem 2. Aufruf genau 1x InterlockedCompareExchange. Schneller geht's nicht.