The critical section problem

We know exactly which three instructions are dangerous: read, add, write.

Everything else the browser's threads do — drawing pixels, parsing HTML, formatting text — is completely safe to run at the same time.

So the fix is not "stop running threads together". It is "put a fence around those three instructions, and nothing else".

Why & what

The critical section. A critical section is the part of a program that touches a shared resource. For the browser's threads, it is the three instructions that read and update bytes_loaded.

Every thread's code is then structured in four parts:

• Entry section — ask for permission to go in. Wait here if someone else is inside.
• Critical section — touch the shared thing. Exactly one thread at a time.
• Exit section — announce that you are done, so a waiting thread can enter.
• Remainder section — everything else. Any number of threads at once.

Keep the critical section small. Only the instructions that actually touch the shared data belong inside. Every extra line inside the fence is a line where every other thread is blocked, and Aisha feels that as lag.

The three requirements. Any correct solution must give all three. They are asked for by name in interviews.

• Mutual exclusion — if one thread is in its critical section, no other thread may be in its own. This is the obvious one.
• Progress — if nobody is inside and threads are waiting, one of them must be chosen within a bounded time. The decision cannot be postponed forever by threads that are not even trying to enter.
• Bounded waiting — there is a limit on how many times other threads can enter ahead of you. This is the anti-starvation requirement, and it is the same starvation idea from Topic 3.4.

A solution with mutual exclusion but no bounded waiting is still broken. It just fails more slowly, and by starving one thread instead of corrupting data.

Can this be solved in software alone? For two threads, yes. Peterson's solution uses two shared variables — a flag saying "I want in" and a turn variable saying "you go first" — and it satisfies all three requirements without any special hardware. It is worth knowing by name, because it proves the problem is solvable in principle. It is not what real systems use, though: it does not extend cleanly beyond two threads, and modern CPUs reorder memory writes in ways that break it. The practical answer is hardware, which is the next topic.

How it works

1. Identify the shared resource. Here, bytes_loaded on the heap.
2. Find every line that touches it. Those lines, and only those, become the critical section.
3. Wrap them in an entry and an exit section. The entry blocks; the exit releases.
4. Check mutual exclusion. Can two threads be inside at once? If yes, the scheme is wrong.
5. Check progress and bounded waiting. Can a waiting thread be ignored forever? If yes, the scheme is also wrong.

Common confusion

"Bigger critical sections are safer." They are safer against races and worse for everything else. Put the browser's entire page-rendering loop inside one critical section and only one thread ever runs — you have thrown away the reason for having threads at all.

"Progress just means the program keeps running." It has a narrower meaning here. Progress means that a thread sitting in its remainder section — not even interested in the critical section — must not be able to block a thread that does want in.

Interview angle

"What are the three requirements for a critical section solution?" Name them and give one line each. This is close to a definition question and is asked very often.

The follow-up is "which one prevents starvation?" — bounded waiting. Being able to answer that instantly shows you understand the three as separate guarantees rather than as one blurry idea.