It might be helpful for contributors to see the source code for the website, in case we want to add a night theme, or edit the titles of .pdfs to match the name of the section, for example. The tab titles are all single.dvi for me, at least on my browser, for the sections I've looked at recently.

Also, what are your thoughts on creating a Discussions section in this repository for questions like these?

In common_threads.h, why are some of the macros duplicated—e.g. Pthread_mutex_lock and Mutex_lock?

In this example, assume we wish to access virtual address 15KB,which
should map to physical address 27KB. Our virtual address, in binary
form, thus looks like this: 11 1100 0000 0000 (hex 0x3C00). The hardware
uses the top two bits (11) to designate the segment, but then we are
left with an offset of 3KB. To obtain the correct negative offset, we must
subtract the maximum segment size from 3KB: in this example, a segment
can be 4KB, and thus the correct negative offset is 3KB minus 4KB
which equals -1KB. We simply add the negative offset (-1KB) to the base
(28KB) to arrive at the correct physical address: 27KB. The bounds check
can be calculated by ensuring the absolute value of the negative offset is
less than the segment’s size.

Hello, there! I tried to find the right contact point to report any bugs, typos, and suggestions, and decided to report it to GitHub and email. First trial is always good enough no matter what it is.

What do you think the above possible maximum segment size as 4KB? Shouldn't it be 2KB? I saw the limit as 2KB from 28KB to 26KB for stack in physical memory. If 4KB is still true, I wonder how the segment size was calculated in this example.

Chapter 1 of the book uses the program "thread" (singular), while the code in this repository is in a file called "threads" (plural). I would suggest fixing either here (which seems easier) or in the book to be consistent.

Chapter 1, page 8:

On page 13 of chapter 39 “INTERLUDE: FILES AND DIRECTORIES” the following is said:

One interesting guarantee provided by the rename() call is that it is
(usually) implemented as an atomic call with respect to system crashes;
if the system crashes during the renaming, the file will either be named
the old name or the new name, and no odd in-between state can arise.
Thus, rename() is critical for supporting certain kinds of applications
that require an atomic update to file state.

However, it is usually not crash-safe.

https://danluu.com/deconstruct-files/ (see the “Rename” subsection of “FAQ” section)

This trick doesn't work. People seem to think that this is safe becaus the POSIX spec says that rename is atomic, but that only means rename is atomic with respect to normal operation, that doesn't mean it's atomic on crash. This isn't just a theoretical problem; if we look at mainstream Linux filesystems, most have at least one mode where rename isn't atomic on crash. Rename also isn't guaranteed to execute in program order, as people sometimes expect.

The most mainstream exception where rename is atomic on crash is probably btrfs, but even there, it's a bit subtle -- as noted in Bornholt et al., ASPLOS’16, rename is only atomic on crash when renaming to replace an existing file, not when renaming to create a new file. Also, Mohan et al., OSDI’18 found numerous rename atomicity bugs on btrfs, some quite old and some introduced the same year as the paper, so you want not want to rely on this without extensive testing, even if you're writing btrfs specific code.

The Linux man page on rename(2) has the following to say:

If newpath already exists, it will be atomically replaced, so there is no point at which another process attempting to access newpath will find it missing. However, there will probably be a window in which both oldpath and newpath refer to the file being renamed.

See also the following discussions:

• https://blogs.gnome.org/alexl/2009/03/16/ext4-vs-fsync-my-take/
• https://lwn.net/Articles/323360/
• https://lwn.net/Articles/323287/

In README.md file of folder threads-lock
Original (on line 43):
promtp> gcc -o compare_and_swap compare_and_swap.c -Wall

Corrected:
promtp> gcc -o compare-and-swap compare-and-swap.c -Wall

Somebody can correct it!

I've recently download this repository and if I run gcc -o threads threads.c -Wall I receive this error:

/usr/bin/ld: /tmp/ccJOGU9O.o: in function `main':
threads.c:(.text+0x165): undefined reference to `pthread_create'
/usr/bin/ld: threads.c:(.text+0x1a5): undefined reference to `pthread_create'
/usr/bin/ld: threads.c:(.text+0x1d9): undefined reference to `pthread_join'
/usr/bin/ld: threads.c:(.text+0x20d): undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status

I'm running gcc (Debian 8.3.0-6) 8.3.0 on WSL2 on a Microsoft Windows [Version 10.0.19042.1415]

The code of threads.c is the one you have in the repository, I haven't touched it