The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update
| Version |
Location |
Description |
Submitted by |
Date submitted |
| Other Digital Version |
14
LockedCounterDemo |
In Lecture 14 of Advance Java with Ken Kousens, the object does not work as I believe he intended. He was trying to show that the lock()/unlock() synchronization in the LockCounter class would work like the other two methods he was demo'ing that would provide the proper answer.
Problem is, it is not guaranteed to do that as written -- and he accidentally discovered the bug and passed over it. When he first ran it, it gave the wrong answer, so he immediately re-ran it to get the answer of 1000, which was what the author was trying to show, then immediately moved on.
The reason is that the submission loop "drops out" when the *submissions* are done, then the shutdown() method is called -- possibly before all threads have run! On my machine, I got inconsistent values all in the upper 900's (and, of course, 1000). My laptop is a core i7 4-core with 4 hyper-threads (8 cores).
This is actually an example where one needs "wait" until all threads are complete before calling shutdown(), what we used to call a barrier in C++.
Thanks for a really informative series on the advanced topics in JDK8! I am still working on them.
|
XFactor |
Jan 27, 2017 |
| Other Digital Version |
14
SychronizedLock |
Technically, all the example code in the LocksDemo class have a problem: Once the threads have been spawned, there is no mechanism for synchronizing their COMPLETION to arrive at the desired 1000.
Alternatively, this as a perfect example(s) of how easy it is to get into trouble with threads -- if, and only if, it was the author's desire was to show the 1000 as proof that all the counting completed in a synchronous manner to reach a desired count.
The reason it seems to work "most" of the time is that the counting threads run asynchronously with the spawning, the example is so trivial, the lock/unlock overhead is so high, and so few other processes are running to keep the CPUs busy that the count is reached by the time the spawning loop completes and shutdown() is executed.
|
XFactor |
Jan 27, 2017 |