Double checkedlockingjavasingletons

Double Checked Locking For Java Singletons Parag Shah Twitter: @coding_insights Blog: http://blog.adaptivesoftware.biz

Singleton

Is This A Safe Singleton ? This Singleton is not thread safe

This Singleton Is Not Threadsafe

Lets Make It Threadsafe

That Was Expensive Making it threadsafe incurred the expense of obtaining a monitor for every invocation of getInstance()

Let's Use Double Checked Locking

Will It Work ? Very Smart... but this does not work

Why ?
Instructions can be re-ordered
Compiler
Processor
Memory reads and writes may appear to be re-ordered due to processor caches

instance = new LoneRanger(””) != Atomic

Compiler Reoredering

Compiler Reoredering Pseudocode

Can We Prevent Reoredering ?
Reordering will be done at will by the compiler or the processor if it can prove certain things
A version of the Symantec JIT VM would inline the constructor and reorder as shown
An intuitive thought - Reordering may not be done accross memory barriers

Memory Barrier
Low level (processor) construct
Instructions can be reordered within a MB but outside it
An MB causes synching of memory cache with main memory

Memory Barrier Instr1 Instr2 Instr3 Instr4 Instr5 Allowed Not Allowed Not Allowed cache Main Memory

Memory Barrier
The synchronized keyword in Java creates a memory barrier

Double Checked Locking With Memory Barrier

Monitor Exit Semantics
Instructions that happen (in the program) before the monitor exit should always happen before the monitor exit
Instructions that happen after the monitor exit MAY be reordered before the monitor exit

Double Checked Locking With Memory Barrier

OK So What The Hell Will Work ? volatile (but only after JDK 1.5) Volatile fields are special fields which are used to communicate state changes between threads.

Semantics of volatile Thread T1 Thread 2 Processor P1 Processor P2 cache cache MAIN MEMORY Flush Invalidate

Double Checked Locking With volatile

Singleton With Static Initializer

Singleton With Static Initializer
Static initializer is the simplest solution
May not be lazily loaded
All information to construct the Singleton may not be available when the class is loaded

Summary
The compiler as well as the processor can reorder instructions under certain conditions
Even if the instructions are not re-ordered, a thread may still see a stale value of a field due to memory caching
Synchronization creates an implicit memory barrier

Summary
Code cannot be moved from within the memory barrier to outside of it
Code MAY be moved from outside a memory barrier to within it
Volatile fields cannot be re-ordered with respect to other volatile fields, and are very difficult to reorder in respect to non volatile fields

Summary
A read to a volatile field invalidates the processor cache and fetches values from main memory
A write to a volatile field flushes the value to main memory
These semantics are all part of the Java memory model

Resources
The Java Memory Model
The ”double checked locking is broken” declaration - Bill Pugh
Double checked locking – clever but broken By Brian Goetz
Warning! Threading in a multiprocessor world By Allen Holub

It's a different matter, in contemporary times the Singleton pattern is considered evil ! THANK YOU

http://blog.adaptivesoftware.biz	1443
http://webcache.googleusercontent.com	5
http://74.6.238.254	1

Double checkedlockingjavasingletons

by parag on Oct 15, 2010

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 1,449

Statistics

Double checkedlockingjavasingletons Presentation Transcript