Does an object always see its latest internal state irrespective of thread? The 2019 Stack Overflow Developer Survey Results Are InDoes a finally block always get executed in Java?Java: serial thread confinement questionJava difference between fixed threadpool and scheduled threadpoolJackrabbit and concurrent modificationHow to stop a Runnable scheduled for repeated execution after a certain number of executionsMultiple threads accessing inner classHow can a loop be completed by two thread? say loop from count=1 to count=4 by ist thread and count =5 to 8 by 2nd thread?If I keep a reference to a Runnable, when does the Thread it ran on get released?How to stop a schedule ScheduledExecutorServiceHow to implement a singleThreadedScheduledExcecutor in wildfly

Why is it "Tumoren" and not "Tumore"?

How to reverse every other sublist of a list?

Does it makes sense to buy a new cycle to learn riding?

What does Linus Torvalds means when he says that git "never ever" tracks a file?

What do the Banks children have against barley water?

How to change the limits of integration

What do hard-Brexiteers want with respect to the Irish border?

Is domain driven design an anti-SQL pattern?

What does "sndry explns" mean in one of the Hitchhiker's guide books?

Dual Citizen. Exited the US on Italian passport recently

Monty Hall variation

Why don't Unix/Linux systems traverse through directories until they find the required version of a linked library?

In microwave frequencies, do you use a circulator when you need a (near) perfect diode?

Why is the maximum length of openwrt’s root password 8 characters?

What is this 4-propeller plane?

Does light intensity oscillate really fast since it is a wave?

Where does the "burst of radiance" from Holy Weapon originate?

I looked up a future colleague on LinkedIn before I started a job. I told my colleague about it and he seemed surprised. Should I apologize?

Springs with some finite mass

How come people say “Would of”?

Where to refill my bottle in India?

Falsification in Math vs Science

Is it possible for the two major parties in the UK to form a coalition with each other instead of a much smaller party?

Does duplicating a spell with Wish count as casting that spell?



Does an object always see its latest internal state irrespective of thread?



The 2019 Stack Overflow Developer Survey Results Are InDoes a finally block always get executed in Java?Java: serial thread confinement questionJava difference between fixed threadpool and scheduled threadpoolJackrabbit and concurrent modificationHow to stop a Runnable scheduled for repeated execution after a certain number of executionsMultiple threads accessing inner classHow can a loop be completed by two thread? say loop from count=1 to count=4 by ist thread and count =5 to 8 by 2nd thread?If I keep a reference to a Runnable, when does the Thread it ran on get released?How to stop a schedule ScheduledExecutorServiceHow to implement a singleThreadedScheduledExcecutor in wildfly



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








12















Let's say I have a runnable with a simple integer count variable which is incremented every time runnable runs. One instance of this object is submitted to run periodically in a scheduled executor service.



class Counter implements Runnable 
private int count = 0;

@Override
public void run()
count++;



Counter counter = new Counter();
ScheduledExecutorService executorService = Executors.newScheduledThreadPool(5);
executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


Here, the object is accessing its own internal state inside of different threads (reading and incrementing). Is this code thread-safe or is it possible that we lose updates to the count variable when it's scheduled in a different thread?










share|improve this question



















  • 1





    Nope; most definitely not.

    – Boris the Spider
    Apr 5 at 19:36






  • 3





    Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

    – Solomon Slow
    Apr 5 at 19:49


















12















Let's say I have a runnable with a simple integer count variable which is incremented every time runnable runs. One instance of this object is submitted to run periodically in a scheduled executor service.



class Counter implements Runnable 
private int count = 0;

@Override
public void run()
count++;



Counter counter = new Counter();
ScheduledExecutorService executorService = Executors.newScheduledThreadPool(5);
executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


Here, the object is accessing its own internal state inside of different threads (reading and incrementing). Is this code thread-safe or is it possible that we lose updates to the count variable when it's scheduled in a different thread?










share|improve this question



















  • 1





    Nope; most definitely not.

    – Boris the Spider
    Apr 5 at 19:36






  • 3





    Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

    – Solomon Slow
    Apr 5 at 19:49














12












12








12


2






Let's say I have a runnable with a simple integer count variable which is incremented every time runnable runs. One instance of this object is submitted to run periodically in a scheduled executor service.



class Counter implements Runnable 
private int count = 0;

@Override
public void run()
count++;



Counter counter = new Counter();
ScheduledExecutorService executorService = Executors.newScheduledThreadPool(5);
executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


Here, the object is accessing its own internal state inside of different threads (reading and incrementing). Is this code thread-safe or is it possible that we lose updates to the count variable when it's scheduled in a different thread?










share|improve this question
















Let's say I have a runnable with a simple integer count variable which is incremented every time runnable runs. One instance of this object is submitted to run periodically in a scheduled executor service.



class Counter implements Runnable 
private int count = 0;

@Override
public void run()
count++;



Counter counter = new Counter();
ScheduledExecutorService executorService = Executors.newScheduledThreadPool(5);
executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


Here, the object is accessing its own internal state inside of different threads (reading and incrementing). Is this code thread-safe or is it possible that we lose updates to the count variable when it's scheduled in a different thread?







java multithreading concurrency






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 6 at 0:06









Peter Mortensen

13.9k1987113




13.9k1987113










asked Apr 5 at 19:28









RandomQuestionRandomQuestion

3,072144580




3,072144580







  • 1





    Nope; most definitely not.

    – Boris the Spider
    Apr 5 at 19:36






  • 3





    Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

    – Solomon Slow
    Apr 5 at 19:49













  • 1





    Nope; most definitely not.

    – Boris the Spider
    Apr 5 at 19:36






  • 3





    Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

    – Solomon Slow
    Apr 5 at 19:49








1




1





Nope; most definitely not.

– Boris the Spider
Apr 5 at 19:36





Nope; most definitely not.

– Boris the Spider
Apr 5 at 19:36




3




3





Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

– Solomon Slow
Apr 5 at 19:49






Just to be clear: When the answers below say "...no happens-before..." what they're saying is, Suppose count==N. Then along comes worker thread A, which sets count = N+1. Then one whole second later, worker thread B is chosen to call the run() method, and worker thread B looks at count. It is possible at that point for worker thread B to still see count == N.

– Solomon Slow
Apr 5 at 19:49













3 Answers
3






active

oldest

votes


















11














Does an object always see its latest internal state irrespective of thread?



Just to be clear for the purposes of this question and its answers, an object doesn't do anything; it's just memory. Threads are the executing entity. It's misleading to say does an object see whatever. It's the thread that's doing the seeing/reading of object state.



This isn't specified in the javadoc, but



Executors.newScheduledThreadPool(5);


returns a ScheduledThreadPoolExecutor.



Your code is using



executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


The javadoc for ScheduledThreadPoolExecutor#scheduledWithFixedDelay states




Submits a periodic action that becomes enabled first after the given
initial delay, and subsequently with the given delay between the
termination of one execution and the commencement of the next.




The class javadoc further clarifies




Successive executions of a periodic task scheduled via
scheduleAtFixedRate or scheduleWithFixedDelay do not overlap.
While different executions may be performed by different threads, the
effects of prior executions happen-before those of subsequent ones
.




As such, each execution of Counter#run is guaranteed to see the value of count after it's been incremented by the previous execution. For example, the third execution will read a count value of 2 before it performs its increment.



You don't need volatile or any other additional synchronization mechanism for this specific use case.






share|improve this answer

























  • Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

    – RandomQuestion
    Apr 5 at 23:47


















7














No, this code is not thread-safe because there isn't any happens-before relation between increments made in different threads started with ScheduledExecutorService.



To fix it, you need to either mark the variable as volatile or switch to AtomicInteger or AtomicLong.



UPDATE:



As @BoristheSpider mentioned, in general in case of increment/decrement making a variable volatile is not enough since increment/decrement is not atomic itself and calling it from several threads concurrently will cause race conditions and missed updates. However, in this particular case scheduleWithFixedDelay() guarantees (according to Javadoc) that there will be overlapping executions of scheduled task, so volatile will also work in this particular case even with increment.






share|improve this answer

























  • @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

    – Ivan
    Apr 5 at 19:41












  • There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

    – Sotirios Delimanolis
    Apr 5 at 20:43











  • How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

    – Edwin Dalorzo
    Apr 5 at 20:51






  • 1





    @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

    – Ivan
    Apr 5 at 20:54











  • To reiterate, the code they have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    Apr 5 at 21:55


















2














No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count.






share|improve this answer




















  • 1





    Even then it's not thread safe, because ++ isn't atomic.

    – Andy Turner
    Apr 5 at 19:37






  • 1





    @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

    – Yug Singh
    Apr 5 at 19:37






  • 1





    Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

    – RandomQuestion
    Apr 5 at 19:39












  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    Apr 5 at 19:40







  • 1





    @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    Apr 5 at 21:55











Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55542189%2fdoes-an-object-always-see-its-latest-internal-state-irrespective-of-thread%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









11














Does an object always see its latest internal state irrespective of thread?



