Win a copy of Classic Computer Science Problems in Swift this week in the iOS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Chapter 7 Q17 - why does this code work differently than they explained  RSS feed

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Code from book:


Ok. Assuming that this works like they said even if i've tried run this code couple of times and i had "90 90" values once.

But back to the merits. They explain correct answer in that way:


B. The code compiles and runs without issue, so D, E, F, and G are incorrect. The key aspect to notice in the code is that a single-thread executor is used, meaning that no task will be executed concurrently. Therefore, the results are valid and predictable with 100 100 being the output, and B is the correct answer. If a pooled thread executor was used with at least two threads, then the sheepCount2++ operations could overwrite each other, making the second value indeterminate at the end of the program. In this case, C would be the cor- rect answer.



I've changed my code to this one:


And i am still gettin the "100 100" values. What am i doing wrong?

I'd really appreciate if you helped me
 
Master Rancher
Posts: 2552
87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In your second code snippet,  let i run from 0 to 100_000, then you will see the numbers diverge.
To be extra sure of the outcome, add service.awaitTermination() at the end of the code, and then do the printout.
 
Seba Doe
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok. Understand.

And what about this situation where had also value - 90?

If thought no matter which scenario i choose (single threaded or fixed thread pool) the AtomicInteger always be 100.
 
Piet Souris
Master Rancher
Posts: 2552
87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, have a look at these two lines in your second code:

It is likely that not all Runnables have been processed at that time. That is why I adviced to put a service.awaitTermination() at the end, bfore printing. Then you know for sure that all Runnables have been processed. So variant 1:

and variant 2:
 
Seba Doe
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your response.

Ok so whats the difference between and
 
Piet Souris
Master Rancher
Posts: 2552
87
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the first case (Thread.sleep(100)), you let the Tread sleep for one tenth of a second. Now, when you only had 100 Runnables, that 100 milliseconds was enough to have 'service' process them all. However, in the case of 100_000 or even 1_000_000 Runnables, this was no longer the case, so that the printout happened before service was finished. The printout thus showed some intermediate values.
In the second case, I let the Thread wait until the service was terminated, in which case we know for sure that all Runnables were completed, no matter how much time that would take. I let it wait for max 5 seconds, so in theory I should have checked after 'awairtTermination' if the service had indeed terminated or that the 5 seconds simply were over.

I hope the difference is clear.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!