Ttyjukl

Was any UN Security Council vote triple-vetoed?

What are these boxed doors outside store fronts in New York?

Why can't I see bouncing of switch on oscilloscope screen?

meaning of に in 本当に?

Important Resources for Dark Age Civilizations?

Which country benefited the most from UN Security Council vetoes?

Revoked SSL certificate

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

Can you really stack all of this on an Opportunity Attack?

Is it unprofessional to ask if a job posting on GlassDoor is real?

Why is consensus so controversial in Britain?

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

Watching something be written to a file live with tail

Do infinite dimensional systems make sense?

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

Client team has low performances and low technical skills: we always fix their work and now they stop collaborate with us. How to solve?

Why "Having chlorophyll without photosynthesis is actually very dangerous" and "like living with a bomb"?

Has there ever been an airliner design involving reducing generator load by installing solar panels?

Can a Cauchy sequence converge for one metric while not converging for another?

Can an x86 CPU running in real mode be considered to be basically an 8086 CPU?

What is the word for reserving something for yourself before others do?

Unable to deploy metadata from Partner Developer scratch org because of extra fields

RSA: Danger of using p to create q

Alternative to sending password over mail?

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

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?

java multithreading concurrency

share|improve this question

edited 21 mins ago

Peter Mortensen

13.9k1987113

asked 4 hours ago

RandomQuestionRandomQuestion

3,055144579

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Nope; most definitely not.
  
  – Boris the Spider
  4 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
  4 hours ago
  
  
  

  
  
  
  

add a comment | 

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?

java multithreading concurrency

share|improve this question

edited 21 mins ago

Peter Mortensen

13.9k1987113

asked 4 hours ago

RandomQuestionRandomQuestion

3,055144579

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Nope; most definitely not.
  
  – Boris the Spider
  4 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
  4 hours ago
  
  
  

  
  
  
  

add a comment | 

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

edited 21 mins ago

Peter Mortensen

13.9k1987113

asked 4 hours ago

RandomQuestionRandomQuestion

3,055144579

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);

share|improve this question

edited 21 mins ago

Peter Mortensen

13.9k1987113

asked 4 hours ago

RandomQuestionRandomQuestion

3,055144579

share|improve this question

edited 21 mins ago

Peter Mortensen

13.9k1987113

asked 4 hours ago

RandomQuestionRandomQuestion

3,055144579

edited 21 mins ago

Peter Mortensen

13.9k1987113

edited 21 mins ago

Peter Mortensen

13.9k1987113

asked 4 hours ago

RandomQuestionRandomQuestion

3,055144579

asked 4 hours ago

RandomQuestionRandomQuestion

3,055144579

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

edited 20 mins ago

Peter Mortensen

13.9k1987113

answered 3 hours ago

Sotirios DelimanolisSotirios Delimanolis

213k41500590

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.
  
  – RandomQuestion
  40 mins ago
  

  
  
  
  

add a comment | 

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

edited 15 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

IvanIvan

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

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.
  
  – Sotirios Delimanolis
  3 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
  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
  

  
  
  
  

add a comment | 

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

edited 18 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

michidmichid

5,54921938

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Even then it's not thread safe, because ++ isn't atomic.
  
  – Andy Turner
  4 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
  4 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
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @RandomQuestion yes. Because visibility.
  
  – Boris the Spider
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.
  
  – Sotirios Delimanolis
  2 hours ago
  

  
  
  
  

 | 
show 2 more comments

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

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

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

Name

Email

Required, but never shown

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

edited 20 mins ago

Peter Mortensen

13.9k1987113

answered 3 hours ago

Sotirios DelimanolisSotirios Delimanolis

213k41500590

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.
  
  – RandomQuestion
  40 mins ago
  

  
  
  
  

add a comment | 

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

edited 20 mins ago

Peter Mortensen

13.9k1987113

answered 3 hours ago

Sotirios DelimanolisSotirios Delimanolis

213k41500590

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thank you for pointing out this happens-before guarantee about ScheduledThreadPoolExecutor.
  
  – RandomQuestion
  40 mins ago
  

  
  
  
  

add a comment | 

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

edited 20 mins ago

Peter Mortensen

13.9k1987113

answered 3 hours ago

Sotirios DelimanolisSotirios Delimanolis

213k41500590

Executors.newScheduledThreadPool(5);

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

share|improve this answer

edited 20 mins ago

Peter Mortensen

13.9k1987113

answered 3 hours ago

Sotirios DelimanolisSotirios Delimanolis

213k41500590

edited 20 mins ago

Peter Mortensen

13.9k1987113

edited 20 mins ago

Peter Mortensen

13.9k1987113

answered 3 hours ago

Sotirios DelimanolisSotirios Delimanolis

213k41500590

answered 3 hours ago

Sotirios DelimanolisSotirios Delimanolis

213k41500590

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

edited 15 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

IvanIvan

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

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.
  
  – Sotirios Delimanolis
  3 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
  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
  

  
  
  
  

add a comment | 

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

edited 15 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

IvanIvan

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

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  There is a happens-before relation introduced between subsequent execution of a task scheduled with scheduleWithFixedDelay.
  
  – Sotirios Delimanolis
  3 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
  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
  

  
  
  
  

add a comment | 

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

edited 15 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

IvanIvan

5,70411022

share|improve this answer

edited 15 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

IvanIvan

5,70411022

edited 15 mins ago

Peter Mortensen

13.9k1987113

edited 15 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

IvanIvan

5,70411022

answered 4 hours ago

IvanIvan

5,70411022

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

edited 18 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

michidmichid

5,54921938

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Even then it's not thread safe, because ++ isn't atomic.
  
  – Andy Turner
  4 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
  4 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
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @RandomQuestion yes. Because visibility.
  
  – Boris the Spider
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.
  
  – Sotirios Delimanolis
  2 hours ago
  

  
  
  
  

 | 
show 2 more comments

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

edited 18 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

michidmichid

5,54921938

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Even then it's not thread safe, because ++ isn't atomic.
  
  – Andy Turner
  4 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
  4 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
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @RandomQuestion yes. Because visibility.
  
  – Boris the Spider
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @RandomQuestion To reiterate, the code you have posted is thread-safe. This answer is wrong.
  
  – Sotirios Delimanolis
  2 hours ago
  

  
  
  
  

 | 
show 2 more comments

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

share|improve this answer

edited 18 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

michidmichid

5,54921938

share|improve this answer

edited 18 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

michidmichid

5,54921938

edited 18 mins ago

Peter Mortensen

13.9k1987113

edited 18 mins ago

Peter Mortensen

13.9k1987113

answered 4 hours ago

michidmichid

5,54921938

answered 4 hours ago

michidmichid

5,54921938