Just to be clear for the purposes of this question and its answers, an object doesn't do anything; it's just memory. Threads are the executing entity. It's misleading to say does an object see whatever. It's the thread that's doing the seeing/reading of object state.



This isn't specified in the javadoc, but



Executors.newScheduledThreadPool(5);


returns a ScheduledThreadPoolExecutor.



Your code is using



executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


The javadoc for ScheduledThreadPoolExecutor#scheduledWithFixedDelay states




Submits a periodic action that becomes enabled first after the given
initial delay, and subsequently with the given delay between the
termination of one execution and the commencement of the next.




The class javadoc further clarifies




Successive executions of a periodic task scheduled via
scheduleAtFixedRate or scheduleWithFixedDelay do not overlap.
While different executions may be performed by different threads, the
effects of prior executions happen-before those of subsequent ones
.




As such, each execution of Counter#run is guaranteed to see the value of count after it's been incremented by the previous execution. For example, the third execution will read a count value of 2 before it performs its increment.



You don't need volatile or any other additional synchronization mechanism for this specific use case.






share|improve this answer

























  • Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

    – RandomQuestion
    Apr 5 at 23:47















11














Does an object always see its latest internal state irrespective of thread?



Just to be clear for the purposes of this question and its answers, an object doesn't do anything; it's just memory. Threads are the executing entity. It's misleading to say does an object see whatever. It's the thread that's doing the seeing/reading of object state.



This isn't specified in the javadoc, but



Executors.newScheduledThreadPool(5);


returns a ScheduledThreadPoolExecutor.



Your code is using



executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


The javadoc for ScheduledThreadPoolExecutor#scheduledWithFixedDelay states




Submits a periodic action that becomes enabled first after the given
initial delay, and subsequently with the given delay between the
termination of one execution and the commencement of the next.




The class javadoc further clarifies




Successive executions of a periodic task scheduled via
scheduleAtFixedRate or scheduleWithFixedDelay do not overlap.
While different executions may be performed by different threads, the
effects of prior executions happen-before those of subsequent ones
.




As such, each execution of Counter#run is guaranteed to see the value of count after it's been incremented by the previous execution. For example, the third execution will read a count value of 2 before it performs its increment.



You don't need volatile or any other additional synchronization mechanism for this specific use case.






share|improve this answer

























  • Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

    – RandomQuestion
    Apr 5 at 23:47













11












11








11







Does an object always see its latest internal state irrespective of thread?



Just to be clear for the purposes of this question and its answers, an object doesn't do anything; it's just memory. Threads are the executing entity. It's misleading to say does an object see whatever. It's the thread that's doing the seeing/reading of object state.



This isn't specified in the javadoc, but



Executors.newScheduledThreadPool(5);


returns a ScheduledThreadPoolExecutor.



Your code is using



executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


The javadoc for ScheduledThreadPoolExecutor#scheduledWithFixedDelay states




Submits a periodic action that becomes enabled first after the given
initial delay, and subsequently with the given delay between the
termination of one execution and the commencement of the next.




The class javadoc further clarifies




Successive executions of a periodic task scheduled via
scheduleAtFixedRate or scheduleWithFixedDelay do not overlap.
While different executions may be performed by different threads, the
effects of prior executions happen-before those of subsequent ones
.




As such, each execution of Counter#run is guaranteed to see the value of count after it's been incremented by the previous execution. For example, the third execution will read a count value of 2 before it performs its increment.



You don't need volatile or any other additional synchronization mechanism for this specific use case.






share|improve this answer















Does an object always see its latest internal state irrespective of thread?



Just to be clear for the purposes of this question and its answers, an object doesn't do anything; it's just memory. Threads are the executing entity. It's misleading to say does an object see whatever. It's the thread that's doing the seeing/reading of object state.



This isn't specified in the javadoc, but



Executors.newScheduledThreadPool(5);


returns a ScheduledThreadPoolExecutor.



Your code is using



executorService.scheduleWithFixedDelay(counter, 1, 1, TimeUnit.SECONDS);


The javadoc for ScheduledThreadPoolExecutor#scheduledWithFixedDelay states




Submits a periodic action that becomes enabled first after the given
initial delay, and subsequently with the given delay between the
termination of one execution and the commencement of the next.




The class javadoc further clarifies




Successive executions of a periodic task scheduled via
scheduleAtFixedRate or scheduleWithFixedDelay do not overlap.
While different executions may be performed by different threads, the
effects of prior executions happen-before those of subsequent ones
.




As such, each execution of Counter#run is guaranteed to see the value of count after it's been incremented by the previous execution. For example, the third execution will read a count value of 2 before it performs its increment.



