views:

144

answers:

3

Reference:- "Modern C++ Design: Generic Programming and Design Patterns Applied" by Andrei Alexandrescu Chapter 6 Implementing Singletons.

Even if you put volatile then also it is not guaranteed to make Double Check locking pattern safe and portable.Why it is so?

If some one can put any good link that explains what is relaxed memory model and what is exactly problem with Double Check pattern.{Or someone can explain}

I used to think volatile has solve the problem but seems its not correct until I read the book.

+7  A: 

Even if you put volatile then also it is not guaranteed to make Double Check locking pattern safe and portable.Why it is so?

I'll try to provide some context.

There are three (Boehm & McLaren) portable use cases for volatile in C++ none of which has anything to do with multithreading. Alexandrescu did come up with a hack a long time back to cajole C++'s type system to help with multithreaded programming but that's that. See David Butenhof's reply on comp.programming.threads regarding the same.

The confusion regarding this qualifier stems from the fact that with some compilers (Intel's for example) volatile brings into play memory fence semantics -- which is what you need for safe multithreading. But this is not portable and should not be relied upon.

Further, most professional grade compilers fail to implement volatile flawlessly. See Regehr et al.

Confusion probably gathers much from the fact that Java, the other language, has completely different semantics for volatile and they do involve memory fences. However, note that even the Double Checked Locking is not free from issues.

dirkgently
Whether `volatile` produces a memory fence is compiler-dependent. The platform only determines whether memory fences are needed for thread-safety, but your statement that `volatile` on Intel platforms in a memory fence is not correct. `volatile` on MSVC 2008 and later does, and with other compilers MAY, but it's not assured by Intel.
Ben Voigt
@Ben Voigt: I meant Intel's compiler. Edited.
dirkgently
@dirkgently: Thank you .
Sudhendu Sharma
+1  A: 

Most of the time using a simple lock that you always check is fast enough for a singleton. You can always cache the singleton in a variable or field if you access it a lot.

Don’t think about “hacks” to avoid locking until you have proved that a simple lock is not fast enough. Writing bug free portable threading code is hard enough without making more problems for yourself.

Ian Ringrose
Totally. Premature optimization or overuse of singleton pattern.
dicroce
A: 

I don't know explicitly what "triple checked locking" is but since almost a decade ago when the compiler writers and hardware engineers started to take control away from the programmers my lazy init has had 3 states: enum eINITIALIZATION_STATE {FIRST_INITIALIZER=0,INITIALIZING,INITIALIZED} ;

( Just imagine if you sent out library software that was totally incompatible with important multi threaded algorithms in the field! But I have been writing code for SMP machines for over 30 years and the multi-core "revolution" (HA!) just really got rolling in the last decade. The compiler writers and HW engineers either didn't know what they were breaking or they decided it did not matter... But enough editorializing! )

Sooo...

enum eINITIALIZATION_STATE {FIRST_INITIALIZER=0,INITIALIZING,INITIALIZED} ;

then you have an initialization control variable:

static int init_state;  //its 0 initialized 'cause static

then the idiom is:

    IF(init_state == INITIALIZED)
        return your pointer or what ever;//the "normal" post initialization path
    ENDIF
    IF(init_state == FIRST_INITIALIZER)
        IF(compare_and_swap(&init_state,
                            INITIALIZING,
                            FIRST_INITIALIZER)==FIRST_INITIALIZER)

           //first initializer race resolved - I'm first.

           do your initialization here;

           //And now resolve the race induced by the compiler writers and the HW guys
           COMPILER_FENCE();//needs macro for portability
           HARDWARE_FENCE();//needs macro for portability

           //on intel using cas here supplies the HARDWARE_FENCE();
           compare_and_swap(&init_state,INITIALIZER,INITIALIZING);
           //now you can return your pointer or what ever or just fall through
       ENDIF
    ENDIF
    DOWHILE(*const_cast<volatile const int*>(&init_state)!=INITIALIZED)
        relinquish or spin;
    ENDDO
    return your pointer or what ever;

I am not sure if this is what was meant but because of the 3 states I suspect this may be equivalent (or at least similar) to whatever was meant by "triple checked locking" .

pgast
Out of curiosity, is there a reason for the `IF`, `ENDIF` and the other Pascal-ization macros?
ShaderOp
not meant to be code - just an idiom expressed in something between code and psuedo-language to covey an essence.
pgast