Hi Elad,
On Fri, 10 May 2019 07:35:02 -0400, Elad Lahav wrote:
> Hello,
>
> In a few places in Chapter 4 it is mentioned that a certain access
> pattern is safe in a single-threaded program.
"thread" in Section 4.3 does not directly match that of pthread.
You might have already noticed, Paul mostly does Linux kernel
programming and his choice of words can be incompatible with
your perspective.
> In many (most?)
> Unix-like operating systems signal handlers in an otherwise
> single-threaded process execute in the context of that single thread.
> Nevertheless the signal handler represents a conceptually separate
> stream of execution that is subject to similar race conditions as
> those that occur in "true" multi-threaded programs. The situation is
> even worse with signal handlers as standard locks typically cannot be
> used to protect the access to shared data.
> It may be worthwhile to mention this pitfall.
FYI, locking and signal handlers are covered in Section 7.1.1.8.
I have no idea if discussion there can satisfy you, though.
>
> Also, a small typo in "Shared-Variable Shenanigans":
>
> --- a/toolsoftrade/toolsoftrade.tex
> +++ b/toolsoftrade/toolsoftrade.tex
> @@ -1550,7 +1550,7 @@ Of course, where practical, the primitives described in
> Section~\ref{sec:toolsoftrade:Atomic Operations (gcc Classic)}
> or (especially)
> Section~\ref{sec:toolsoftrade:Atomic Operations (C11)}
> -should be instead be used to avoid data races, that is, to ensure
> +should instead be used to avoid data races, that is, to ensure
> that if there are multiple concurrent accesses to a given
> variable, all of those accesses are loads.
>
Nice catch! It would be more than welcome if you could contribute in
a properly formatted patch by using "git format-patch".
Thanks, Akira
> --Elad
>