You don't need volatile or any other additional synchronization mechanism for this specific use case.







share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 6 at 0:07









Peter Mortensen

13.9k1987113




13.9k1987113










answered Apr 5 at 20:40









Sotirios DelimanolisSotirios Delimanolis

213k41503593




213k41503593












  • Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

    – RandomQuestion
    Apr 5 at 23:47

















  • Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

    – RandomQuestion
    Apr 5 at 23:47
















Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

– RandomQuestion
Apr 5 at 23:47





Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.

– RandomQuestion
Apr 5 at 23:47













7














No, this code is not thread-safe because there isn't any happens-before relation between increments made in different threads started with ScheduledExecutorService.



To fix it, you need to either mark the variable as volatile or switch to AtomicInteger or AtomicLong.



UPDATE:



As @BoristheSpider mentioned, in general in case of increment/decrement making a variable volatile is not enough since increment/decrement is not atomic itself and calling it from several threads concurrently will cause race conditions and missed updates. However, in this particular case scheduleWithFixedDelay() guarantees (according to Javadoc) that there will be overlapping executions of scheduled task, so volatile will also work in this particular case even with increment.






share|improve this answer

























  • @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

    – Ivan
    Apr 5 at 19:41












  • There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

    – Sotirios Delimanolis
    Apr 5 at 20:43











  • How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

    – Edwin Dalorzo
    Apr 5 at 20:51






  • 1





    @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

    – Ivan
    Apr 5 at 20:54











  • To reiterate, the code they have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    Apr 5 at 21:55















7














No, this code is not thread-safe because there isn't any happens-before relation between increments made in different threads started with ScheduledExecutorService.



To fix it, you need to either mark the variable as volatile or switch to AtomicInteger or AtomicLong.



UPDATE:



As @BoristheSpider mentioned, in general in case of increment/decrement making a variable volatile is not enough since increment/decrement is not atomic itself and calling it from several threads concurrently will cause race conditions and missed updates. However, in this particular case scheduleWithFixedDelay() guarantees (according to Javadoc) that there will be overlapping executions of scheduled task, so volatile will also work in this particular case even with increment.






share|improve this answer

























  • @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

    – Ivan
    Apr 5 at 19:41












  • There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

    – Sotirios Delimanolis
    Apr 5 at 20:43











  • How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

    – Edwin Dalorzo
    Apr 5 at 20:51






  • 1





    @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

    – Ivan
    Apr 5 at 20:54











  • To reiterate, the code they have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    Apr 5 at 21:55













7












7








7







No, this code is not thread-safe because there isn't any happens-before relation between increments made in different threads started with ScheduledExecutorService.



To fix it, you need to either mark the variable as volatile or switch to AtomicInteger or AtomicLong.



UPDATE:



As @BoristheSpider mentioned, in general in case of increment/decrement making a variable volatile is not enough since increment/decrement is not atomic itself and calling it from several threads concurrently will cause race conditions and missed updates. However, in this particular case scheduleWithFixedDelay() guarantees (according to Javadoc) that there will be overlapping executions of scheduled task, so volatile will also work in this particular case even with increment.






share|improve this answer















No, this code is not thread-safe because there isn't any happens-before relation between increments made in different threads started with ScheduledExecutorService.



To fix it, you need to either mark the variable as volatile or switch to AtomicInteger or AtomicLong.



UPDATE:



As @BoristheSpider mentioned, in general in case of increment/decrement making a variable volatile is not enough since increment/decrement is not atomic itself and calling it from several threads concurrently will cause race conditions and missed updates. However, in this particular case scheduleWithFixedDelay() guarantees (according to Javadoc) that there will be overlapping executions of scheduled task, so volatile will also work in this particular case even with increment.







share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 6 at 0:12









Peter Mortensen

13.9k1987113




13.9k1987113










answered Apr 5 at 19:37









IvanIvan

5,72411022




5,72411022












  • @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

    – Ivan
    Apr 5 at 19:41












  • There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

    – Sotirios Delimanolis
    Apr 5 at 20:43











  • How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

    – Edwin Dalorzo
    Apr 5 at 20:51






  • 1





    @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

    – Ivan
    Apr 5 at 20:54











  • To reiterate, the code they have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    Apr 5 at 21:55

















  • @BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

    – Ivan
    Apr 5 at 19:41












  • There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

    – Sotirios Delimanolis
    Apr 5 at 20:43











  • How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

    – Edwin Dalorzo
    Apr 5 at 20:51






  • 1





    @EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

    – Ivan
    Apr 5 at 20:54











  • To reiterate, the code they have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    Apr 5 at 21:55
















@BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

– Ivan
Apr 5 at 19:41






@BoristheSpider taking into account how scheduleWithFixedDelay work there will be no overlapped calls to counter++ in that particular scenario. So volatile should be OK.

– Ivan
Apr 5 at 19:41














There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

– Sotirios Delimanolis
Apr 5 at 20:43





There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.

– Sotirios Delimanolis
Apr 5 at 20:43













How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

– Edwin Dalorzo
Apr 5 at 20:51





How come volatile is not enough? The semantics of volatile should hold in every case and it would solve this problem. In the past, the writing of doubles and longs could have been more difficult to do atomically since those occupied more than one 32-bit register. However, as far as I can tell, that should not affect the semantics of volatile. Or am I missing something?

– Edwin Dalorzo
Apr 5 at 20:51




1




1





@EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

– Ivan
Apr 5 at 20:54





@EdwinDalorzo in this particular case volatile is enough. But in general case not because increment is effectively translated into 3 operations: read, add, write and is prone to race condition in multithreaded environment

– Ivan
Apr 5 at 20:54













To reiterate, the code they have posted is thread-safe. This answer is wrong.

– Sotirios Delimanolis
Apr 5 at 21:55





To reiterate, the code they have posted is thread-safe. This answer is wrong.

– Sotirios Delimanolis
Apr 5 at 21:55











2














No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count.






share|improve this answer




















  • 1





    Even then it's not thread safe, because ++ isn't atomic.

    – Andy Turner
    Apr 5 at 19:37






  • 1





    @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

    – Yug Singh
    Apr 5 at 19:37






  • 1





    Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

    – RandomQuestion
    Apr 5 at 19:39












  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    Apr 5 at 19:40







  • 1





    @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    Apr 5 at 21:55















2














No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count.






share|improve this answer




















  • 1





    Even then it's not thread safe, because ++ isn't atomic.

    – Andy Turner
    Apr 5 at 19:37






  • 1





    @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

    – Yug Singh
    Apr 5 at 19:37






  • 1





    Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

    – RandomQuestion
    Apr 5 at 19:39












  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    Apr 5 at 19:40







  • 1





    @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    Apr 5 at 21:55













2












2








2







No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count.






share|improve this answer















No, this code is not thread-safe since there isn't any happens before relation between different threads accessing count.







share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 6 at 0:09









Peter Mortensen

13.9k1987113




13.9k1987113










answered Apr 5 at 19:32









michidmichid

5,54921938




5,54921938







  • 1





    Even then it's not thread safe, because ++ isn't atomic.

    – Andy Turner
    Apr 5 at 19:37






  • 1





    @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

    – Yug Singh
    Apr 5 at 19:37






  • 1





    Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

    – RandomQuestion
    Apr 5 at 19:39












  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    Apr 5 at 19:40







  • 1





    @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    Apr 5 at 21:55












  • 1





    Even then it's not thread safe, because ++ isn't atomic.

    – Andy Turner
    Apr 5 at 19:37






  • 1





    @michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

    – Yug Singh
    Apr 5 at 19:37






  • 1





    Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

    – RandomQuestion
    Apr 5 at 19:39












  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    Apr 5 at 19:40







  • 1





    @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

    – Sotirios Delimanolis
    Apr 5 at 21:55







1




1





Even then it's not thread safe, because ++ isn't atomic.

– Andy Turner
Apr 5 at 19:37





Even then it's not thread safe, because ++ isn't atomic.

– Andy Turner
Apr 5 at 19:37




1




1





@michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

– Yug Singh
Apr 5 at 19:37





@michid please correct me if I am wrong but shouldn't counter++ be synchronized too as increment operation is not atomic.

– Yug Singh
Apr 5 at 19:37




1




1





Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

– RandomQuestion
Apr 5 at 19:39






Does counter++ need to be synchronized even if it's guaranteed that only one thread will be running this runnable at a time (like in the code in the question)?

– RandomQuestion
Apr 5 at 19:39














@RandomQuestion yes. Because visibility.

– Boris the Spider
Apr 5 at 19:40






@RandomQuestion yes. Because visibility.

– Boris the Spider
Apr 5 at 19:40





1




1





@RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

– Sotirios Delimanolis
Apr 5 at 21:55





@RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.

– Sotirios Delimanolis
Apr 5 at 21:55

















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55542189%2fdoes-an-object-always-see-its-latest-internal-state-irrespective-of-thread%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Sum ergo cogito? 1 nng

三茅街道4182Guuntc Dn precexpngmageondP