Volatile keyword is thought of as an easy form of synchronized. It require less coding than synchronized and frequently have less run-time overhead.
When we talk about locks, 2 main features introduce:
i.) mutual exclusion which means only one thread at a time can hold a given lock, and
ii.) visibility which ensures that changes mode to shared data before releasing the lock are accessible to another thread that subsequently acquires the lock.
Comparing the volatile keyword with synchronized, the volatile is a field modifier while synchronized is used with code blocks and methods.
Let's clear one more point here. Threads can have local copies of variables/data which don't have to be the same as the data held in other threads. In fact, java has an idea of a MAIN memory which holds the current value for variables. And threads can have their own copy of variables which can be different from the main memory. And it's possible that suppose you have a variable named X which value is 1 for thread1 and 2 for thread2 but these values are not distributed to main memory or other threads.
So, using "volatile" does not allow to have a local copy of a variable that is different from the value currently held in main memory. Whenever you access or update the volatile variable in any thread, its value is visible to all other threads immediately.
But when using "synchronized" which firstly obtains and releases locks on monitors can force only one thread a time to execute a code block, if both threads use the same monitor (lock). It also synchronizes memory.
However, the volatile only synchronizes the value of one variable between thread memory and "main" memory, the synchronized synchronizes the value of all variables between thread memory and "main" memory and handles locks (acquire/release) and have more overhead than volatile.
In java, an increment (i.e. ++) and similar operations are not atomic. Hence, incrementing a volatile variable is not thread-safe and to achieve it, you have to use the synchronized keyword.
To conclude, using volatile is easy and simple as well as unlike locks don't cause a thread to block, so they are less likely to cause scalability issues.
When we talk about locks, 2 main features introduce:
i.) mutual exclusion which means only one thread at a time can hold a given lock, and
ii.) visibility which ensures that changes mode to shared data before releasing the lock are accessible to another thread that subsequently acquires the lock.
Comparing the volatile keyword with synchronized, the volatile is a field modifier while synchronized is used with code blocks and methods.
Let's clear one more point here. Threads can have local copies of variables/data which don't have to be the same as the data held in other threads. In fact, java has an idea of a MAIN memory which holds the current value for variables. And threads can have their own copy of variables which can be different from the main memory. And it's possible that suppose you have a variable named X which value is 1 for thread1 and 2 for thread2 but these values are not distributed to main memory or other threads.
So, using "volatile" does not allow to have a local copy of a variable that is different from the value currently held in main memory. Whenever you access or update the volatile variable in any thread, its value is visible to all other threads immediately.
But when using "synchronized" which firstly obtains and releases locks on monitors can force only one thread a time to execute a code block, if both threads use the same monitor (lock). It also synchronizes memory.
However, the volatile only synchronizes the value of one variable between thread memory and "main" memory, the synchronized synchronizes the value of all variables between thread memory and "main" memory and handles locks (acquire/release) and have more overhead than volatile.
In java, an increment (i.e. ++) and similar operations are not atomic. Hence, incrementing a volatile variable is not thread-safe and to achieve it, you have to use the synchronized keyword.
To conclude, using volatile is easy and simple as well as unlike locks don't cause a thread to block, so they are less likely to cause scalability issues.
Comments
Post a Comment