Does an object always see its latest internal state irrespective of thread?Does a finally block always get...

How old can references or sources in a thesis be?

Paid for article while in US on F-1 visa?

Replacing matching entries in one column of a file by another column from a different file

Theorems that impeded progress

Can a vampire attack twice with their claws using Multiattack?

How to determine what difficulty is right for the game?

What does the "remote control" for a QF-4 look like?

What doth I be?

Malformed Address '10.10.21.08/24', must be X.X.X.X/NN or

What's the output of a record needle playing an out-of-speed record

Was any UN Security Council vote triple-vetoed?

"You are your self first supporter", a more proper way to say it

Cross compiling for RPi - error while loading shared libraries

What does "Puller Prush Person" mean?

What does it mean to describe someone as a butt steak?

Perform and show arithmetic with LuaLaTeX

What typically incentivizes a professor to change jobs to a lower ranking university?

Did Shadowfax go to Valinor?

What would happen to a modern skyscraper if it rains micro blackholes?

Do infinite dimensional systems make sense?

Codimension of non-flat locus

Arrow those variables!

What defenses are there against being summoned by the Gate spell?

Can I make popcorn with any corn?



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


Does 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;
}







8















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

























  • Nope; most definitely not.

    – Boris the Spider
    5 hours ago






  • 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
    5 hours ago




















8















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

























  • Nope; most definitely not.

    – Boris the Spider
    5 hours ago






  • 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
    5 hours ago
















8












8








8


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 46 mins ago









Peter Mortensen

13.9k1987113




13.9k1987113










asked 5 hours ago









RandomQuestionRandomQuestion

3,055144579




3,055144579













  • Nope; most definitely not.

    – Boris the Spider
    5 hours ago






  • 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
    5 hours ago





















  • Nope; most definitely not.

    – Boris the Spider
    5 hours ago






  • 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
    5 hours ago



















Nope; most definitely not.

– Boris the Spider
5 hours ago





Nope; most definitely not.

– Boris the Spider
5 hours ago




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
5 hours ago







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
5 hours ago














3 Answers
3






active

oldest

votes


















3














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
    1 hour ago



















5














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
    5 hours ago













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

    – Sotirios Delimanolis
    4 hours ago











  • 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
    4 hours ago











  • @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
    3 hours ago











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

    – Sotirios Delimanolis
    2 hours ago



















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
    5 hours ago






  • 1





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

    – Yug Singh
    5 hours ago






  • 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
    5 hours ago













  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    5 hours ago








  • 1





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

    – Sotirios Delimanolis
    2 hours ago












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









3














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
    1 hour ago
















3














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
    1 hour ago














3












3








3







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 45 mins ago









Peter Mortensen

13.9k1987113




13.9k1987113










answered 4 hours ago









Sotirios DelimanolisSotirios Delimanolis

213k41500590




213k41500590













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

    – RandomQuestion
    1 hour ago



















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

    – RandomQuestion
    1 hour ago

















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

– RandomQuestion
1 hour ago





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

– RandomQuestion
1 hour ago













5














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
    5 hours ago













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

    – Sotirios Delimanolis
    4 hours ago











  • 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
    4 hours ago











  • @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
    3 hours ago











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

    – Sotirios Delimanolis
    2 hours ago
















5














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
    5 hours ago













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

    – Sotirios Delimanolis
    4 hours ago











  • 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
    4 hours ago











  • @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
    3 hours ago











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

    – Sotirios Delimanolis
    2 hours ago














5












5








5







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 40 mins ago









Peter Mortensen

13.9k1987113




13.9k1987113










answered 5 hours ago









IvanIvan

5,70411022




5,70411022













  • @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
    5 hours ago













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

    – Sotirios Delimanolis
    4 hours ago











  • 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
    4 hours ago











  • @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
    3 hours ago











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

    – Sotirios Delimanolis
    2 hours ago



















  • @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
    5 hours ago













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

    – Sotirios Delimanolis
    4 hours ago











  • 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
    4 hours ago











  • @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
    3 hours ago











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

    – Sotirios Delimanolis
    2 hours ago

















@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
5 hours ago







@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
5 hours ago















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

– Sotirios Delimanolis
4 hours ago





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

– Sotirios Delimanolis
4 hours ago













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
4 hours ago





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
4 hours ago













@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
3 hours ago





@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
3 hours ago













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

– Sotirios Delimanolis
2 hours ago





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

– Sotirios Delimanolis
2 hours ago











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
    5 hours ago






  • 1





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

    – Yug Singh
    5 hours ago






  • 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
    5 hours ago













  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    5 hours ago








  • 1





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

    – Sotirios Delimanolis
    2 hours ago
















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
    5 hours ago






  • 1





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

    – Yug Singh
    5 hours ago






  • 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
    5 hours ago













  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    5 hours ago








  • 1





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

    – Sotirios Delimanolis
    2 hours ago














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 43 mins ago









Peter Mortensen

13.9k1987113




13.9k1987113










answered 5 hours ago









michidmichid

5,54921938




5,54921938








  • 1





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

    – Andy Turner
    5 hours ago






  • 1





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

    – Yug Singh
    5 hours ago






  • 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
    5 hours ago













  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    5 hours ago








  • 1





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

    – Sotirios Delimanolis
    2 hours ago














  • 1





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

    – Andy Turner
    5 hours ago






  • 1





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

    – Yug Singh
    5 hours ago






  • 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
    5 hours ago













  • @RandomQuestion yes. Because visibility.

    – Boris the Spider
    5 hours ago








  • 1





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

    – Sotirios Delimanolis
    2 hours ago








1




1





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

– Andy Turner
5 hours ago





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

– Andy Turner
5 hours ago




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
5 hours ago





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

– Yug Singh
5 hours ago




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
5 hours ago







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
5 hours ago















@RandomQuestion yes. Because visibility.

– Boris the Spider
5 hours ago







@RandomQuestion yes. Because visibility.

– Boris the Spider
5 hours ago






1




1





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

– Sotirios Delimanolis
2 hours ago





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

– Sotirios Delimanolis
2 hours ago


















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

“%fieldName is a required field.”, in Magento2 REST API Call for GET Method Type The Next...

How to change City field to a dropdown in Checkout step Magento 2Magento 2 : How to change UI field(s)...

變成蝙蝠會怎樣? 參考資料 外部連結 导航菜单Thomas Nagel, "What is it like to be a...