• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Why does this work ? Boyarsky/Selikoff Exam 1Z0-809 Chapter 7 Q 17

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If one thread is incrementing sheepCount2 and another thread is printing its value, and we don't have appropriate synchronization in place, how can the answer be B ? Surely the answer must be C ?
That said, every time I've executed the code it always prints 100 100.

Can someone explain ?

Thanks,

Michael
 
Bartender
Posts: 5465
212
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Michael,

Welcome to the Ranch and enjoy the stay!

The ExecutorService that is being used in this exercise is a SingleThreadExecutor. As such, it has only one Thread running and so there is no need for synchronization.
 
Michael Farragher
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the response, Piet !

But isn't the thread that does the increment different to the thread that prints out the value ?
 
Marshal
Posts: 79180
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the Ranch

Please provide more details; you can otherwise only understand the question if you have a copy of the book to hand.
 
Piet Souris
Bartender
Posts: 5465
212
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, that is true, the Thread that does the printing is different from the Thread that executes the task. But the print Thread is sleeping for 100 ms and the exercise states that it assumes that that is sufficuent time for the executor to finish the task.

And additionally: there is only one task executed. So, even in the case that the service has more than one Thread, only one Thread will execute the task, so still no need for synchronization.
 
Michael Farragher
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I didn't think that changes made by one thread were visible to other threads unless you had synchronization in place ?

Say we have this class :




This class isn't thread safe.

Say we have an instance of this class and thread A executed the set method with a value of 5, then 5 hours later thread B executed the accessor method, we don't necessarily get to read the 5 that was previously set.

As well as preventing race conditions, I thought synchronization was necessary to allow us to read the most recent writes ?
 
Campbell Ritchie
Marshal
Posts: 79180
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Adding this discussion to our threads forum.

No, that isn't correct. Synchronisation doesn't enable other code to see the most recent update, but to prevent two updates occurring simultaneously. If you have two threads each updating i to 5 or 8, you will have the most recent update visible, but you won't know whether it is 5 or 8. Synchronisation cannot force a particuar update to be the most recent; it simply prevents them interfering with each other. If you are really using a single thread as Piet says, that problem won't occur; there cannot be a race condition, And as Piet also pointed out, if you have a 100ms delay before calling println(), that is > 1000000× longer than the update executon time.
 
Michael Farragher
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for getting back to me, Campbell.

If I can direct you to https://inbravo.github.io/docs/refer/java-concurrency.pdf

If you scroll to Chapter 3, in particular the paragraph under 3.1 Visibility, it says :

In general,there is no guarantee that the reading thread will see a value written by another
thread on a timely basis, or even at all. In order to ensure visibility of memory
writes across threads, you must use synchronization.

Doesn't this clash with what you've just said ?

Thanks



 
Piet Souris
Bartender
Posts: 5465
212
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Michael,

good question. Java is using the 'happens before' principle (or whatever it is called). All that I know is that int writes are atomic and happen before any subsequent reads. I tried to look this up, but I couldn't find it, and the JLS is unreadable about this (section 17.4, if I am correct). Anyway, if in doubt, use the 'volatile' keyword.

But no doubt a specialist will give a better explanation.
 
I've read about this kind of thing at the checkout counter. That's where I met this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic