On Tue, Jan 27, 2015 at 10:37:22PM +0900, Motohiro Kanda wrote: > Hi, this might sounds too picky, but here are another typos in perfbook. Not at all, thank you for your careful review and feedback! > In Quick Quiz 4.24 on page 46, it says, > Linux-kernel equivalents to fork() and join()? > You mean > fork() and wait()? > Table 4.1 already has pthread join. Good catch, fixed! > In Quick Quiz 5.60 on page 83 it says, > update-side signals over read-side atomic operations > > And in Section 5.6 Parallel Counting Discussion, on page 82, paragraph > starting with > "Figure 5.2 shows", it says > penalty can be reduced by substituting read-side signals for > update-side atomic operations. > > These looks odd, because signal and atomic operations are both on update-side. Good eyes! The "read-side" and "update-side" weren't adding much aside from confusion, so I removed them. In addition, the Quick Quiz answer was using outdated performance results, so I fixed that as well. > add_count in Figure 5.18 has atomic_cmpxchg. > add_count in Figure 5.25 calls flush_local_count, which sends a > signal, wait until ready, and do the thieving. > > So, they should read > update-side signals over atomic operations > and > update-side signals for atomic operations. I will stick with removing the "update-side" as well as the "read-side". ;-) > In section 5.4.1 Atomic Limit Counter Implementation, on page 69 says, > Otherwise, line 11 combines an updated counter > it should read > line 12 Good catch, fixed! > in Quick Quiz 5.43 on page 71, it says, > What prevents concurrent execution of the fastpath of either atomic_add() or > atomic_sub() > > It should read add_count and sub_count. Again, good catch, and again, fixed! > In section 11.7.4 Microbenchmarking, on page 287, it says, > The first and third sources of interference provide conflicting advice > it should read > The first and 4-th sources > > because 4th item suggests reducing the number of iterations. Good eyes, fixed! > In section 15.3 Shaving the Mandelbrot Set, on page 390, in the second > paragraph says, > The to-be-shaven solution is to unconditionally acquire the locks in list order > it should read > in any order > because third approach in the previous paragraph has already mentioned > "list order" and > the trick here is there are N threads and N+1 objects so no threads > will be starved, right? The "list order" is correct here. If we allowed locks to be acquired in any order, deadlock could still result because each thread must acquire up to three locks, namely the predecessor, the element, and the successor. Suppose that Thread A must acquire the locks for elements 1, 2, and 3, and that Thread B must acquire the locks for elements 2, 3, and 4. If the two threads are allowed to acquire the locks in any order, Thread A might acquire 3, then 2, then 1, while Thread B might acquire 2, then, 3, then 4. This could result in deadlock, with thread A holding 3 and acquiring 2 and thread B holding 2 and acquiring 3. > Finally, in section 11.7.1 Benchmarking on page 285, it says > benchmarks serve three major purposes: > and you mention four. > > You might say that the fourth one, "as a marketing tool" should not be > in "major purposes". > Or, you might be playing the "Spanish Inquisition" sketch :-) I guess I was inadvertently playing that sketch. ;-) Fixed! > By the way, Japanese translation of Chapter 2 and 5, including their > quick quiz answers > has been completed.Chapter 9 is 70% done. Nice!!! You are translating the first edition, or some other version? > I am not good at TeX publishing, so they are in plain text now. Your choice on that one. I am not sure how well LaTeX deals with Japanese characters in any case! Thanx, Paul > Regards, > -- > Kanda Motohiro at > https://sites.google.com/site/kandamotohiro/perfbook > -- > To unsubscribe from this list: send the line "unsubscribe perfbook" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe perfbook" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
