remzi-arpacidusseau / ostep-code Goto Github PK
View Code? Open in Web Editor NEWCode from various chapters in OSTEP (http://www.ostep.org)
Code from various chapters in OSTEP (http://www.ostep.org)
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 .pdf
s 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 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!
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:
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.
In common_threads.h, why are some of the macros duplicated—e.g. Pthread_mutex_lock
and Mutex_lock
?
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.