My compass is curiosity.https://www.lyt0112.comhttps://www.lyt0112.com/blog/dw_worlds_of_wonder-enhttps://www.lyt0112.com/blog/dw_worlds_of_wonder-enThe plan was just to visit the San Diego Museum of Art, then a glance up while passing the Comic-Con Museum changed the day.Mon, 16 Feb 2026 16:30:00 GMT<p>This day was really fun.</p> <p>The original plan was just to visit the San Diego Museum of Art. The sky was a little gray, the ground was still wet, and everything felt quiet. Then while passing the Comic-Con Museum, there was a glimpse of some very familiar blue boxes, with <code>Doctor Who Worlds of Wonder</code> across them.</p> <p>There had been absolutely no idea this exhibition was here. It was not the reason for the trip, and it was not something checked in advance either. It just appeared out of nowhere while walking by.</p> <p>Getting closer, it turned out to be real.</p> <p>Tickets were about $30 for adults and $20 for students. At the time, signing up on the official site also got a $15 discounted ticket.</p> <h2>That Blue Door</h2> <p>The entrance itself was simple, but once that blue door showed up, the whole place already felt very Doctor Who.</p> <p>The first thing there was the costume wall.</p> <p>Nine, Ten, Eleven, Twelve, Thirteen. For anyone who has been following the show for years, it still feels special. Twelve especially brought back 2014, when Doctor Who first became a real part of everyday life.</p> <h2>Props</h2> <p>Further in were the console and the sonic screwdrivers[^1]. Even got to touch the console once.</p> <p>In the nearby case were some smaller props that do not show up as often, including Twelve's sonic shades[^2] and the little device used in the 2013 50th Anniversary Special[^3].</p> <p>There was also Handles[^4][^5], the old Cyberman head that stayed with Eleven to the very end.</p> <p>After the outfit area, the first thing to see was a row of three spacesuits. The one on the left is River Song's Apollo-style suit from the <code>S06</code> story arc[^6]. The middle one is from <code>S04E08-S04E09</code>[^7][^8], and it immediately brings back <code>Hey, who turned out the lights?</code>. The orange one on the right is that classic Doctor Who spacesuit that appears again and again, including Clara's in <code>S08E07 Kill the Moon</code>[^9].</p> <p>The Weeping Angel on the left is from <code>S03E10</code>[^10], and the fluffy Meep on the right is from the 2023 60th anniversary <code>Special 1</code>[^11].</p> <p>Then came the villain lineup: Daleks[^12], Cybermen[^13], and Sontarans[^14].</p> <p>Up close, the Dalek eyestalk still feels a little intimidating.</p> <p>It was the first time seeing the words on the TARDIS door from this close.</p> <p>There was also the Teller from <code>S08E05 Time Heist</code>[^15], or <code>Brain Soup</code>.</p> <p>Face of Boe / Captain Jack Harkness[^16][^17]. Torchwood is pretty good too[^18].</p> <p>Nearby was the cat nun from <code>S02E01</code>[^19].</p> <p>Silence will fall![^20]</p> <h2>Whiteboard and screening area</h2> <p>Left a quick message on the whiteboard.</p> <p>There was also a screening area nearby. When this visit happened, it was introducing the 2023 60th anniversary <code>Special 1</code>[^11].</p> <p>This timeline wall runs from 1963 to now. Doctor Who has already been going for a very, very long time.</p> <h2>Gift shop</h2> <p>T-shirts, tote bags, Dalek-pattern bags, and so on.</p> <p>Doctor Who novels, comics, and spin-offs.</p> <h2>After leaving</h2> <p>It still was not dark in Balboa Park when leaving the exhibition. The ground was still wet, and the light was slowly starting to come back.</p> <p>Later there was also a walk through the Japanese garden nearby. Daleks and Cybermen first, then water and stones.</p> <p>At the end, there was a sunset after the rain.</p> <p>The best part was this kind of completely unplanned surprise.</p> <hr> <p>[^1]: What is the TARDIS? Doctor Who. https://www.doctorwho.tv/news-and-features/what-is-the-tardis</p> <p>[^2]: Sonic shades. Tardis Wiki. https://tardis.wiki/wiki/Sonic_shades</p> <p>[^3]: The Day of the Doctor. Doctor Who. https://www.doctorwho.tv/stories/the-day-of-the-doctor</p> <p>[^4]: Handles. Tardis Wiki. https://tardis.wiki/wiki/Handles</p> <p>[^5]: The Time of the Doctor. Doctor Who. https://www.doctorwho.tv/stories/the-time-of-the-doctor</p> <p>[^6]: River Song. Tardis Wiki. https://tardis.wiki/wiki/River_Song</p> <p>[^7]: Silence in the Library. Doctor Who. https://www.doctorwho.tv/stories/silence-in-the-library</p> <p>[^8]: Forest of the Dead. Doctor Who. https://www.doctorwho.tv/stories/forest-of-the-dead</p> <p>[^9]: Kill the Moon. Doctor Who. https://www.doctorwho.tv/stories/kill-the-moon</p> <p>[^10]: Blink. Doctor Who. https://www.doctorwho.tv/stories/blink</p> <p>[^11]: The Star Beast. Doctor Who. https://www.doctorwho.tv/stories/the-star-beast</p> <p>[^12]: Daleks. Doctor Who. https://www.doctorwho.tv/characters/daleks</p> <p>[^13]: Cybermen. Doctor Who. https://www.doctorwho.tv/characters/cybermen</p> <p>[^14]: Sontarans. Doctor Who. https://www.doctorwho.tv/characters/sontarans</p> <p>[^15]: Time Heist. Doctor Who. https://www.doctorwho.tv/stories/time-heist</p> <p>[^16]: Face of Boe. Tardis Wiki. https://tardis.wiki/wiki/Face_of_Boe</p> <p>[^17]: Captain Jack Harkness. Tardis Wiki. https://tardis.wiki/wiki/Captain_Jack_Harkness</p> <p>[^18]: Torchwood (TV series). Tardis Wiki. https://tardis.wiki/wiki/Torchwood_(TV_series)</p> <p>[^19]: New Earth. Doctor Who. https://www.doctorwho.tv/stories/new-earth</p> <p>[^20]: The Silence. Doctor Who. https://www.doctorwho.tv/characters/the-silence</p>https://www.lyt0112.com/blog/dw_worlds_of_wonder-zhhttps://www.lyt0112.com/blog/dw_worlds_of_wonder-zh本来只是去圣地亚哥美术馆, 结果路过 Comic-Con Museum 时抬头一看.Mon, 16 Feb 2026 16:30:00 GMT<p>这天真是太有趣了.</p> <p>原计划其实只是去 San Diego Museum of Art 逛逛. 天有点阴, 地上还是湿的, 非常宁静的氛围. 结果路过 Comic-Con Museum, 偶然瞥见了一些熟悉的蓝盒子, 标题是 <code>Doctor Who Worlds of Wonder</code>.</p> <p>之前完全不知道这个展, 不是专门来参观, 也不是提前查好的行程, 非常非常凑巧路过的时候突然看见了.</p> <p>走近之后确认一下居然是真的.</p> <p>票价大概是成人 30 美元, 学生 20 美元. 当时如果在官网注册过活动信息, 还有 15 美元优惠票.</p> <h2>That Blue Door</h2> <p>展览入口很简单, 但是蓝门一出来, 整个环境已经非常 Doctor Who 了.</p> <p>第一眼就是服装墙.</p> <p>九任, 十任, 十一任, 十二任, 十三任. 对追了很多年的人来说, 这种感觉还是很特别. 尤其是十二任那套, 看到的时候想起 2014 年刚开始追剧的那段时间.</p> <h2>道具区</h2> <p>再往里走就是控制台和 sonic screwdrivers[^1]. 还上手摸了一把控制台.</p> <p>旁边展柜的各种出现次数较少的道具, 有十二叔的音速眼镜[^2], 还有五十周年纪念集中用来探查 Zygon Queen Elizabeth 的小道具[^3].</p> <p>还有 <code>The Time of the Doctor</code> 里的 Handles[^4][^5], 陪 11 任走完最后一段的老朋友.</p> <p>经过了 outfit 区域先看到的是三套宇航服. 左边这套是 River Song[^6] 在 <code>S06</code> 故事线里的 Apollo 风宇航服. 中间这套来自图书馆两集 <code>S04E08-S04E09</code>[^7][^8], 一看到就会想起那句 "Hey, who turned out the lights?". 右边这套橙色宇航服则是出现在很多集里的经典宇航服, 比如 Clara 在 <code>S08E07 Kill the Moon</code> 穿过的那一套[^9].</p> <p>左边的 Weeping Angel 来自 <code>S03E10</code>[^10], 右边这只毛茸茸的 Meep 来自 2023 60 周年 <code>Special 1</code>[^11].</p> <p>反派大合集[^12][^13][^14].</p> <p>Dalek 的眼柄近看还是会有一点压迫感.</p> <p>TARDIS 门上的字第一次距离这么近看.</p> <p>还有 <code>S08E05 Time Heist</code> 的 <code>Brain Soup</code>[^15].</p> <p>Face of Boe / Captain Jack Harkness[^16][^17]. Torchwood 还蛮好看的嘞[^18].</p> <p>旁边还有 <code>S02E01</code> 的猫修女[^19].</p> <p>Silence will fall![^20]</p> <h2>留言板和放映区</h2> <p>在白板上到此一游一下.</p> <p>旁边还有放映区, 去的时候正在介绍 2023 60 周年 <code>Special 1</code>[^11].</p> <p>这面时间线墙, 从 1963 年到现在, Doctor Who 已经走了很久很久了.</p> <h2>纪念品区</h2> <p>T 恤, tote bag, Dalek 图案的包等等.</p> <p>DW 的周边小说漫画衍生剧.</p> <h2>之后</h2> <p>离开展馆时, Balboa Park 的天还没有黑. 地面还是湿的, 光线开始慢慢出来.</p> <p>后来又去旁边的日本庭园转了转. 前面看 Dalek 和 Cybermen, 后面看水和石头.</p> <p>最后看到了雨后的晚霞.</p> <p>最喜欢的还是这种完全没计划好的惊喜.</p> <hr> <p>[^1]: What is the TARDIS? Doctor Who. https://www.doctorwho.tv/news-and-features/what-is-the-tardis</p> <p>[^2]: Sonic shades. Tardis Wiki. https://tardis.wiki/wiki/Sonic_shades</p> <p>[^3]: The Day of the Doctor. Doctor Who. https://www.doctorwho.tv/stories/the-day-of-the-doctor</p> <p>[^4]: Handles. Tardis Wiki. https://tardis.wiki/wiki/Handles</p> <p>[^5]: The Time of the Doctor. Doctor Who. https://www.doctorwho.tv/stories/the-time-of-the-doctor</p> <p>[^6]: River Song. Tardis Wiki. https://tardis.wiki/wiki/River_Song</p> <p>[^7]: Silence in the Library. Doctor Who. https://www.doctorwho.tv/stories/silence-in-the-library</p> <p>[^8]: Forest of the Dead. Doctor Who. https://www.doctorwho.tv/stories/forest-of-the-dead</p> <p>[^9]: Kill the Moon. Doctor Who. https://www.doctorwho.tv/stories/kill-the-moon</p> <p>[^10]: Blink. Doctor Who. https://www.doctorwho.tv/stories/blink</p> <p>[^11]: The Star Beast. Doctor Who. https://www.doctorwho.tv/stories/the-star-beast</p> <p>[^12]: Daleks. Doctor Who. https://www.doctorwho.tv/characters/daleks</p> <p>[^13]: Cybermen. Doctor Who. https://www.doctorwho.tv/characters/cybermen</p> <p>[^14]: Sontarans. Doctor Who. https://www.doctorwho.tv/characters/sontarans</p> <p>[^15]: Time Heist. Doctor Who. https://www.doctorwho.tv/stories/time-heist</p> <p>[^16]: Face of Boe. Tardis Wiki. https://tardis.wiki/wiki/Face_of_Boe</p> <p>[^17]: Captain Jack Harkness. Tardis Wiki. https://tardis.wiki/wiki/Captain_Jack_Harkness</p> <p>[^18]: Torchwood (TV series). Tardis Wiki. https://tardis.wiki/wiki/Torchwood_(TV_series)</p> <p>[^19]: New Earth. Doctor Who. https://www.doctorwho.tv/stories/new-earth</p> <p>[^20]: The Silence. Doctor Who. https://www.doctorwho.tv/characters/the-silence</p>https://www.lyt0112.com/blog/real_world_rl-enhttps://www.lyt0112.com/blog/real_world_rl-enHow real-world RL pulls robots out of virtual worlds and lets them learn in the only environment that matters.Mon, 17 Nov 2025 23:00:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gpt-5.2</code></p> <p>This article uses LLM to polish the writing.</p> <p>Physical Intelligence released the technical report for $\pi_{0.6}^*$ [^7]. A key point is that it uses real-world RL on physical robots to improve performance. I had been following real-world RL for a while, so I used this as a chance to review the line of work and sketch a few possible directions.</p> <h2>Background: What is Real-World RL?</h2> <p>For a long time, <code>robots + reinforcement learning</code> almost meant collecting experience inside a physics simulator. We put virtual robots into environments and frameworks such as MuJoCo, Isaac Gym, Isaac Lab, and ManiSkill, let them run day and night, and after hundreds of millions of actions we find a policy that maximizes return. Then we try to use domain randomization, sim-to-real, or residual actions to make up for the dynamics gap between the simulator and the real world. This gap is usually called the <code>Sim2Real Gap</code>, and it becomes more obvious as tasks become more dynamic and longer-horizon.</p> <p>Real-world RL takes a more direct path: let real-robot data carry most of the learning, use simulation only as a rough warm-up (if at all), and improve performance through repeated real interaction. The payoff is that training happens under the deployment dynamics, with no simulator bias.</p> <p>Compared with classic sim-to-real, there are two key differences:</p> <ul> <li>The trajectories for RL come from the real world, so there is no Sim2Real Gap</li> <li>Algorithms and systems must face real-world constraints seriously: hardware breaks, objects get lost, environments are messy, and human patience is limited</li> </ul> <p>This is why DayDreamer [^1] emphasizes from the start: no simulation, no human demonstrations, only online RL on real robots. It takes the Dreamer world model and puts it on real platforms, and shows that a world model can also learn behaviors efficiently in the physical world.</p> <p>Later, A Walk in the Park [^2] lowered the bar even further: no world model, no complex pretraining. As long as you polish a model-free RL algorithm and the controller and engineering details, a Unitree A1 quadruped can learn to walk stably on various outdoor terrains in about 20 minutes of real-world interaction.</p> <p>From these works on, Real-World RL stopped being just a vision and became a technical route that people could discuss seriously.</p> <h2>First Stage: From Learning in Simulation to Learning in Reality</h2> <p>If you only read the titles, it is easy to treat DayDreamer and A Walk in the Park as two separate lines: one from the world-model side, the other from the model-free side. But if you stretch out the timeline, they actually work together to show one thing: doing RL in the real world is not a myth, but an engineering problem that can be solved.</p> <h3>DayDreamer: Not in World, in World Model</h3> <p>In short, DayDreamer moves the Dreamer world model to real robots and tests whether it can still learn. It evaluates on several different platforms: for example, training robots in the real world to navigate, to balance, and to do locomotion control, without relying on simulation or human teleoperation. Data collection and training run online in parallel. [^1]</p> <p>In this setup the world model is important because it gives real-world RL a virtual environment and increases the efficiency of using real data: the robot first learns a policy in the learned world model, which greatly reduces the number of real interactions needed. This makes online RL in the real world feasible for the first time.</p> <p>DayDreamer's main result is proof that online RL with a learned world model is workable on real robots, turning the path from theory into something you can walk.</p> <h3>A Walk in the Park: Algorithm or Engineering?</h3> <p>A year later, A Walk in the Park reported that carefully tuned SAC-style control and low-level controllers let an A1 learn outdoors in ~20 minutes without a world model. The takeaway is that the win came from task/MDP and controller engineering, not a new RL trick, reinforcing that system and controller engineering (not the loss function) is the bottleneck. [^2]</p> <h3>RoboCat: Self-generated Data</h3> <p>In 2023, DeepMind released RoboCat, which takes a different path. It is not a system designed specifically for Real-World RL, but it looks like a kind of rehearsal for real-world RL. [^6]</p> <p>RoboCat builds on a Gato-style vision-based decision Transformer. It trains a generalist agent from demonstration data covering many robots and many tasks, and then runs a self-improvement loop: humans provide 100-1000 demonstrations for a new task, the model is fine-tuned, then it practices about ten thousand times in simulation or in the real world, and the generated data is fed back into the training set to produce a new, stronger version.</p> <p>Although RoboCat does not emphasize online RL as strongly as DayDreamer or A Walk in the Park, it clearly brings out another important idea:</p> <p>A generalist robot policy can keep getting stronger by generating its own data and improving itself.</p> <p>This idea will later become a core theme in $\pi_{0.6}^*$.</p> <h2>Second Stage: From Can Learn to Learns Well</h2> <p>The first stage showed that real-world RL can learn. But when people try to deploy these systems, they care about two other questions:</p> <ul> <li>Can the agent learn in a way that is stable enough, with success rates close to 100%?</li> <li>Can it keep running for a long time, without needing a human to rescue it every half hour?</li> </ul> <p>A series of works between 2023 and 2025 can be seen as systematic answers to these questions.</p> <h3>HIL-SERL: Data + Human Corrections + RL</h3> <p>HIL-SERL (Human-in-the-Loop Sample-Efficient RL) comes from Berkeley RAIL and appeared in Science Robotics 2025. It targets a set of tasks that are much harder than learning to walk: dynamic shaking to pull out a block, precise assembly, dual-arm collaboration, pan tossing for cooking, and other real manipulation tasks. [^3]</p> <p>The training procedure of HIL-SERL is simple but effective: first they collect good and bad trajectories using teleoperation, and train a binary reward model that judges success or failure; then they use a small number of demonstrations to initialize the policy; finally they run online RL on real robots, where humans step in to correct the robot at key moments. RL then improves the policy using this correction data and the learned reward.</p> <p>The results are very direct: on a set of complex manipulation tasks, HIL-SERL can push the success rate of vision-based policies close to 100% in about 1-2.5 hours of interaction, and the final execution speed is even faster than human teleoperation.</p> <p>This work makes two points that strongly influence later research:</p> <ul> <li>Real-world RL should not start from random exploration, but should stand on top of demonstrations</li> <li>Human interventions are not noise; they are the key component that makes RL both safe and efficient</li> </ul> <p>You can view it as an upgrade of what DayDreamer and A Walk in the Park did: from can learn to can learn well, and learn fast.</p> <h3>RL-100: Systematizing the Pipeline</h3> <p>If HIL-SERL is still a method, RL-100 has already grown into an engineering system.</p> <p>RL-100 proposes a three-stage pipeline: first, use imitation learning to inject human experience into a diffusion policy; second, run offline RL with offline policy evaluation (OPE) to obtain conservative policy improvement; finally, run a short period of online RL on real robots to clean up the remaining failure modes. [^4]</p> <p>They validate the system on seven real-robot tasks, including cloth folding, pouring fluids and granular materials, dynamic pushing, dexterous nut tightening, multi-stage orange juicing, and so on. In 900 evaluations they achieve 900/900 successes, and some tasks can run 250 times in a row without failure.</p> <p>Technically, RL-100 and HIL-SERL share the same spirit:</p> <ul> <li>Both rely on demonstrations and offline data to ensure a good starting point</li> <li>All exploration stays within safety boundaries monitored by OPE or humans</li> <li>The role of RL is to fix long-tail failures, not to invent motions from scratch</li> </ul> <p>But RL-100 does one extra important thing: it turns the whole pipeline into a framework that is relatively agnostic to tasks, robot platforms, and sensing modalities. This is a step from paper demo toward a reusable system.</p> <h3>Contact-Rich Sim-to-Real: A Compromise Route</h3> <p>For assembly and tight insertion tasks where contact mechanics are very sensitive, learning entirely in the real world is still too risky. For such settings, work from Tomizuka's group proposes a hybrid idea: learn trajectories and compliance parameters with RL in simulation, then, in the real world, only do online fine-tuning of a small admittance residual. [^5]</p> <p>This style of method may not be as eye-catching as HIL-SERL or RL-100, but it is very practical in industrial scenarios: most of the risk is handled in simulation, and real-world RL only applies a small residual update.</p> <p>You can view it as an important side branch in the second stage: Real-World RL is not always the main actor, but can serve as the final adaptation layer in sim-to-real.</p> <h2>Third Stage: From Task-Specific to General Policies</h2> <p>So far, most work still focuses on letting the robot learn a single task. $\pi_{0.6}^*$ does something slightly counter-intuitive: it changes the object of RL training from a task to a general policy.</p> <h3>A Good-Enough General VLA</h3> <p>Physical Intelligence released $\pi_{0}$ in 2024. This model is essentially a vision-language-action (VLA) foundation model: it uses internet-scale vision-language pretraining plus large-scale robot data to train a model that can zero-shot and few-shot generalize across robots and tasks. [^8]</p> <p>$\pi_{0.5}$ and $\pi_{0.6}$ then increase model size, training data, and architectural capacity, forming a large-policy model that can "basically get the job done" on many household and simple industrial tasks. But, just like all the previous systems we have discussed, it hits the familiar problem: success rates are passable, but still not high enough for real use.</p> <p>This is the background for $\pi_{0.6}^*$.</p> <h3>RL with Experience &#x26; Corrections</h3> <p>The technical report of $\pi_{0.6}^*$ describes a staged recipe: offline pretraining, supervised fine-tuning, and online correction-driven RL. [^7]</p> <p>What is interesting is the shape of the learning signal. In practice, Recap (RL with Experience &#x26; Corrections via Advantage-conditioned Policies) is closer to supervised regression with a preference signal than to classic RL. The value function is trained by regressing to returns on collected trajectories. The policy is trained by regressing to actions in the dataset, but conditioned on advantage, so the model learns to bias toward higher-value choices. The key addition beyond plain imitation is that failures are <strong>no longer just "bad demos" to be discarded</strong>. They become explicit negative labels, so the policy gets told what to avoid. [^9]</p> <p>Concretely, Recap looks like this:</p> <ul> <li>First they run offline RL on $\pi_{0.6}$ to shape action preferences from offline data, i.e. training a value function on the model's own trajectories, regress it to returns, compute an advantage signal that scores actions as better or worse than average, and feed that advantage into the VLA as a condition</li> <li>For each concrete task, they then run a round of supervised / imitation learning fine-tuning from human demonstrations, so the model has a decent starting point</li> <li>Next they deploy the model on real robots and let it run the task by itself. Humans only step in when there are clear mistakes; these corrections are logged as supervision in the failure states</li> </ul> <p>This may sound abstract, but a simpler description is: $\pi_{0.6}^*$ uses interaction to expose real errors, turns those failures into training signal, and then uses advantage-conditioning to spread the fix to nearby situations instead of patching only the exact state you corrected.</p> <p>What about results? The report lists concrete numbers and case studies: on complex tasks like making espresso, assembling cardboard boxes, and folding different types of clothes, Recap doubles the throughput of $\pi_{0.6}^*$ (the number of tasks finished per unit time), and cuts failure rates to half or even less. The team runs robots from 5:30 in the morning to 11:30 at night making coffee, folding 50 unseen garments in a stranger's house, or assembling 59 real boxes on a factory line, without any run ending early because of model errors.</p> <p>If you zoom out on the timeline, it is natural to see $\pi_{0.6}^*$ standing on the shoulders of the previous work:</p> <ul> <li>Like HIL-SERL, it uses the trio of demonstrations + human corrections + RL to solve long-tail failures</li> <li>Like RL-100, it treats RL as a final repair layer that upgrades performance from sometimes wrong to rarely wrong</li> <li>But it also goes further: it is not optimizing a policy for a single task, but fine-tuning a large, general model</li> </ul> <p>At the level of $\pi_{0.6}^*$, Real-World RL changes its role from a skill learning algorithm to a last-mile training tool for a general policy.</p> <h2>Summary and Outlook: Where Might Real-World RL Go Next?</h2> <p>DayDreamer and A Walk in the Park show that real-world RL can learn. HIL-SERL and RL-100 show that it can learn stably and for a long time. $\pi_{0.6}^*$ shows that it can become the last step for training general robot policies.</p> <p>From the point of view of research methodology, Real-World RL has quietly shifted:</p> <ul> <li>From we need new RL algorithms to we need reliable system engineering and training pipelines</li> <li>From letting RL learn one skill in the real world to letting RL fix the corners that a VLA cannot handle in the real world</li> <li>From simulation is the main work and the real world is only for evaluation to real experience is a necessary stage, and simulation is just a warm-up</li> </ul> <p>Looking forward, some promising directions might cluster around:</p> <ul> <li>Larger-scale real-world data: trying robots generate their own training data across many tasks at the same time</li> <li>More automated and cheaper human intervention and safety mechanisms: for example, better semi-automatic correction, batch annotation tools, and more autonomous recovery, instead of requiring an engineer to stand by with an emergency stop</li> <li>More dexterous motion: overcoming the large Sim2Real gap in dexterous manipulation or high-dynamics manipulation, so that Real-World RL can learn in-hand manipulation beyond simple pick-and-place (for example, one-handed Rubik's Cube rotations, or using chopsticks)</li> </ul> <p>From your perspective, if you are doing research or products in robot learning, the most practical value of Real-World RL today may not be inventing an even fancier RL algorithm, but carefully answering two very concrete questions:</p> <ul> <li>Which parts of your system should be handled by demonstrations and offline training, so that the model becomes smart enough to not self-destruct easily?</li> <li>And then, where must RL touch the real world, and learn from real failures and long tails?</li> </ul> <p>$\pi_{0.6}^*$ gives the following answer:</p> <p>Demonstrations and pretraining are responsible for getting the success rate above zero, and Real-World RL is responsible for addressing real-world failure cases and closing the remaining gaps, until the robot can operate reliably in the physical world.</p> <p>That is probably the most attractive part of Real-World RL: it is not meant to replace everything else, but to make the whole robot system work reliably in the real world.</p> <hr> <p>[^1]: DayDreamer: World Models for Physical Robot Learning. CoRL 2022. https://danijar.com/project/daydreamer/ [^2]: Laura Smith et al. A Walk in the Park: Learning to Walk in 20 Minutes With Model Free Reinforcement Learning. RSS Demo Track 2023. https://arxiv.org/abs/2208.07860 [^3]: HIL-SERL: Precise and Dexterous Robotic Manipulation via Human-in-the-Loop Sample-Efficient Robotic Reinforcement Learning. Science Robotics, 2025. https://hil-serl.github.io/ [^4]: Kun Lei et al. RL-100: Performant Robotic Manipulation with Real-World Reinforcement Learning. arXiv:2510.14830, 2025. https://arxiv.org/abs/2510.14830 [^5]: Xiang Zhang et al. Efficient Sim-to-real Transfer of Contact-Rich Manipulation Skills with Online Admittance Residual Learning. CoRL 2023. https://arxiv.org/abs/2310.10509 [^6]: RoboCat: A Self-Improving Generalist Agent for Robotic Manipulation. DeepMind, 2023. https://arxiv.org/abs/2306.11706 [^7]: $\pi_{0.6}^*$: A VLA that Learns from Experience. Physical Intelligence Blog, 2025-11-17. https://www.pi.website/blog/pistar06 [^8]: $\pi_{0}$: A Vision-Language-Action Flow Model for General Robot Control. Physical Intelligence Blog, 2024-10-31. https://www.physicalintelligence.company/blog/pi0 [^9]: Pi 0.6 : 披着Reinforcement Learning 外衣的 Supervised Learning, 2026-01-13. https://mp.weixin.qq.com/s/O7QOFeyjMDlg8Y5xDVbJNA</p>https://www.lyt0112.com/blog/real_world_rl-zhhttps://www.lyt0112.com/blog/real_world_rl-zhHow real-world RL pulls robots out of virtual worlds and makes them to learn in the only environment that counts.Mon, 17 Nov 2025 23:00:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gpt-5.2</code></p> <p>This article uses LLM to polish the writing.</p> <p>今天 Physical Intelligence 发布了 $\pi_{0.6}^*$ 的技术报告 [^7], 其中一个关键点是它在真实机器人上使用了 Real-World RL 来提升性能. 之前也读过一些 Real-World RL 相关的工作, 借此机会调研一下已有的相关工作并总结一下来龙去脉, 以及未来可能的发展方向.</p> <h2>背景: 什么是 Real-World RL?</h2> <p>在很长一段时间里, 机器人 + 强化学习几乎等同于在物理仿真器里刷经验. 我们在 MuJoCo, Isaac Gym, Isaac Lab, ManiSkill 之类的环境/框架里, 让虚拟机器人日夜练习, 在数亿次动作之后找到最大化 return 的 policy, 再想办法用 domain randomization, sim-to-real 或者 residual action 等方法去弥补物理仿真器和现实的动力学差异, 这个差异被称作 <code>Sim2Real Gap</code>, 并且在越动态, 越长的 Task 上越明显.</p> <p>Real-World RL 这个词, 指的是另一条更直接的路: 让真实世界的数据在真实机器人上承担主要的学习责任, 完全不依赖模拟, 或者模拟只是粗略起步, 最终通过现实里的反复交互迭代提升性能. 这是一个很有吸引力的目标, 因为现实世界的分布和动力学才是最终部署环境.</p> <p>它和 sim-to-real 有两个重要区别:</p> <ul> <li>RL Trajectory 的来源是现实, 没有 Sim2Real Gap</li> <li>算法和系统必须严肃面对现实层面的约束: 硬件会坏, 物体会丢, 环境不可控, 人的耐心有限</li> </ul> <p>这也是为什么 DayDreamer [^1] 会刻意强调: 不用模拟, 没有人类示教, 只靠 online RL 训练现实中的机器人, 把 Dreamer 世界模型搬到真实平台上, 证明 world model 在物理世界中也能高效学习行为.</p> <p>而后来的 A Walk in the Park [^2] 又把门槛再往下压了一点: 不用世界模型, 不用复杂预训练, 只要把 Model Free RL 算法和控制器以及工程实现打磨好, 一台 A1 四足机器人就可以在 20 分钟左右的现实交互里学会在多种户外地形上稳定行走.</p> <p>从这些工作开始, Real-World RL 不再只是一个愿景, 而变成了可以被认真讨论的技术路线.</p> <h2>第一阶段: 从在虚拟里学习到在现实里学习</h2> <p>如果只看论文标题, 很容易把 DayDreamer 和 A Walk in the Park 当成两条平行线: 一个是 World Model 派, 一个是 Model Free 派. 但如果把时间线拉长, 它们其实一起完成了同一件事: 证明在现实世界里做 RL 不是神话, 而是可以解决的工程问题.</p> <h3>DayDreamer: Not in World, in World Model</h3> <p>DayDreamer 做的事概括成一下: 把 Dreamer 世界模型整个搬到真实机器人上, 看它能不能学出来. 它在多个不同平台上测试: 例如让机器人在现实中学导航, 学平衡和运动控制, 完全没有依赖模拟或人工示教, 数据收集和训练在线并行进行. [^1]</p> <p>在这里世界模型真正重要的是, 它给现实 RL 提供了一种虚拟的世界, 提高真实数据的应用效率: 机器人先在 learned world model 里学习 policy, 大幅减少真实交互次数, 这使得在现实中做 online RL 第一次变得可行.</p> <p>DayDreamer 的结论很直接: 世界模型配合在线 RL 在真实机器人上可行, 路已经能走.</p> <h3>A Walk in the Park: 算法 OR 工程</h3> <p>一年后, A Walk in the Park 给出了一个精炼结果: 不用世界模型, 只要把 SAC 一类的 model-free 算法与低层控制器打磨到位, A1 在户外 20 分钟左右也能学会走路. 关键信息是: 成功更多来自 MDP/控制/工程细节, 而不是新奇的算法, 难点更多在系统与控制, 而非损失函数.</p> <h3>RoboCat: 自生成数据</h3> <p>2023 年, DeepMind 发布的 RoboCat 走的是另一条路线: 它不是专门为 Real-World RL 设计的系统, 但可以视为现实 RL 的一种预演. [^6]</p> <p>RoboCat 基于 Gato 式的视觉决策 Transformer, 通过汇集多种机器人, 多任务的示教数据训练出一个 generalist agent, 然后进入自我改进循环: 人给 100~1000 条新任务示范, 模型微调后在仿真或现实中自我练习约一万次, 再把生成的数据回灌进训练集, 得到新的, 更强版本.</p> <p>它虽然不像 DayDreamer, A Walk in the Park 那样强调在线 RL, 但它清楚地提出了另一个重要思想:</p> <p>通用机器人策略可以通过自我产生数据与自我改进来变得越来越强.</p> <p>这个思想会在 $\pi_{0.6}^*$ 里被放大成一个核心主题.</p> <h2>第二阶段: 从能学到学得好</h2> <p>第一阶段证明了现实 RL 可以学会, 然而实际部署时, 人们更关心的是另外两个问题:</p> <ul> <li>能不能学得足够稳, 成功率接近 100%?</li> <li>能不能学得足够久, 不要每半小时就需要人来救场?</li> </ul> <p>2023 - 2025 年间的一系列工作, 基本都可以看作是围绕这两个问题的系统化解答.</p> <h3>HIL-SERL: Data + 人类纠正 + RL</h3> <p>HIL-SERL (Human-in-the-Loop Sample-Efficient RL) 出自 Berkeley RAIL, 发表在 2025 年的 Science Robotics. 它面对的是一组比学走路难得多的任务: 动态抖动抽积木, 精密装配, 双臂协同, 颠锅做饭之类的真实 manipulation. [^3]</p> <p>HIL-SERL 的训练流程非常朴素但有效: 先用遥操作采集好坏样本, 训练一个二分类 reward 模型判断是否成功; 再用少量示范初始化策略; 最后在现实中做 online RL, 人类在关键时刻介入纠正, RL 在这些纠正数据和奖励上不断改进策略.</p> <p>实验结果非常直接: 在一系列复杂操作任务上, HIL-SERL 能在大约 1~2.5 小时的交互里, 把视觉策略的成功率推到接近 100%, 并且执行速度还比人类遥操作更快.</p> <p>这篇工作有两个对后续研究影响很大的观点:</p> <ul> <li>现实 RL 不应该从零随机探索, 而应该站在示教的起点上</li> <li>人类的介入不是噪声, 而是让 RL 既安全又高效的关键构件</li> </ul> <p>可以把它看成是 DayDreamer / A Walk in the Park 做的那件事的升级版: 从能学会升级成能学好, 而且学得很快.</p> <h3>RL-100: Systematizing the Pipeline</h3> <p>如果说 HIL-SERL 还是一个方法, RL-100 就已经长成了一个工程系统.</p> <p>RL-100 提出了一个三阶段 pipeline: 先用 imitation learning 把人类经验注入到扩散策略里, 再用带离线策略评估 (OPE) 的离线 RL 做保守的策略改进, 最后用一小段在线 RL 在真实机器人上清除残余的失败模式. [^4]</p> <p>他们在七个真实机器人任务上做了系统验证: 包括布料折叠, 流体/颗粒物倾倒, 动态推杆, 灵巧手拧螺帽, 多阶段榨橙汁等, 最终在 900 次评估里做到了 900/900 成功, 有的任务甚至能连续 250 次不出错.</p> <p>从技术角度看, RL-100 和 HIL-SERL 的精神是一致的:</p> <ul> <li>都依赖示教和离线数据来保证起点不错</li> <li>所有探索都在被 OPE 或人类监控的安全边界内进行</li> <li>RL 的职责是修补长尾失败情况, 而不是从头发明动作</li> </ul> <p>但 RL-100 做了一件非常重要的额外工作: 它把整条链路做成了一个对任务, 机器人平台, 感知模态相对 agnostic 的框架, 这是从论文 demo 迈向可复用系统的一步.</p> <h3>Contact-Rich Sim-to-Real: 折中路线</h3> <p>在装配, 精密插接这种接触力学极其敏感的任务上, 完全在现实里学依然太危险. 针对这类任务, Tomizuka 等人的工作提出了一个混合思路: 在模拟中用 RL 学到轨迹和顺应控制参数, 到了现实世界只在线微调一个小小的 admittance residual. [^5]</p> <p>这类方法不一定像 HIL-SERL, RL-100 那样显眼, 但它们在工业场景里非常实用: 大部分风险在模拟里解决, 现实中的 RL 只做小幅度的残差微调.</p> <p>可以把它视为第二阶段中的一个重要支线: Real-World RL 不一定总是主角, 但可以作为 sim-to-real 的最后一层自适应.</p> <h2>第三阶段: 从任务级 RL 到通用策略</h2> <p>前面所有工作, 多少还是以让机器人学会某个任务为主角. $\pi_{0.6}^*$ 做了一件略微反常识的事: 它把 RL 用来训练的对象, 从某个任务换成了一个通用策略.</p> <h3>足够好的通用 VLA</h3> <p>Physical Intelligence 在 2024 年公开了 $\pi_{0}$, 这个模型本质上是一个 vision-language-action (VLA) 基础模型: 用互联网规模的视觉-语言预训练加上大规模机器人数据, 让一个模型在多机器人, 多任务上具备零样本和小样本泛化能力. [^8]</p> <p>之后的 $\pi_{0.5}$, $\pi_{0.6}$ 继续在模型规模, 训练数据和架构上做增强, 形成了一个在很多家务和简单工业任务上基本能干活的大模型策略. 但和前面提到的所有工作一样, 它也遇到了那个熟悉的问题: 成功率可以过得去, 但离真正可用还差一些.</p> <p>这就是 $\pi_{0.6}^*$ 登场的背景.</p> <h3>RL with Experience &#x26; Corrections</h3> <p>$\pi_{0.6}^*$ 的技术报告里, 描述了一个分阶段的训练流程: 离线预训练, 监督微调, 以及基于纠正信号的在线 RL. [^7]</p> <p>但如果把它拆开看, Recap (RL with Experience &#x26; Corrections via Advantage-conditioned Policies) 更像是带偏好条件的监督回归. Value function 是对回报做回归训练, policy 是对动作做回归训练, 只是把 advantage 当作条件输入, 让模型倾向于更高 value 的选择. 和传统 imitation learning 最大的差别, 是<strong>失败不再被当作噪声丢掉</strong>, 而是被标注成负信号, 变成模型要主动避免的东西. [^9]</p> <p>具体流程可以写成这样:</p> <ul> <li>先用离线 RL 在 $\pi_{0.6}$ 上做一次预训练, 让模型在离线数据上学会区分好动作和坏动作, 方法是让模型基于自己的执行轨迹学习一个 value function, 对 sparse 的 return 做回归, 计算 advantage 信号, 并把这个 advantage 作为条件输入, 让 VLA 学会偏好高 advantage 的行为</li> <li>对于每个具体任务, 再用人类示教做一轮微调, 让模型在这个任务上有个不错的起点</li> <li>然后在真实机器人上放开模型, 让它自己做任务, 人类只在明显错误时介入纠正, 这些纠正会被作为失败状态下的纠正样本, 再重复第一步的 RL 流程</li> </ul> <p>换个角度说, 这里的 RL 负责暴露真实错误, 把失败变成训练信号, advantage-conditioned policy 则让修正从一个具体状态扩展到一类相近情境.</p> <p>结果如何? 报告里给出了一些非常具体的数字和案例: 在制作意式咖啡, 组装纸箱, 折叠各类衣物这些复杂任务上, 引入 Recap 后, $\pi_{0.6}^*$ 的吞吐量 (单位时间内成功完成的任务数) 可以翻倍, 失败率下降到原来的一半甚至更低. 团队让机器人从早上 5:30 到晚上 11:30 一直做咖啡, 或者在陌生家里连续折 50 件没见过的衣服, 或者在真实工厂里装 59 个真正用于包装的纸箱, 都没有因为模型错误而中断.</p> <p>如果把时间线拉远一点, 你会发现 $\pi_{0.6}^*$ 非常自然地站在前面几篇工作的肩膀上:</p> <ul> <li>它和 HIL-SERL 一样, 用示教 + 人类纠正 + RL 的三段式套路解决长尾失败问题</li> <li>它和 RL-100 一样, 把 RL 放在最后的修补层, 只负责把成功率从偶尔错打磨到尽量不错</li> <li>但它又走得更远: 它不是在优化一个具体任务的策略, 而是在优化一个通用的大模型</li> </ul> <p>在 $\pi_{0.6}^*$ 这里, Real-World RL 的角色从技能学习算法变成了通用策略的最后一公里训练工具.</p> <h2>小结与展望: Real-World RL 之后会走向哪里?</h2> <p>把上面的故事压缩成一句话的话, 大概是这样:</p> <p>DayDreamer 和 A Walk in the Park 证明了现实世界 RL 可以学会, HIL-SERL 和 RL-100 证明了它可以学得稳, 学得久, $\pi_{0.6}^*$ 则展示了它可以变成通用机器人策略的最后一步.</p> <p>从研究范式的角度看, Real-World RL 已经完成了几次观念的转变:</p> <ul> <li>从我们需要新的 RL 算法变成我们需要靠谱的系统工程和训练流程</li> <li>从让 RL 在现实中学会一个技能变成让 RL 在现实中修好 VLA 学不到的角落</li> <li>从模拟是主力, 现实只是验证变成现实经验是必经之路, 模拟只是热身</li> </ul> <p>未来比较值得期待的一些方向, 大概会围绕下面几件事展开:</p> <ul> <li>更大规模的真实世界数据: 在大量的 Task 上同时尝试机器人自己产生训练数据</li> <li>更自动化, 更便宜的人类介入和安全机制: 比如更好的半自动纠正, 批量标注工具, 以及更强的自主恢复能力, 而不是依赖工程师随时介入</li> <li>更灵巧的动作: 在 Dexterous Manipulation 或者 High Dynamics Manipulation 这类更复杂的任务上克服传统 Sim2Real 的巨大 SimReal Gap, 让 Real-World RL 学到更复杂的 In-Hand Manipulation, 而不是简单的 Pick and Place 组合, 比如单手拧魔方或用筷子夹取物体</li> </ul> <p>从你的角度, 如果你在做机器人学习相关的研究或产品, Real-World RL 在今天最现实的价值可能不是发明一个更 fancy 的 RL 算法, 而是认真回答两个非常具体的问题:</p> <ul> <li>你的系统里, 哪些部分应该交给示教和离线训练, 让模型先足够聪明, 不太容易自杀</li> <li>然后, 在哪些地方必须让 RL 接触真实世界, 从真正的错误和长尾里学到修正信号</li> </ul> <p>$\pi_{0.6}^*$ 给出的答案是:</p> <p>示教和预训练负责把动作练到成功率不为 0, Real-World RL 则负责在现实世界里覆盖失败场景并逐步缩小剩余 gap, 直到系统可以稳定运行.</p> <hr> <p>[^1]: DayDreamer: World Models for Physical Robot Learning. CoRL 2022. https://danijar.com/project/daydreamer/ [^2]: Laura Smith et al. A Walk in the Park: Learning to Walk in 20 Minutes With Model Free Reinforcement Learning. RSS Demo Track 2023. https://arxiv.org/abs/2208.07860 [^3]: HIL-SERL: Precise and Dexterous Robotic Manipulation via Human-in-the-Loop Sample-Efficient Robotic Reinforcement Learning. Science Robotics, 2025. https://hil-serl.github.io/ [^4]: Kun Lei et al. RL-100: Performant Robotic Manipulation with Real-World Reinforcement Learning. arXiv:2510.14830, 2025. https://arxiv.org/abs/2510.14830 [^5]: Xiang Zhang et al. Efficient Sim-to-real Transfer of Contact-Rich Manipulation Skills with Online Admittance Residual Learning. CoRL 2023. https://arxiv.org/abs/2310.10509 [^6]: RoboCat: A Self-Improving Generalist Agent for Robotic Manipulation. DeepMind, 2023. https://arxiv.org/abs/2306.11706 [^7]: $\pi_{0.6}^*$: A VLA that Learns from Experience. Physical Intelligence Blog, 2025-11-17. https://www.pi.website/blog/pistar06 [^8]: $\pi_{0}$: A Vision-Language-Action Flow Model for General Robot Control. Physical Intelligence Blog, 2024-10-31. https://www.physicalintelligence.company/blog/pi0 [^9]: Pi 0.6 : 披着Reinforcement Learning 外衣的 Supervised Learning, 2026-01-13. https://mp.weixin.qq.com/s/O7QOFeyjMDlg8Y5xDVbJNA</p>https://www.lyt0112.com/blog/retargeting-zhhttps://www.lyt0112.com/blog/retargeting-zhInteraction-aware hand motion retargeting spanning geometry, force, and self-supervision.Mon, 29 Sep 2025 17:13:04 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gpt-5.2</code></p> <p>This article uses LLM to polish the writing.</p> <h2>背景与定义</h2> <p>运动重定向 (Motion Retargeting) 是角色动画/机器人领域的一个概念, 指在把个体的关节状态 qpos 转换成另一个类似的个体的关节状态.</p> <p>具体来说, 在人手上是指把人手或者机械手的动作转移到另一个手, 同时尽量保持对同一物体的操作一致性. 比如给定人手拿起一个木块的动作, 能够通过 retargeting 将动作转移给机械手, 最终让它也拿起这个木块. 所以这项能力是 teleoperation, imitation learning 和数据扩增的关键环节, 因为它让已有的人类示教得以跨本体复用.</p> <p>如果是同样的自由度, 那么最直接的想法是逐关节复制旋转角度, 但当两只手在自由度, 连杆长度和关节约束上不一致时, 这个 naive 方式马上失效, 物体接触的位置也会漂移. 人手动作重定向 (Hand Motion Retargeting) 真正的挑战在于人手与机器人手存在系统性的形态差异, 同时还要面对与物体的复杂接触. 纯几何角度映射难以保留交互语义和任务目标, 于是研究逐渐从几何匹配走向交互感知, 把物体形状, 受力, 触觉和动作意图纳入同一个学习闭环, 并积极采用自监督和无配对数据.</p> <h2>几何重定向</h2> <p>早期路线聚焦于几何一致性: 对齐关键点, 缩放轨迹, 用优化吸收残差. AnyTeleop [^1] 把手腕到指尖的向量误差纳入目标并施加平滑正则, DexH2R [^2] 则缩放人手轨迹后求解非线性优化, 为机器人手输出关节序列. 这条路径提供了直接的几何直觉, 但缺乏对物体语义的建模, 一旦任务或接触面发生变化就容易失稳.</p> <h2>对象形状为条件的重定向</h2> <p>人手面对不同形状的物体时, 关节角度和接触分布会系统性重排. 如果仍然把人手姿态硬映射到机器人手, 接触点会错位, 抓握力会失衡, 姿态也会显得不自然. 因此研究开始把物体几何引入条件, 先对齐物体再推断手部姿态, 以恢复高层的交互直觉.</p> <ul> <li> <p><strong>FunGrasp (2024) [^3]</strong>: 该系统提出了一个三阶段管线, 首先利用单张 RGB-D 图像估计功能性人手姿态, 并通过在物体坐标系中对齐手部链节方向及优化保持精确接触点和人手姿态, 将人类功能性抓握重定向到不同机器人手. 随后结合视觉和触觉的动态强化学习策略, 在保持接触参考的基础上让机器人手适应不同形状和未见物体, 并通过特权学习和系统辨识提升仿真到真实的迁移.</p> </li> <li> <p><strong>DexFlow (2025) [^4]</strong>: 该方法构建了一个分层优化管线, 先进行全局姿态搜索匹配人手与机器人手, 再在局部阶段用能量函数优化接触, 使机器人手自然贴合物体表面. 同时通过双阈值检测与时间平滑的时序接触处理流程提取稳定接触, 并发布包含 29.2 万个抓取帧的跨手拓扑数据集支持这一流程.</p> </li> <li> <p><strong>Kinematic Motion Retargeting for Contact-Rich Manipulations (2024) [^5]</strong>: 该工作将重定向视为非等距形状匹配问题, 利用表面接触区域与标记点数据, 通过逆运动学逐步估计并优化目标手轨迹. 其核心贡献是局部形状匹配算法和多阶段优化管线, 可在整个操作序列中保持接触分布一致, 并支持对象替换与跨手泛化.</p> </li> <li> <p><strong>Learning Cross-hand Policies of High-DOF Reaching and Grasping (2024) [^6]</strong>: 作者提出手形无关的状态-动作表示和二阶段框架, 先用统一策略预测抓取关键点位移, 再由手型特定的适配器转化为各手的关节控制, 从而实现高自由度抓取策略的跨手迁移. 策略输入由语义关键点和交互中垂面 (IBS) 组成, 借助 Transformer 网络学习手指间关系, 从而对不同手型和物体组合具备泛化能力.</p> </li> </ul> <h2>受力为条件的重定向</h2> <p>在实际操作中, 力分布决定抓握是否稳定; 即便物体形状相同, 不同受力模式也需要不同的目标姿态, 所以受力必须作为显式条件.</p> <ul> <li><strong>Feel the Force: Contact-Driven Learning from Humans (2025) [^7]</strong>: 使用带触觉传感器的手套记录人手接触力与关键点坐标, 预测机器人轨迹和期望抓握力, 执行时以 PD 控制调整夹爪以贴合触觉示范, 但 pipeline 中夹杂了大量手工设置, 可迁移性有限.</li> <li><strong>DexMachina (2025) [^8]</strong>: 强化学习阶段引入强度衰减的虚拟物体控制器, 叠加接触奖励和任务奖励, 但是这其实应该被认为是 RL Tracking 而不是 Retargeting.</li> </ul> <h2>Cross-embodiment 与自监督学习</h2> <p>这一方向试图摆脱人工配对数据, 直接从动作准则中学习跨手映射.</p> <ul> <li><strong>Geometric Retargeting (2025) [^12]</strong>: 以指尖速度一致性等动作准则作为自监督信号, 学习跨本体的无配对映射, 即便在尺度与关节差异下仍维持接触语义与运动稳定性, 并已作为几何先验集成进 Dexterity Gen [^13].</li> <li><strong>Learning to Transfer Human Hand Skills for Robot Manipulations (2025) [^10]</strong>: 拟合人手, 机器人动作与物体运动的共享流形, 利用合成配对三元组训练模型, 避免真实人机配对数据的高昂成本.</li> </ul> <h2>结论</h2> <p>几何映射难以覆盖复杂物体交互与任务约束, 因此近年来的工作都在利用视觉和触觉线索来追求更自然的接触以及更强的泛化. 然而, 除去简单的 pick and place, 多数任务仍难以可靠迁移. 直觉上, 缺口主要在两点: 对物体的理解与对受力的一致性. 其一, 面对不同形状或功能的物体, 即使人手的动作相同, 期望的机器人关节配置并不相同, 因此需要以物体几何或功能为条件; 其二, 即便是同一物体, 不同的人手力分布也应映射到不同的机器人 target qpos, 因此需要以接触力或目标力为条件.</p> <p>从另一条路径看, 若未来的强化学习学得足够 dexterous 的原生策略, 只需把人手动作作为额外的输入进行对齐就能端到端完成 retargeting. 但是以当下的能力而言, 这样的控制器尚未出现. 因此, 以物体与受力为条件的交互感知重定向仍是最务实且可扩展的路线.</p> <hr> <p>[^1]: AnyTeleop: A General Vision-Based Dexterous Robot Arm-Hand Teleoperation System. https://arxiv.org/abs/2307.04577v3 [^2]: DexH2R. https://arxiv.org/abs/2411.04428.pdf [^3]: FunGrasp: Functional Grasping for Diverse Dexterous Hands. https://arxiv.org/abs/2411.16755v1 [^4]: DexFlow: A Unified Approach for Dexterous Hand Pose Retargeting and Interaction. https://arxiv.org/abs/2505.01083v1 [^5]: Kinematic Motion Retargeting for Contact-Rich Anthropomorphic Manipulations. https://arxiv.org/abs/2402.04820.pdf [^6]: Learning Cross-hand Policies of High-DOF Reaching and Grasping. https://arxiv.org/abs/2404.09150 [^7]: Feel the Force: Contact-Driven Learning from Humans. https://arxiv.org/abs/2506.01944.pdf [^8]: DexMachina. https://arxiv.org/abs/2505.24853.pdf [^9]: ManipTrans: Efficient Dexterous Bimanual Manipulation Transfer via Residual Learning. https://arxiv.org/abs/2503.21860 [^10]: Learning to Transfer Human Hand Skills for Robot Manipulations. https://arxiv.org/abs/2501.04169v1 [^11]: Cross-Embodiment Dexterous Grasping with Reinforcement Learning. https://arxiv.org/abs/2410.02479v1 [^12]: Geometric Retargeting. https://arxiv.org/abs/2503.07541 [^13]: Dexterity Gen. https://zhaohengyin.github.io/dexteritygen/</p>https://www.lyt0112.com/blog/retargeting-enhttps://www.lyt0112.com/blog/retargeting-enInteraction-aware hand motion retargeting spanning geometry, force, and self-supervision.Mon, 29 Sep 2025 17:13:03 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gpt-5.2</code></p> <p>This article uses LLM to polish the writing.</p> <h2>Background and Definition</h2> <p>Motion Retargeting is a concept in character animation and robotics that refers to converting one individual's joint state (qpos) to another similar individual's joint state.</p> <p>For hands, it means transferring the motion of a human hand or robotic hand to another hand while maintaining the ability to manipulate the same objects consistently. For example, given a human hand motion of picking up a block, retargeting can transfer this motion to a robotic hand, ultimately enabling it to pick up the same block. This capability is a key hub for teleoperation, imitation learning, and data augmentation, because it allows existing human demonstrations to be reused across embodiments.</p> <p>If the degrees of freedom are identical, the most straightforward idea is to copy joint rotation angles one by one. When two hands differ in degrees of freedom, link lengths, or joint constraints, this naive approach fails and the contact positions drift. The real challenge of hand motion retargeting lies in the systematic morphological differences between human and robot hands, combined with complex contacts with objects. Pure geometric mappings struggle to preserve interaction semantics and task objectives, so research has gradually shifted from geometric matching to interaction-aware methods that bring object shape, force, touch, and action intent into the learning loop, often via self-supervision and unpaired data.</p> <h2>Geometric Retargeting</h2> <p>Early approaches focused on geometric consistency: align keypoints, scale trajectories, and absorb residuals via optimization. AnyTeleop [^1] includes the vector error from wrist to fingertip in the objective and applies smooth regularization. DexH2R [^2] scales human-hand trajectories and then solves a nonlinear optimization to produce a joint sequence for the robot hand. This path provides straightforward geometric intuition but lacks modeling of object semantics, so it often becomes unstable when the task or contact surface changes.</p> <h2>Object-conditioned Retargeting</h2> <p>When the hand interacts with objects of different shapes, joint angles and contact distributions rearrange systematically. If we continue to hard-map human poses to a robot hand, contact points will misalign, grip forces will become unbalanced, and the resulting pose will look unnatural. Consequently, recent work conditions on object geometry: first align the object, then infer the hand pose to recover high-level interaction intent.</p> <ul> <li><strong>FunGrasp (2024) [^3]</strong>: Proposes a three-stage pipeline. It first estimates a functional human-hand pose from a single RGB-D image. In the object frame, it aligns hand link directions and optimizes to preserve precise contact points and human-hand pose, retargeting functional grasps to different robot hands. It then trains a vision-and-touch DRL policy that adapts the robot hand to different shapes and unseen objects while respecting contact references, and improves sim-to-real transfer via privileged learning and system identification.</li> <li><strong>DexFlow (2025) [^4]</strong>: Builds a hierarchical optimization pipeline. It performs a global pose search to match human and robot hands, then locally optimizes contacts with an energy function so the robot hand naturally conforms to the object surface. It also extracts stable contacts via dual-threshold detection with temporal smoothing, and releases a cross-hand-topology dataset containing 292k grasp frames to support this pipeline.</li> <li><strong>Kinematic Motion Retargeting for Contact-Rich Manipulations (2024) [^5]</strong>: Treats retargeting as a non-isometric shape matching problem. Using surface contact regions and marker data, it incrementally estimates and optimizes target-hand trajectories via inverse kinematics. The core contributions are a local shape-matching algorithm and a multi-stage optimization pipeline that maintains consistent contact distributions over full manipulation sequences, and supports object replacement and cross-hand generalization.</li> <li><strong>Learning Cross-hand Policies of High-DOF Reaching and Grasping (2024) [^6]</strong>: Proposes a hand-shape-agnostic state-action representation and a two-stage framework. A unified policy predicts displacements of grasp keypoints, then hand-specific adapters convert them to each hand's joint controls, enabling cross-hand transfer of high-DOF grasping. Inputs are semantic keypoints and the interaction bisector surface (IBS); a Transformer learns relations among fingers, yielding generalization over different hands and objects.</li> </ul> <h2>Force-conditioned Retargeting</h2> <p>In practice, force placement decides grasp stability; even with the same object, different force profiles demand different target poses, so force must be an explicit condition.</p> <ul> <li><strong>Feel the Force: Contact-Driven Learning from Humans (2025) [^7]</strong>: Uses a tactile glove to record human contact forces and keypoint coordinates, predicts robot trajectories and desired grasp forces, and at execution time adjusts the gripper with PD control to track tactile demonstrations. However, the pipeline involves many hand-tuned components and has limited transferability.</li> <li><strong>DexMachina (2025) [^8]</strong>: Introduces a fading virtual-object controller during RL and adds contact and task rewards, but this should be considered RL tracking rather than true retargeting.</li> </ul> <h2>Cross-embodiment and Self-supervision</h2> <p>This direction aims to avoid manually paired data and to learn cross-hand mappings directly from action principles.</p> <ul> <li><strong>Geometric Retargeting (2025) [^12]</strong>: Uses action principles such as fingertip-velocity consistency as self-supervised signals to learn unpaired, cross-embodiment mappings that preserve contact semantics and motion stability despite scale and joint differences, and has been integrated as a geometric prior into Dexterity Gen [^13].</li> <li><strong>Learning to Transfer Human Hand Skills for Robot Manipulations (2025) [^10]</strong>: Fits a shared manifold of human-hand motion, robot actions, and object motion; trains on synthetic paired triplets to avoid the high cost of real human-robot pairs.</li> </ul> <h2>Conclusions</h2> <p>Purely geometric retargeting cannot cover complex object interactions and task constraints, so recent work leverages visual and tactile cues to pursue more natural contacts and stronger generalization. Yet, beyond simple pick-and-place, most tasks still fail to transfer reliably. In practice, the main gaps are twofold: understanding objects and achieving force consistency. First, for objects with different shapes or functions, even identical human motions should map to different robot joint configurations; therefore conditioning on object geometry or functionality is required. Second, even for the same object, different human force distributions should map to different robot target qpos; therefore conditioning on contact or target forces is necessary.</p> <p>From another angle, if future reinforcement learning yields sufficiently dexterous native policies, we could complete retargeting end-to-end by aligning human motion as an additional input. At present, such controllers do not exist. Thus, interaction-aware retargeting conditioned on objects and forces remains the most pragmatic and scalable path.</p> <hr> <p>[^1]: AnyTeleop: A General Vision-Based Dexterous Robot Arm-Hand Teleoperation System. https://arxiv.org/abs/2307.04577v3 [^2]: DexH2R. https://arxiv.org/abs/2411.04428.pdf [^3]: FunGrasp: Functional Grasping for Diverse Dexterous Hands. https://arxiv.org/abs/2411.16755v1 [^4]: DexFlow: A Unified Approach for Dexterous Hand Pose Retargeting and Interaction. https://arxiv.org/abs/2505.01083v1 [^5]: Kinematic Motion Retargeting for Contact-Rich Anthropomorphic Manipulations. https://arxiv.org/abs/2402.04820.pdf [^6]: Learning Cross-hand Policies of High-DOF Reaching and Grasping. https://arxiv.org/abs/2404.09150 [^7]: Feel the Force: Contact-Driven Learning from Humans. https://arxiv.org/abs/2506.01944.pdf [^8]: DexMachina. https://arxiv.org/abs/2505.24853.pdf [^9]: ManipTrans: Efficient Dexterous Bimanual Manipulation Transfer via Residual Learning. https://arxiv.org/abs/2503.21860 [^10]: Learning to Transfer Human Hand Skills for Robot Manipulations. https://arxiv.org/abs/2501.04169v1 [^11]: Cross-Embodiment Dexterous Grasping with Reinforcement Learning. https://arxiv.org/abs/2410.02479v1 [^12]: Geometric Retargeting. https://arxiv.org/abs/2503.07541 [^13]: Dexterity Gen. https://zhaohengyin.github.io/dexteritygen/</p>https://www.lyt0112.com/blog/this_is_pku-zhhttps://www.lyt0112.com/blog/this_is_pku-zh欲买桂花同载酒，终不似，少年游。Thu, 03 Jul 2025 02:58:21 GMT<h2>燕园未竟书</h2> <p>作为本科生在燕园的最后一个白日，竟与四年前踏入此地的那个清晨，有着相似的温度。只是彼时的凉爽里浸润着对未来的迷茫热望，此刻的暑气中却弥漫着一丝曲终人散的惘然。</p> <p>此刻七月三日深夜提笔时，才发觉曾经汹涌的万语千言，此刻都已碎成沙。毕业，原来不是一场盛大的落幕，而是一次无声的离席。我没能为这四年找到一个足够定义自己的标签，它像一部还没来得及起书名的手稿，在对生活意义的寻寻觅觅中，便仓促地迎来了终章。</p> <p>四年很长，长到足够我吃下几千块钱的勺园黄焖鸡；四年也很短，短到我还没来得及尝遍家园与学一之外的早餐，没来得及去老馆的旧时光里坐上一坐，然后在自习的间隙睡上一觉。我总以为来日方长，却被时间悄悄地甩在了身后。这些未竟的小事，像书页里忘记折角的遗憾，最终都成了故事的一部分，提醒我，人生本就是一场充满留白的旅行。</p> <p>入学那天，我在邱德拔那条曲折的坡道前遇见两位学长，一句"欢迎来到北大"，轻描淡写，却成为我与这座园子最初的约定。坡道蜿蜒而上，正如我这四年虽曲折却不断向前的旅程。我在入学前曾用不容置疑的声音告诉自己，要坦然接受自己的普通，也要学会与期待和解，我努力选择倾听内心真正的声音，但是终究被绩点裹挟内耗。燕园很大，大到可以包容无数种梦想，绩点只是其中一种，但绝不是唯一的衡量。生命的价值，绝不应只用一份成绩单来定义。更重要的是，找到那件能让你眼里闪光、能让你被世界听见、被世界需要的事——让自己的声音被世界感知，让自己的努力回应世界的渴望，这远比在一条拥挤的赛道上身心俱疲更有意义。</p> <p>作为一个小小的尝试，从大二起，我开始整理我的<a href="https://www.lyt0112.com/blog/course_review-zh">课程资料</a>。我并非想立一座不朽的丰碑，只是想在身后留下一串脚印，为后来者点一盏小小的灯。如果有人能因此少走一段弯路，多看一程风景，那便是我能想到的，最浪漫的告别。或许终有一天，我会从所有人的记忆里淡出，但若曾有某位同学，在某个深夜，对着屏幕上的资料，轻声念出标题，那一刻，我的青春便与他同在，我的思考便在这座园子里，获得了永恒。这份坚持，也离不开挚友 <a href="https://arthals.ink">Arthals 同学</a> 的启发，是他让我看到，知识的分享本身，就是一种创造。</p> <p>告别的时刻终将到来。我们转身，将燕园的四季与晨昏装进行囊，走向一个没有围墙的远方。我们中的大多数人，都将从宏大的叙事中淡出，在日复一日里，活成一个面目模糊却无比真实的普通人。</p> <p>但这并非故事的结尾。请记得那个曾在四十五乙楼仰望星空的少年，请守护好那份与世界交手时，不与世俗和解的倔强。那才是我们行囊里最宝贵的财富。它会在未来的风雨里提醒我们：即便走在平凡的路上，也要走出属于自己的回响。</p> <h2>后记</h2> <p>命运似乎总爱在不经意处埋下伏笔。作为信息科学技术学院最早报到的学生之一，当年那个最早踏入四十五乙楼的我，在时光流转中送走了一任又一任的楼长之后，竟阴差阳错地递补接过了三、四楼微信群主的"权柄"。这件略带荒诞色彩的小事，成了一段意想不到的插曲，或许也是时光以一种奇特的方式，为我四年前那个启程的清晨，留下的一枚最特别的印记。</p> <p>如果你恰好看到并用到了我的<a href="https://www.lyt0112.com/blog/course_review-zh">课程资料</a>，特别欢迎你在那个页面下方留下一个评论，让我知道这份微小的努力曾经被你看见。</p> <p>树洞 #7427133, #7393484, #7309965, #7285599, #7113770 的作者是我。</p> <p>树洞 #5836142 的作者是 <a href="https://arthals.ink">Arthals 同学</a>，他是一个非常好的 ICS 助教。</p>https://www.lyt0112.com/blog/this_is_pku-enhttps://www.lyt0112.com/blog/this_is_pku-enSo we beat on, boats against the current, borne back ceaselessly into the past.Thu, 03 Jul 2025 02:58:20 GMT<h2>An Unfinished Story</h2> <p>My last day as an undergraduate at Peking University felt just like the morning I first arrived four years ago. The air then was cool and filled with a vague but passionate hope for the future; today, the warmth is tinged with the sadness of parting.</p> <p>As I start to write, I realize the torrent of thoughts that once surged within me has crumbled into fragments. Graduation, it turns out, isn't a grand finale but a quiet exit. I never found a single label for these four years. They feel like an untitled manuscript, a hurried ending to a quest for meaning that was just beginning.</p> <p>Four years was long enough to eat my weight in braised chicken from the Shaoyuan canteen. Yet, it was short enough that I never managed to try breakfast anywhere but the Jiayuan and Xueyi canteens, or find time to just sit in the old library and nap between study sessions. I always thought I had all the time in the world, only to watch it slip away. These small, unfinished tasks, like un-dog-eared pages in a book, have become part of the story, reminding me that life is a journey with its share of blank spaces.</p> <p>On my first day, I met two upperclassmen on the winding path in front of the Qiu Deba Sports Hall. Their simple "Welcome to PKU" became my first real connection to this campus. The path sloped upwards, much like my own winding but ever-forward journey. Before I even started, I told myself to accept my own ordinariness and make peace with my expectations. I tried to listen to my inner voice, but was ultimately consumed by the pressure of my GPA. Peking University is vast enough to hold countless dreams; grades are just one measure of success, and by no means the only one. A person's worth should never be defined by a transcript. What matters more is finding what makes your eyes light up, what allows your voice to be heard and your presence to be felt. Making your voice heard and your efforts count is far more meaningful than exhausting yourself on a crowded track.</p> <p>As a small experiment in my sophomore year, I began organizing my <a href="https://www.lyt0112.com/blog/course_review-zh">course materials</a>. I wasn't trying to build a monument, just leave a trail of footprints—a small light for those who would come after me. If it helped someone avoid a few detours on their own path, that would be the best farewell I could imagine. Maybe one day I'll fade from everyone's memory. But if, late one night, a student looks at my notes and softly reads the title, in that moment, my youth will be with them. My thoughts will have found a small piece of eternity on this campus. This endeavor was also inspired by my dear friend <a href="https://arthals.ink">Arthals</a>, who showed me that sharing knowledge is an act of creation in itself.</p> <p>The time to say goodbye has come. We turn, packing the seasons of Peking University into our bags, and head toward a future without walls. Most of us will fade from the grand narratives and become ordinary people, our faces perhaps indistinct in a crowd, but our lives incredibly real.</p> <p>But this isn't the end of the story. Remember the young man who once gazed at the stars from Building 45B. Hold on to that stubborn refusal to compromise with the world. That is the most precious treasure in our bags. It will remind us in the storms to come that even on an ordinary path, we must create our own echo.</p> <h2>Epilogue</h2> <p>Destiny, it seems, has a habit of leaving clues where you least expect them. As one of the first students from the School of Information Science and Technology to check in, I was the first to step into Building 45B. After watching several floor managers come and go, by a strange twist of fate, I inherited the "mantle" of being the WeChat group admin for the third and fourth floors. This absurd little detail became an unexpected chapter in my story—perhaps time's own quirky way of commemorating that first morning my journey began.</p>https://www.lyt0112.com/blog/blindfold-zhhttps://www.lyt0112.com/blog/blindfold-zh三阶魔方彳亍法盲拧逻辑详解以及一套更符合直觉, 更易于记忆的三阶魔方盲拧编码方案. Mon, 30 Jun 2025 00:13:04 GMT<p>import { Aside } from '@/components/user'</p> <h2>前言</h2> <p>盲拧, 作为一项复原手段, 与我们熟知的速拧有着本质的不同. 速拧依赖于观察魔方状态的实时反馈, 是一个"闭环控制"过程; 而盲拧则是在蒙上双眼后, 仅凭记忆执行一系列操作, 是一个"开环控制"过程. 这两个系统虽然逻辑迥异, 但在一些技巧上却有共通之处.</p> <p>盲拧入门最大的挑战之一, 就是如何将魔方的状态编码并牢记. 目前流行的"彳亍法"<a href="%5B%E4%B8%89%E5%BE%AA%E7%8E%AF%E5%90%8C%E6%97%B6%E8%A7%A3%E5%86%B3%E4%BD%8D%E7%BD%AE%E5%92%8C%E6%96%B9%E5%90%91%EF%BC%88%E6%80%9D%E8%B7%AF%EF%BC%89%E2%80%94%E2%80%94%E5%BD%B3%E4%BA%8D%5D(http://www.mf8-china.com/forum.php?mod=viewthread&#x26;tid=2101)">^8</a>最初是由 <code>彳亍</code> 于 2006 年在 mf8 论坛上提出的, 其作为三循环二步法虽然强大, 但其编码对于新手而言记忆熟练负担较重. 为了解决这一痛点, 本文在现代"彳亍法"教程[^1]<a href="%5B%E5%BD%B3%E4%BA%8D%E6%B3%95(%E4%B8%89%E5%BE%AA%E7%8E%AF%E4%BA%8C%E6%AD%A5%E7%9B%B2%E6%8B%A7%E6%B3%95)%E5%85%A5%E9%97%A8%E7%AE%80%E6%98%8E%E6%95%99%E7%A8%8B%E2%80%94%E2%80%94%E4%B8%80%E5%8F%B6%E7%9F%A5%E7%A7%8B%5D(http://bbs.mf8-china.com/forum.php?mod=viewthread&#x26;tid=13404)">^5</a>的基础上, 设计了一套更符合直觉, 更易于记忆的编码图, 希望能为广大魔方爱好者打开盲拧世界的大门.</p> <p>彳亍法盲拧的基本思路可以简要概括为: 首先, 将打乱后的魔方角块和棱块的位置, 分别按照特定规则编码成两个字母字符串. 每个字符串大约包含 20 个英文字母. 记住这两个字符串后, 在蒙眼复原时, 依次按照三循环公式, 将字符串中的每一对字母所对应的块复原到正确位置. 当这两个字符串全部执行完毕, 魔方的角块和棱块也就全部复原了.</p> <p>因此, 与速拧相比, 学习盲拧彳亍法时主要需要掌握以下四大板块:</p> <ol> <li>熟记魔方上每个面所对应的字母编码.</li> <li>新的复原流程.</li> <li>掌握应用在字母编码上的三循环公式: <ol> <li>简单版本中, 我们只考虑缓冲块与顶层非对角的两个块的三循环公式, 角块需要 8 个公式, 棱块需要 18 个公式;</li> <li>复杂版本中, 我们考虑任意两个块和缓冲块之间的三循环公式, 角块公式多达 440 个, 棱块公式有 378 个, 总计 818 个公式, 这也是"盲拧彳亍 818"名称的由来.</li> </ol> </li> <li>高效记忆这两个总长约 20 个字母的字符串, 方法如下: <ol> <li>将每两个字母<strong>联想</strong>成一个词语进行记忆;</li> <li>用拼音（或双拼）来记忆两个字母;</li> <li>像记电话号码, 车牌号一样, 直接顺序顺口读下来;</li> <li>对于初学者, 建议全部采用联想记忆法. 当盲拧速度提升到两分钟以内时, 可以尝试"记角读棱法": 用方法 2 记忆较短的角块编码, 用方法 3 记忆较长的棱块编码, 复原时优先还原棱块, 以防遗忘棱块编码.</li> </ol> </li> </ol> <h2>编码</h2> <h3>设计理念</h3> <p>参考[^2]和[^3], 我设计了一套新的编码图, 旨在融合 <code>Speffz</code> 编码的逻辑性和中文编码的顺口性, 为初学者提供一套更易上手的盲拧记忆方案.</p> <ul> <li><strong>对比彳亍编码</strong>: 传统的彳亍编码记忆点较为零散, 新手容易"从入门到放弃". 我的设计更注重字母排布的规律, 降低了记忆门槛.</li> <li><strong>对比 Speffz 编码</strong>: Speffz 作为国际标准, 是由 <a href="https://www.speedsolving.com/wiki/index.php?title=Ville_Sepp%C3%A4nen">Ville Seppänen</a> 和 <a href="https://www.speedsolving.com/wiki/index.php?title=Rob_Holt">Rob Holt</a> 于 2010 年为了方便交流提出的标准化方案, 逻辑性极佳, 但字母本身难以与中文的形象或拼音关联, 不便于中文母语者通过组词等方式记忆.</li> </ul> <h3>编码详解</h3> <ul> <li><strong>顶层 (U Face)</strong>: 完全遵循 <code>Speffz</code> 编码的 <code>A, B, C, D</code> 顺序, 一组连续字母, 方便整体记忆.</li> <li><strong>前层 (F Face)</strong>: 字母为 <code>E, F, G, X</code>. 可以联想为这个面正对着"我 (Me)", 所以以 <code>E</code> 开头. <code>E, F, G</code> 字母连续, 朗朗上口. <code>X</code> 则作为一个特殊字母, 与右, 后, 左面的 <code>Y, Z, W</code> 形成一组.</li> <li><strong>右, 后, 左层 (R, B, L Faces)</strong>: 首字母分别为 <code>R, O, L</code>, 可记为 <code>Right</code> (右), <code>Opposite</code> (前层的对面), <code>Left</code> (左). 每个面同样搭配了易于记诵的连续字母.</li> <li><strong>底层 (D Face)</strong>: 字母为 <code>H, I, J, K</code>, 一组连续字母, 方便整体记忆.</li> </ul> <h2>编码与复原流程</h2> <p>前文已经简要介绍了盲拧的基本思路, 下面将详细梳理整个复原流程, 帮助大家更清晰地理解每一步的操作.</p> <p>由于实际操作中举例讲解非常重要, 因此强烈建议大家配合 <a href="https://space.bilibili.com/243671525/lists/4331101">彳亍法盲拧教程</a> 的视频学习, 视频中的演示和讲解非常直观易懂.</p> <h3>编码——顺序</h3> <p>编码的起点是缓冲块的上方: 对于棱块来说, 是 <code>UF</code> 棱块的 <code>U</code> 面; 对于角块, 则是 <code>UFR</code> 角块的 <code>U</code> 面. 我们通常先对棱块进行编码, 角块的编码原理与棱块类似, 这里以棱块为例进行说明.</p> <p>假设当前 <code>UL</code> 棱块的 <code>L</code> 面正好位于缓冲块 <code>UF</code> 的 <code>U</code> 面上, 那么第一个编码就是 <code>L</code>. 这是因为在我设计的编码方案中, <code>UL</code> 棱块的 <code>L</code> 面对应字母 <code>L</code>. 这个编码的含义是: 现在处于 <code>C</code> 位置的棱块, 现在应该被送往 <code>L</code> 位置.</p> <p>需要注意的是, 字母编码是固定的, 不会随着魔方的旋转而变化, 可以理解为一个静止的坐标系. 比如“<code>C</code> 这个字母前往 <code>L</code>”, 就好比在坐标系中, 一个标注了 0 的小球应该从位置 5 移动到位置 0, 复原这个小球的编码就是 0.</p> <p>接下来, 观察 <code>L</code> 位置上的棱块颜色, 判断它应该去往哪个位置. 如果它应该前往 <code>B</code> 位置, 那么第二个编码就是 <code>B</code>. 依此类推, 直到所有棱块都被编码完毕.</p> <h3>编码——奇偶校验 (Parity Check)</h3> <p>当编码长度为奇数时 (棱块和角块编码长度必然同奇偶), 需要进行奇偶校验. 方法很简单: 只需在棱块和角块编码后各加一个 <code>B</code>, 并在复原最后执行一次 <code>Jb Perm</code> 公式即可.</p> <h3>编码——翻色</h3> <p>如果打乱后有某个棱块或角块虽然位置正确但方向错误, 那么就需要进行翻色操作.</p> <p>如果需要翻色的块数为偶数, 则这些块一起翻色; 如果为奇数, 则这些块和缓冲块一起翻色.</p> <h3>编码——小循环</h3> <p>小循环的概念相对抽象, 建议大家先观看<a href="https://www.bilibili.com/video/BV1TE41187AG">实例视频</a>，或亲自尝试构造一个顺序编码提前结束的小循环案例, 以便更好地理解.</p> <p>在实际编码过程中, 我们常常会遇到这样一种情况: 顺序编码时, 某个块需要回到缓冲块的位置 (即 <code>C</code> 位置或 <code>E</code> 位置), 但此时还有其他块尚未被编码. 此时, 顺序编码会提前"断开", 形成一个小循环. 为了继续完成编码, 我们需要主动选择一个尚未被编码的块, 作为新的"起点", 继续顺序编码, 直到所有块都被编码为止.</p> <p>色相: <code>UD</code> 面为高级色相, <code>FR</code> 面为中级色相, <code>LB</code> 面为低级色相. 每个棱块都位于两个不同级别的面上, 因此每个块都拥有一个高级色相和一个低级色相.</p> <p>色相相同: 指的是两个面同为高级色相或同为低级色相.</p> <p>如何选择新的起点 (即如何打破小循环) 是许多初学者常见的疑惑, 我们给出选择原则:</p> <ul> <li>棱块: 选择与当前缓冲块<strong>色相相同</strong>的块作为下一个编码目标.</li> <li>角块: 可以任意选择一个未编码的位置继续编码, 无需遵守色相一致原则.</li> </ul> <p>具体操作时, 如果顺序编码遇到某个块应回到缓冲块的 <code>C</code> 位置, 应优先选择一个尚未编码、拥有高级色相的块作为下一个编码目标; 如果遇到应回到 <code>E</code> 位置, 则优先选择拥有低级色相的块. 这样做可以避免在有奇偶校验且编码以 <code>UR</code> 块结尾时, 出现额外的翻色情况.</p> <p>大多数情况下, 借位色相是否一致并不会影响结果, 只有在编码为奇数个 (即需要奇偶校验) 且棱块最后一个编码落在 <code>B</code> 或 <code>R</code> 时才会有区别.</p> <ol> <li>如果此时其余棱块没有翻色或是偶数个翻色, 按色相借位, 最后的编码是 <code>B</code>, 不按色相借位则是 <code>R</code>. 这样会导致缓冲块和 <code>UR</code> 块<strong>额外</strong>产生一次翻色, 这不是打乱本身造成的, 而是因为没有遵守色相一致原则导致的, 造成了额外的工作量, 这是我们希望避免的.</li> <li>如果是奇数个棱块需要翻色, 按色相借位同样会使最后一个编码落到 <code>R</code>, 同样会有翻色, 但此时是缓冲块和另外奇数个翻色块共同翻色. 由于额外翻色为奇数, 无论如何都得进行翻色, 这是打乱本身造成的, 没有造成额外的工作量, 可以接受.</li> </ol> <p>举例说明:</p> <p>红顶绿前打乱: <code>R U R' F' R U R' U' R' F R2 U' R' U'</code></p> <p>这个打乱的盲拧编码长度为奇数, 存在奇偶校验, 并且最后一个编码必然为 <code>B</code> 或 <code>R</code>, 满足出现特殊情况的条件.</p> <p>如果遵守色相一致原则, 棱块盲拧编码为: <code>BZ B</code>, 最后一个 <code>B</code> 和奇偶校验加入的额外 <code>B</code> 互相抵消, 因此只需做一个 <code>BZ</code> 公式.</p> <p>如果不遵守色相一致原则, 棱块盲拧编码为: <code>RS R</code>, 最后一个 <code>R</code> 和奇偶校验加入的额外 <code>B</code> 互相抵消, 因此只需做一个 <code>RS</code> 公式.</p> <p>从做完公式的结果可以看到, 遵守色相一致原则不会产生额外翻色, 而不遵守则会多一次翻色.</p> <h3>复原——应用公式</h3> <p>编码完成后, 就可以开始应用公式进行复原.</p> <p>例如, 若两个编码为 <code>DB</code>, 则直接使用 <code>M2 U' M U2 M' U' M2</code> 公式进行复原.</p> <h3>复原——Set Up and Reverse</h3> <p>如果没有记住任意两块之间的复原公式 (共 818 条), 可以只记 26 条基础公式, 配合 Set Up and Reverse 技巧完成复原.</p> <p>Set Up and Reverse 的原理是: 先将目标两块通过预处理 (Set Up) 转移到 <code>UL</code> 和 <code>UR</code> 位置, 应用已记住的公式进行复原, 最后再按相反步骤 (Reverse) 将两块归位. 这个过程类似于"入栈"和"出栈".</p> <p>有两个必须遵守的规则和一个可以不遵守的建议:</p> <ol> <li>Set Up 过程中, 不能在转动某个面时同时移动两个需要被 Set Up 的块, 否则可能导致额外的翻色.</li> <li>Set Up 过程中, 不能移动缓冲块, 否则公式就不再针对当前缓冲块 (除非你清楚缓冲块的新位置并能应用相应公式).</li> </ol> <p>建议先 Set Up 一对编码中的第一个块, 再 Set Up 第二个块. 这样更有逻辑性, 也更不容易出错.</p> <h2>三循环公式</h2> <p>顾名思义, 三循环公式就是调换任意三个块 (棱块或角块) 而不影响其他块的公式.</p> <p>参考<a href="%5B%E5%BD%B3%E4%BA%8D%E6%B3%95%E7%9B%B2%E6%8B%A7%E6%95%99%E7%A8%8B(10)%E2%80%94%E2%80%94%E5%9F%BA%E7%A1%80%E5%85%AC%E5%BC%8F%E2%80%94%E2%80%94%E4%BE%9D%E6%97%A7%E6%98%AF%E4%B8%80%E4%B9%9D%E5%9B%9B%5D(https://www.bilibili.com/video/BV1TE411b7Xe)">^7</a>, 这里给出简单版本的公式, 只包含 <code>UL</code>,<code>UF</code>,<code>UR</code> 三个棱块互换和 <code>UFL</code>,<code>UFR</code>,<code>UBR</code> 三个角块互换的公式. 复杂版本的公式可以参考<a href="https://www.bilibili.com/opus/355029676093901363">一九四的三盲818公式</a>.</p> <ul> <li><strong>E 层</strong>: U 层和 D 层所夹的中层, 转动方向同 D 层.</li> <li><strong>S 层</strong>: F 层和 B 层所夹的中层, 转动方向同 F 层.</li> <li><strong>M 层</strong>: L 层和 R 层所夹的中层, 转动方向同 L 层.</li> </ul> <h3>棱块公式</h3> <p>缓冲块为 <code>UF</code>.</p> <p>其中的备选公式 1 比较适合初学者, 备选公式 2 比较进阶.</p> <p>| 目标位置 | 备选公式 1 (初学) | 备选公式 2 (进阶) | | :---: | :--- | :--- | | DB | <code>R2 U R U R' U' R' U' R' U R'</code> | <code>M2 U' M U2 M' U' M2</code> | | BD | <code>R U' R U R U R U' R' U' R2</code> | <code>M2 U M U2 M' U M2</code> | | LB | <code>U' r U R' U' r' R U R U' R' U</code> | <code>L F' L' S' L F L' S</code> | | BL | <code>U' R U R' U' M' U R U' r' U</code> | <code>S' L F' L' S L F L'</code> | | LR | <code>M U M' U2 M U M'</code> | | | RL | <code>M U' M' U2 M U' M'</code> | | | DR | <code>U' R' U' R U M U' R' U r</code> | <code>S R' F R S' R' F' R</code> | | RD | <code>U' r' U' R U M' U' R' U R</code> | <code>R' F R S R' F' R S'</code> |</p> <p>对棱翻色公式: <code>M' U M' U M' U2 M U M U M U2</code></p> <h3>角块公式</h3> <p>缓冲块为 <code>UFR</code>.</p> <p>| 目标位置 | 公式 | | :---: | :--- | | DB | <code>x' R2 D2 R' U' R D2 R' U R' x</code> | | BD | <code>x' R U' R D2 R' U R D2 R2 x</code> | | DO | <code>R' U' D' R' D R U R' D' R D R</code> | | OD | <code>R' D' R' D R U' R' D' R U D R</code> | | DS | <code>U' R' U2 R' D' R U2 R' D R2 U</code> | | SD | <code>U' R2 D' R U2 R' D R U2 R U</code> | | EB | <code>R2 D R' U2 R D' R' U2 R'</code> | | BE | <code>R U2 R D R' U2 R D' R2</code> | | EO | <code>R U D' R' D' R U2 R' D R D U R'</code> | | OE | <code>R U' D' R' D' R U2 R' D R D U' R'</code> | | ES | <code>R' U' R2 D' R2 D R2 U R2 D' R2 D R'</code> | | SE | <code>R D' R2 D R2 U' R2 D' R2 D R2 U R</code> | | MB | <code>x' R U R' D R U' R' D' x</code> | | BM | <code>x' D R U R' D' R U' R' x</code> | | MO | <code>R' U L U' R U L' U'</code> | | OM | <code>U L U' R' U L' U' R</code> | | MS | <code>F' U R' D R U2 R' D' R U F</code> | | SM | <code>F' U' R' D R U2 R' D' R U' F</code> |</p> <p>角块翻色采用 <code>(R U R' U') D (U R U' R') D'</code> 等类似的转换机 (Commutator) 翻色法.</p> <p>详情可参考视频: <a href="https://www.bilibili.com/video/BV1RE411t7zr/">彳亍法教程——关于翻色</a>.</p> <h3>奇偶校验</h3> <p>当编码中出现奇数个字母时, 说明出现了奇偶校验问题, 需要额外执行下述的其中一个公式来修正 (哪一个都行).</p> <ul> <li><strong>棱块缓冲与B交换, 角块缓冲与B交换</strong>: <code>R U R' F' R U R' U' R' F R2 U' R' U'</code></li> <li><strong>棱块缓冲与A交换, 角块缓冲与D交换</strong>: <code>U' R U R' U' R' F R2 U' R' U' R U R' F' U</code></li> </ul> <h2>记忆方法</h2> <p>我采用的是小鹤双拼记忆法[^4], 这种方法与双拼输入法的原理类似, 即用一个汉字来表示两个字母. 例如, 如果你的盲拧编码只有棱块的 <code>ID</code>, 在双拼输入法中可以对应为 <code>拆</code> 或 <code>柴</code> 字, 因此你只需要记住这个汉字即可.</p> <p>当然, 有些字母组合可能没有对应的汉字, 这时我们可以用其他拼音方式来替代. 例如, 编码 <code>C</code> 代表缓冲块, 不会被编码, 所以在没有对应汉字的情况下, 可以将双拼的第一个或第二个音节替换为 <code>C</code>.</p> <p>具体的设计细节可以参考 <a href="https://www.cuberoot.me/cuberoot-letter-scheme-and-syllable/">CubeRoot 双拼记忆法</a>, 这里不再赘述.</p> <p>双拼记忆法的优点在于, 它将记忆量减半, 相比拼音法更加高效. 不过, 这种方法更适合平时就习惯使用双拼输入法的人. 如果你平时并不熟悉双拼, 可能需要花费较多时间先掌握双拼编码. 因此, 如果你不常用双拼输入法, 我更推荐你采用联想法或拼音法进行记忆.</p> <p>如果想了解更多相关教程, 可以在 B 站搜索 <code>盲拧记忆</code> 等关键词进行查找.</p> <hr> <p>[^2]: <a href="https://www.bilibili.com/video/BV1TUKszEEVT/">我发明了一种新的盲拧编码图, 或许是最符合中文思路的盲拧编码图——依旧是一九四</a></p> <p>[^3]: <a href="https://www.bilibili.com/video/BV1NaK5zJEQV/">一种新的盲拧编码方式分享, 或许是容易记忆的盲拧编码图（回应194大神的编码视频）——亢泽超kzc</a></p> <p>[^4]: <a href="https://www.cuberoot.me/cuberoot-letter-scheme-and-syllable/">CubeRoot Scheme, Syllable——CubeRoot</a></p> <p>[^5]: <a href="https://www.bilibili.com/read/cv17648560/">盲拧魔方彳亍法入门 文字版教程——天方魔</a></p>https://www.lyt0112.com/blog/course_review-zhhttps://www.lyt0112.com/blog/course_review-zhHelpful Course Information for PKU StudentsSun, 22 Jun 2025 12:17:00 GMT<p>import { Aside } from '@/components/user' import GithubCard from '@/components/advanced/GithubCard.astro'</p> <p>欢迎来到博主的课程评测页面!</p> <p>使用电脑等宽屏设备浏览, 可以在右侧看到详细目录; 使用手机等移动设备, 点击右下角按钮同样可以方便地展开目录.</p> <p>每门课程的资料链接都放在对应的介绍后面, 欢迎根据需要查阅.</p> <p>如果这些内容对你有所帮助, 非常欢迎在下方评论区留下你的反馈和建议, 这不仅能帮助到我, 也能帮助到更多同学. 同时也欢迎给我的 GitHub 仓库点个 star 🌟, 你的支持是我持续更新的动力!</p> <p><strong>祝大家选课顺利, 学业进步, 收获满满!</strong></p> <p>Update on 2025.12.29:</p> <p>又到了一年一度的 ICS 期末季, 选择这门课的同学们真的辛苦了. 想在这里分享一些感想.</p> <p>从现在的视角来看, 很多课程资料, 尤其是 Lab 代码, 已经不再具有强的指导意义, 因为各种 coding agent 已能高效完成定义明确的课程 Lab 编程任务. 比如, <a href="https://github.com/ICUlizhi/VibePkuMinic">Vibe Coding: PKU Compiler Principles Lab</a> 就展示了, 即使是难度最高的编译原理 Lab, 也可以完全交给 AI 来完成. 这与我在科研中的实践也相互印证.</p> <p>因此, 最简单的, <strong>一定要学会使用 coding agent 写代码</strong>.</p> <p>其次, 在这样的环境下, 我们如何保持竞争力？这并不是几句话能说清的. 但正如那篇文章的作者所言：</p> <blockquote> <p>当 Implementation 的边际成本趋近于零, Engineering 的价值便会从 "How to build" 向 "What to build" 剧烈迁移.</p> </blockquote> <p>希望大家能在这样的环境中找到自己真正喜欢的事情, 并全身心投入. 这才是大学阶段最值得去做的事.</p> <p>Update on 2025.07.03:</p> <p>我在 <a href="this_is_pku-zh">这篇文章</a> 中分享了整理课程资料的心路历程，欢迎感兴趣的同学阅读！</p> <p>Update on 2025.06.22:</p> <p>最后一科分析性英语写作 (一门非常好的不用上课的 C 级英语课) 卡着毕业生出分 DDL 出分了, 本科 150 学分课程全部完成, 毕业快乐!</p> <p>Update on 2025.04.18:</p> <p>这里有一个北大同学开发的课程资料网站: <a href="https://pkuhub.cn">PKUHUB</a>, 在开发团队的邀请下我上传了部分资料, 也可以看到别的同学上传的资料, 非常好的项目!</p> <h2>春秋学期均开设的课程</h2> <h3>编译原理</h3> <p>刘先华, 王迪, 张路 2024秋</p> <p><strong>课程听感</strong></p> <p>大四了就去过三次课, 但是我感觉讲的还挺清楚的, 但是如果只看 slides 可能会很迷惑, 尤其是语法分析和 SDT 部分, 所以建议要么看书作为补充, 要么看看下面资料中的笔记.</p> <p><strong>作业/任务量</strong></p> <p>十五次作业, 九个 lab. 有的时候一周两次作业, 有的时候一周没有作业.</p> <p>建议在没有绩点压力的大四选这门课, 就可以不写 Lv9 了, 因为 Lv9 非常浪费时间并且占所有 Lab 的 27% 的分数, 也就是总评的 8 分, 如果在绩点压力下完成所有 Lab 会浪费很多时间.</p> <p><strong>考试</strong></p> <p>最后一节课有三十分钟的 Lab 小测, 开卷可以查阅任何资料, 我们的小测问题是:</p> <ol> <li>目前完成的程度及功能得分.</li> <li>简介你的编译器是如何处理符号表及嵌套作用域的.</li> <li>简介你的寄存器分配方案的设计和实现.</li> <li>SysY 文法是否有二义性问题, 你的编译器是如何解决的.</li> <li>简述 KoopalR (或你所使用的 IR) 的主要特点.</li> </ol> <p>期中期末都有考试, 期中之前好好学习了, 每周看 slides ; 期中之后没看过, 期末考试前两天速成, 对往年题做 few-shot learning 可以做到期中 90 分, 期末也差不多, 同样写写往年题就行了.</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Compiler_Principles-2024Fall-PKU">编译原理资料仓库</a></p> </li> <li> <p><a href="https://github.com/EmptyBlueBox/Compiler_Principles_Lab-2024Fall-PKU">编译原理 Lab 代码</a></p> </li> <li> <p><a href="https://www.lyt0112.com/blog/compiler_principles_lab_note-zh">编译原理 Lab 笔记</a></p> </li> <li> <p><a href="https://arthals.ink/tags/%E7%BC%96%E8%AF%91%E5%8E%9F%E7%90%86">课程知识笔记和 Lab 注意事项 from Arthals</a></p> </li> </ol> <p><strong>成绩</strong></p> <p>2025.01.26: 81</p> <p>大四满足了 🎊</p> <h3>操作系统</h3> <p>陈向群 2025春</p> <p><strong>课程听感</strong></p> <p>去了 0 次 + 最后一节课的 10 分钟.</p> <p><strong>作业/任务量</strong></p> <ol> <li>xv6 实验</li> <li>四次书面作业</li> <li>二十几次上课小测</li> <li>一次期中考试 (半开卷, 可以带五张正反面 A4 纸)</li> <li>一次期末考试</li> </ol> <p><strong>考试</strong></p> <p>期中考试:</p> <p>考到第六章虚拟内存技术.</p> <p>非常抽象的事情是考试方式阴晴不定, 我了解到的信息 (大概是这样):</p> <ul> <li>2023年春季学期没有期中考试</li> <li>2023年秋季学期期中考试闭卷</li> <li>2024年春季学期期中考试闭卷</li> <li>2024年秋季学期期中考试完全开卷, 可以带任意多资料</li> <li>2025年春季学期期中考试部分开卷, 可以带 5 张 A4 纸</li> </ul> <p>期末考试:</p> <p>这两年期末老师提到必考<a href="https://github.com/EmptyBlueBox/Operating_Systems-2025Spring-PKU/blob/main/Resource/%E6%80%9D%E8%80%83%E9%A2%98.md#02-unix%E5%92%8Cfat16%E5%B8%83%E5%B1%80%E6%A8%A1%E6%8B%9F">UNIX和FAT16布局模拟</a>, 上课也仔细讲了这道题, 如果没时间可以看看最后两次课的内容, <a href="https://www.lyt0112.com/blog/operating_systems_note_10-zh">经典的同步问题</a> 和 <a href="https://www.lyt0112.com/blog/operating_systems_note_11-zh">死锁</a> 的内容.</p> <p>期末考试题目回忆:</p> <ol> <li>举一个使用了 <code>mmap</code> 的例子, 并解释这样做有什么好处, 使用了什么数据结构</li> <li><a href="https://github.com/EmptyBlueBox/Operating_Systems-2025Spring-PKU/blob/main/Resource/%E8%AF%BE%E5%A0%82%E5%B0%8F%E6%B5%8B-%E6%9C%9F%E4%B8%AD%E5%89%8D.md">期中前课堂小测</a>的最后一题 <ol> <li>询问什么时候会把页面从工作集中置换到空闲页面链表</li> <li>把修改的页面先放到修改页面链表再写回 (延迟写) 有什么好处</li> <li>什么是软缺页异常</li> </ol> </li> <li>就是上面这个 UNIX 文件系统布局模拟, 但是用了两级目录, 然后提问某个文件读取其中一段访问了几个数据块</li> <li>死锁 <ol> <li>有哪些方法避免死锁</li> <li>哲学家就餐问题怎么使用有序资源申请解决</li> </ol> </li> <li>按下键盘上的 <code>Ctrl+C</code> 后发生了什么, 给了大约20个选项排序, 包括陷入内核的时候要并发调度到别的进程</li> <li>同步问题 <ol> <li>用信号量解决三峡大坝船闸问题</li> <li>用管程解决生产者-消费者问题, 并说明你用的是 Hoare 管程还是 MESA 管程</li> <li>用信号量管理共享资源, 询问 "I'll Do it for You" 是否是正确解法, 然后给 "Pass the Baton" 解法填空</li> </ol> </li> <li>xv6 代码题 (主要是跟作业相关的) <ol> <li>解释 <code>uvmalloc</code> 怎么实现的, 主要是解释其中的 <code>for</code> 循环在做什么</li> <li>解释为什么要获取 <code>bcache</code> 的锁, 然后解释磁盘块高速缓存怎么实现 <code>LRU</code> 算法的</li> <li>从管道写入的函数, 具体记不清了</li> </ol> </li> <li>附加题: 画出五个进程死锁的所有不同构的进程依赖图</li> </ol> <p><strong>相关资料</strong></p> <ol> <li>课程笔记:</li> </ol> <ul> <li><a href="https://www.lyt0112.com/blog/operating_systems_note_01-zh">01. 操作系统概述</a></li> <li><a href="https://www.lyt0112.com/blog/operating_systems_note_02-zh">02. 中断异常机制</a></li> <li><a href="https://www.lyt0112.com/blog/operating_systems_note_03-zh">03. 进程线程模型</a></li> <li><a href="https://www.lyt0112.com/blog/operating_systems_note_04-zh">04. 进程线程调度</a></li> <li><a href="https://www.lyt0112.com/blog/operating_systems_note_05-zh">05. 内存管理概述</a></li> <li><a href="https://www.lyt0112.com/blog/operating_systems_note_06-zh">06. 虚拟内存技术</a></li> <li><a href="https://www.lyt0112.com/blog/operating_systems_note_07-zh">07. 文件系统 1</a></li> <li><a href="https://www.lyt0112.com/blog/operating_systems_note_08-zh">08. 文件系统 2</a></li> <li><a href="https://www.lyt0112.com/blog/operating_systems_note_09-zh">09. 并发机制</a></li> <li><a href="https://www.lyt0112.com/blog/operating_systems_note_10-zh">10. 经典的同步问题</a></li> <li><a href="https://www.lyt0112.com/blog/operating_systems_note_11-zh">11. 死锁</a></li> </ul> <ol start="2"> <li> <p><a href="https://github.com/EmptyBlueBox/Operating_Systems-2025Spring-PKU">操作系统资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>课程笔记</li> <li>课程作业</li> <li>Lab 代码 (下面这个仓库作为 submodule)</li> <li>考试往年题以及解答</li> <li>课堂小测以及解答</li> <li>思考题以及解答</li> </ol> </li> <li> <p><a href="https://github.com/EmptyBlueBox/Operating_Systems_Lab-2025Spring-PKU">操作系统 Lab 代码仓库</a></p> <p>这个仓库包括:</p> <ol> <li>Lab 代码</li> <li>Lab 实验文档</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>80</p> <p>终究还是给了 80 而不是 80- 吗, 哈基cnn, 你这家伙......</p> <h3>射箭</h3> <p>张冰 2024秋</p> <p><strong>课程听感</strong></p> <p>超难选超好玩给分超好体育课.</p> <p> 这个博主射箭超厉害 </p> <p> 最后一节课的有趣射箭小游戏, 第一名有奖牌 </p> <p><strong>作业/任务量</strong></p> <p>只有期末理论方面的一篇手写论文, 和射箭相关写多少字都行, 我就写了两段话半张 A4 纸.</p> <p><strong>考试</strong></p> <p>期末会有两节课的射箭排位赛, 具体方式就是每节课每人射 8 组箭, 前两组用作热身不算成绩, 每组箭 6 枝, 两节课总共算 72 枝箭的成绩, 最后全班按照总环数排名.</p> <p>基本上 650 环可以拿到第一名, 博主 610 环第四名.</p> <p><strong>相关资料</strong></p> <p>无</p> <p><strong>成绩</strong></p> <p>2024.12.30: 97</p> <p>疑似体测扣了 3 分, 射箭本体满分...🌚...</p> <h2>秋季学期课程</h2> <h3>信息安全引论</h3> <p>王昭 2024秋</p> <p><strong>课程听感</strong></p> <p>大四专业选修凑学分课, 疑似没听过. Slides 也非常非常极尽迷惑之事, 根本看不明白, 感觉不如看课本, 但是课本太多了, 所以建议前几节课学学后面的就不用学了, 尤其是期中之后的知识考试涉及不多.</p> <p><strong>作业/任务量</strong></p> <p>三次书面作业, 六次小测, 两次作业小测, 四次课堂小测, 但是课堂小测可以下来问同学密码是多少然后补测.</p> <p>一次写代码的 Lab, 若干次在一个在线平台上的 Lab, 第一个 Lab 需要费点时间, 后面的 Lab 比较简单, 一个小时就能做一个.</p> <p><strong>考试</strong></p> <p>没有期中考试, 期末考试 60% 为作业题, 大四同学好好复习作业题和小测题即可, 在仓库里有详细解析的作业题和小测题自取~</p> <p>期末题型为填空, 判断, 选择, 简答, 大题, 体感来讲如果好好复习了作业题和小测题确实至少能拿 60 分, 博主体感正经写了 80 分左右的题目, 剩下 20 分就瞎写了.</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Introduction_to_Information_Security-2024Fall-PKU">信息安全引论资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>作业及解答</li> <li>期末复习选择题总结</li> <li>Lab 解答</li> <li>小测题, 不过已经总结进期末复习选择题总结里了</li> <li>课本</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>2025.01.16: 84</p> <p>大四满足了 🎊</p> <h3>强化学习</h3> <p>李文新 2024秋</p> <p><strong>课程听感</strong></p> <p>大四就去过两次课, 感觉不如看 slides, 但是上课回答问题可以加分, 最高加三分. 同时时不时就有传纸条签到的环节, 但是完全可以让同学帮忙写姓名学号.</p> <p><strong>作业/任务量</strong></p> <p>八次作业, 一次大作业, 一次课程大作业 Presentation.</p> <p>每次小作业差不多花一两个小时, 就是复现一些经典的 RL 算法, 有的调参还挺烦的. 其中最后一个作业是在开悟平台上的控制 agent 走迷宫, 只需要调整 reward 然后续训就能达到 1430 左右的分数.</p> <p>大作业是在四个项目里选择, 分别是开悟平台王者1v1对战, 国标麻将, 双升, 和掼蛋的强化学习模型训练, 每个大作业按照跟同学的对战胜负排名天梯给分. 建议选择王者1v1对战, 因为可以复用最后一次小作业的经验, 并且不用修改代码就能跑起来, 最后只需要调整 reward 和模型架构即可.</p> <p>大作业 Presentation 就是每组上台汇报自己的 RL agent 训练经验, 汇报持续两周, 第一周汇报的同学因为训练时间更少所以有一分加分.</p> <p><strong>考试</strong></p> <p>没有期中考试, 期末考试 60 道选择题. 拟合小测题和往年题即可.</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Reinforcement_Learning-2024Fall-PKU">强化学习资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>期末复习总结</li> <li>课程作业及解答</li> <li>小测题</li> <li>课本</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>89</p> <p>给分吹爆, 没有任何额外加分都能给大四这么高, 优秀率 60%.</p> <p>来自树洞 7073734:</p> <p>学长学长, 你的地概确实很强, 但还是太吃优秀率限制了, 有没有什么更加简单又好拿分的课程推荐一下吗？</p> <p>有的兄弟！有的！像这么好的课程北大当然是不止一个了, 一共有九个, 当时当前学期t0.5的优质课程, 随便选上一个都能够轻松彩虹, 如果九门都选上那你的院系排名将会冲顶, 如果九门课都像学长一样拿到满分的水平, 那我可以说你的成绩可以直接冲五四奖学金都是没有问题的了.</p> <p>2025年, zkc教员宣告水课地概已不复存在, 考试重点不再勾画, 优秀率也不再给满, 新形势下, 老九门课程讲何去何从？我们还有没有机会重铸彩虹荣光？</p> <p>有的兄弟！有的！我推荐你来选嘻嘻科学技术学院课程：强化学习. 本课程由李文新教授讲授, 课堂幽默风趣互动良多愉快有加分, 且加分有上限无内卷, 作业两周一个轻松容易, 不考勤有慕课复习无压力, 考核内容有趣不紧张, 助教贴心全程陪学有问必答答必解惑, lab框架清晰同学交流密切, 更有前沿讲座各界大佬分享技术交流思想, 考题不超纲全是单选且与教学内容绝对平行不正交, 有往年题提供开源自信从不隐瞒, 大作业选题宽泛麻将掼蛋王者荣耀应有尽有, 即使你对强化学习算法一窍不通也可以简单多次训练拿到很好的表现加强对强化学习的了解与认知.</p> <p>选择强化学习, 重铸彩虹荣光！</p> <p>兄弟！有没有心动！</p> <p>兄弟！有的！</p> <h3>智能机器人概论</h3> <p>赵卉菁 2023秋</p> <p><strong>课程听感</strong></p> <p>听感一般, 老师讲课很认真, 但是三教的教室实在是太温暖了, 让人不得不睡觉...</p> <p>最后来的人越来越少, 老师就会以前一节课的 slides 内容作为小测内容, 在下一节课小测, 但是准确率不重要, 是用作签到的.</p> <p><strong>作业/任务量</strong></p> <p>三次写代码的小作业, 每次也就几十行代码, 很快就写完了, 但是要写实验报告, 大概是使用课上讲过的算法来构建地图这样的简单任务.</p> <p>期中期末两次大作业.</p> <p>期中是绕行理科二号楼一圈, 今年额外加了最后的绕桶项目, 难度较大, 前面的拐弯使用启发式算法即可.</p> <p>期末是自选题目, 最重要的事情是选择一个有趣的题目, 强烈建议借助小车完成期末作业, 然后可以做一个视频讲一个故事, 越有趣越好, 代码难度没有什么影响.</p> <p>附上我们组的期末大作业视频以供参考: <a href="https://b23.tv/gBXGwpG">Bilibili</a></p> <p><strong>考试</strong></p> <p>无</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Introduction_to_Intelligent_Robots-zhj-2023Fall-PKU">智能机器人概论资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>三次作业的代码</li> <li>期中大作业的代码和评分标准</li> <li>期末大作业的视频链接</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>93</p> <p>感觉是大作业的 idea 让老师感觉很有趣.</p> <h3>计算机网络</h3> <p>黄群 2023秋</p> <p><strong>课程听感</strong></p> <p>黄群老师讲课是自顶向下的, 和同一个学期的计网实验班是相反的顺序.</p> <p>老师讲得挺好的, 可以把 slides 和口述部分连接起来形成逻辑链条, 课程值得一听.</p> <p>讲课的时候老师还喜欢加入长者的梗, +1s</p> <p><strong>作业/任务量</strong></p> <p>没有平时作业.</p> <p>四个 lab 选三个最高分, 我选择的是 1, 2, 4, 首先第四个 lab 半个小时就能写完, 一定要选; 第一个 lab 也不难, 而且是刚开学时间充裕, 建议选; 最后我还建议选第二个 lab, 因为第三个 lab 可能和期末考试时间有冲突, 难度也不低.</p> <p>MOOC 水过, ddl 是期末之后, 及格就行.</p> <p><strong>考试</strong></p> <p>期中考试无, 期末考试会给往年题和考试范围.</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Computer_Networks-hq-2023Fall-PKU">计算机网络资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>我的期末复习笔记.</li> <li>Labs , 但是第三个 Router Lab 仍然有 bug , 但是由于只需要完成四个 lab 中的三个即可, 所以这个 lab 就没有彻底完成.</li> <li>一些相关资源, 包括一些往年题.</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>88</p> <p>疑似期末考得一般.</p> <h3>博弈论</h3> <p>刘霖 2023秋</p> <p><strong>课程听感</strong></p> <p>这是政府学院的刘霖教授开设的三学分博弈论课程, 课程分为四个部分介绍了不同种类的博弈论, 知识内容还是比较丰富的, 老师上课也会积极与同学互动, 叫同学上台回答问题.</p> <p>但是刘霖教授的讲课方式注定了这门课需要下课自己好好思考学习. 因为老师的 slides 只有大纲, 具体的知识点都是口述, 所以上课是必要的, 但是又由于老师讲课有的时候比较模糊, 所以需要下课复习回放. 在复习回放的基础上, 没有必要看其他的补充教材.</p> <p><strong>作业/任务量</strong></p> <p>作业次数不多, 但是每次作业都有较难的题, 需要多花一些时间认真思考.</p> <p><strong>考试</strong></p> <p>老师的考试方式也是很有特点, 考试类似简单的数学课考试, 所以吸引了很多数学, 物理, 信科学院的同学选修.</p> <p>不过如果对考试非常有信心, 是可以冲击彩虹的, 我仅使用了自己记的笔记就拿到了彩虹, 没有使用其它的参考资料, 欢迎参考!</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Game_Theory-ll-2023Fall-PKU">博弈论资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>课件</li> <li>带有笔记的课件 (我的主要贡献是给老师较为简陋的 slides 上记录了非常详尽的笔记, 基本上都是根据老师口述所整理的, 感觉对这门课的学习会有非常大的帮助)</li> <li>课程作业</li> <li>一些相关资源 (包括往年的考试和往年带有答案的作业题)</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>100</p> <h3>魅力化学</h3> <p>黄建滨 2022秋</p> <p><strong>课程听感</strong></p> <p>老师风趣幽默, 每节课会请不同方向的教授来做讲座, 每节课课前会发一个有两三道题的小测, 听完讲座交上去, 用作签到.</p> <p><strong>作业/任务量</strong></p> <p>一篇期末论文</p> <p><strong>考试</strong></p> <p>没有考试</p> <p><strong>相关资料</strong></p> <p><a href="https://www.lyt0112.com/blog/crystal-zh">我的魅力化学课程论文</a></p> <p><strong>成绩</strong></p> <p>97</p> <p>唯一一个上 90 的论文课... 想必是论文写出了真情实感吧🥹</p> <h3>计算机系统导论</h3> <p>管雪涛 2022秋</p> <p>2024.09.05 Update: 兹喜闻zzy同学当选为24届27班ICS助教, 特此表示热烈祝贺!</p> <p><strong>课程听感</strong></p> <p>这门课的课程测评很多了, 就不重复说了.</p> <p>在此推荐唯一真神: <a href="https://arthals.ink/blog/data-lab">更适合北大宝宝体质的 XXX Lab 踩坑记</a></p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Introduction_to_Computer_System_ICS-gxt-2022Fall-PKU">计算机系统导论资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>所有lab的满分解答 (针对2022年版本的labs, 由于包含面向样例优化, 之后的年份可能由于测试样例的改变导致性能急剧下降, 比如下降到80分左右)</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>94</p> <p>历史成绩不具备现实意义.</p> <h3>数据结构与算法 (A)</h3> <p>邹磊 2022秋</p> <p><strong>课程听感</strong></p> <p>中规中矩, 感觉看看 slides 就可以了. 对于学习巩固算法知识还是有用的.</p> <p><strong>作业/任务量</strong></p> <p>中规中矩, 每一章有一些算法题和几道书面算法题, 尽量熟练使用 STL 可以提高编程效率.</p> <p><strong>考试</strong></p> <p>期中考试:</p> <p>期中是线下考试, 大部分就是正常的算法模拟题, 拟合一下往年题就好了</p> <p>期末考试:</p> <p>线上考试, 不具有参考意义. 但是是根据样例通过个数给分, 与之前的程设和计算概论都不同.</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Data_Structures_And_Algorithms_A-zl-2022Fall-PKU/">数据结构与算法资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>上机作业题</li> <li>书面作业题</li> <li>往年考试题</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>91</p> <p>历史成绩不具备现实意义.</p> <h3>中级微观经济学 (Legacy)</h3> <p>秦晋 2023秋</p> <p>Update 2024.09.25: 看老师在朋友圈发了一暑假照片哈哈哈</p> <p>Update 2024.06.06: 听说老师要走了, 真的很可惜, 虽然在考试和难度方面有争议, 但是老师讲的还是很认真的, 也对教书这件事情很热情. 希望老师能找到可以实现理想的地方.</p> <p><strong>课程听感</strong></p> <p>非常不错, Dr.J 讲课条理清晰, 用填空的形式带领补全思维链条, 微观经济学本身就有清晰的理论依据, 这更使得这门课听起来简洁明了. 如果学过吴泽南的经济学原理, 那么这门课的内容大部分是在经济学原理中已经讲授过的, 所以给我一种在复习经济学原理的错觉(x</p> <p><strong>作业/任务量</strong></p> <p>作业不难, 可能偶尔有一两道比较tricky的问题</p> <p><strong>考试</strong></p> <p>出分之后在树洞上引起了不小的讨论, 主要是在讨论这样给分是否合理. 由于调分力度很大, 树洞里大量的彩虹和 84.5 样本说明成绩分布有极端化的趋势, 我觉得在调分的时候适当引入一些梯度可以更好评价每一位同学的付出程度. 当然无论如何调分力度都很大, 期末是助教出题, 题目较难, 但是最后的成绩很满意!</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Intermediate_Microeconomics-qj-2023Fall-PKU">中级微观经济学资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>填补完成的课程笔记</li> <li>课程作业</li> <li>一些期末模拟题以供训练</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>100</p> <p>历史成绩不具备现实意义.</p> <h2>春季学期课程</h2> <h3>计算机视觉导论</h3> <p>王鹤 2024春</p> <p>2024.07.12 Update: 出分哩, 大三结束!</p> <p>2024.06.18 Update: PDF 格式的笔记在 GitHub 上作为 <code>Releases</code> 发布</p> <p><strong>Github 仓库所有笔记更新完毕, 完结撒花!!!</strong></p> <p>2024.06.08 Update: Embodied AI 相关笔记</p> <p>2024.06.01 Update: Generative Model 相关笔记</p> <p>2024.05.25 Update: Detection and Instance Segmentation 相关笔记</p> <p>2024.05.18 Update: Transformer 相关笔记</p> <p><strong>课程听感</strong></p> <p>(以下是在课程笔记前写的前言)</p> <p>作为北京大学信息科学技术学院的学生, 长期以来饱受糟糕课程质量, 糟糕课程作业, 糟糕考试难度的折磨. 比如算法设计与分析的等课程的教学质量极低, 教考分离, ICS 考试一面黑板的考试错误题目订正等等. 在这样的环境下, 遇到了王鹤老师开设的计算机视觉导论课程, 这门课程的内容丰富, 作业质量高, 考试难度适中, 称得上是精品课程 (与算分这种国家精品课程相区别) .</p> <p>王鹤老师将计算机视觉的发展脉络呈现给大家, 在这个深度学习时代, 老师并没有完全忽视传统 CV 的方法, 而是挑选了其中具有代表性的工作, 这些工作为深度学习时代的 CV 打下了良好的基础, 提供了许多基础工具和数据集的构建方式. 同时老师也更加注重深度学习的基础知识, 如 BatchNorm 的特性和与其他 Norm 的区别, 许多人仅仅只是会 PyTorch 的积木搭建, 但是对于这些基础知识的原理和性质却不甚了解, 导致在实际使用中遇到问题时无法解决, 王老师在这方面往往提出 intuitive 的问题, 引人深思.</p> <p>我是在大三下学期选修了这门课程, 即使我已经具有了一定的深度学习基础, 但是我仍然很享受上课 (看回放) 的过程, 因为对于许多已经了解的知识, 王老师会再度给出解释, 总是让我在同一个地方有不同的收获.</p> <p>我在本学期期中考试之前偶然了解到曾经有学长撰写了一本笔记, 但是许多内容已经进行了 更新或者删改, 因此我联系上林晓疏 (笔名) 学长, 获取了这份笔记的源代码, 并在此基础上进行更新, 以飨后人.</p> <p>该笔记按照讲授先后顺序进行排列, 但是章节编排按照知识结构划分, 因此章节划分可能与课程进度有所不同. 同时本笔记不能替代课程, 只是对这部分知识的总结和思考, 建议与课程回放配合食用.</p> <p><strong>作业/任务量</strong></p> <p>作业是四次 lab , 没有其它作业, 对我来讲周更笔记算是比较有趣的事情, 一边看回放一边记记笔记需要两三个小时, 预计总时长会在25小时左右 (更新完之后发现总时长在35小时左右) .</p> <p>Lab1</p> <p>都不能使用 for 循环</p> <ol> <li>实现卷积, 包括 pedding , 使用 Toeplitz Matrix 实现卷积, 使用 Sliding Window 实现卷积</li> <li>实现 Canny Edge Detector, 包括包括 NMS 和 Edge Linking with Hysteresis Threshold</li> <li>实现 Harris Corner Detector</li> <li>使用 RANSAC 进行平面 fitting</li> </ol> <p>Lab2</p> <ol> <li>手工实现反向传播 (不是很要求矩阵求导, 考试也不考察矩阵求导)</li> <li>手工实现 Batch Norm</li> <li>使用前两问的函数在 Cifar-10 上训练一个 CNN</li> <li>使用 PyTorch 实现一个 CNN</li> </ol> <p>Lab3</p> <p>除了 Marching Cube 都不能使用 for 循环</p> <ol> <li>实现相机校准</li> <li>从 depth image 重建点云</li> <li>从 mesh sample 点云, 使用两种 metric 计算点云距离</li> <li>使用 Marching Cube 从 SDF 重建 mesh</li> </ol> <p>Lab4</p> <p>可以使用 for 循环</p> <ol> <li>实现 Point Net</li> <li>Mask RCNN</li> <li>RNN</li> </ol> <p>时间: 3-4个小时</p> <p>lab质量较前三个有所下降, 大概是因为这几个网络复杂度提高了太多了, 想要好好写任务量太大了.</p> <p><strong>考试</strong></p> <p>期中考试</p> <p>还是有一些难度的, cheatsheet实际上用处不大, 记录一些公式或者课上老师口述的例子就够了, 我考试的时候就看了两三次, 还是确认一下我记的名词是不是对的</p> <p>需要对CV的知识和老师上课讲的 insight 比较熟悉才能拿到90+的分数</p> <p>期末考试</p> <p>几个记忆比较深刻的地方</p> <ol> <li>对于 RCNN, Fast RCNN, Faster RCNN 的算法流程要熟悉, 比如具体为什么 Fast RCNN 比 RCNN 快, 快在哪里了</li> <li>Embodied AI 和一些相关知识点我的笔记都有提到</li> <li>SDF 哪边是正数, 因为我有个同学记错了🙂‍↔️</li> <li>Object detection 的 IoU, PR曲线, AP计算模拟</li> </ol> <p>不过大三大四应该是不调分的, 我的原始成绩98.15, 最后还向下取整了🥹</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Introduction_to_Computer_Vision-wh-2024Spring-PKU">计算机视觉导论资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>Latex 格式的课程笔记, 编译好的 PDF 格式笔记可以在 <code>Releases</code> 中下载</li> <li>Lab 及其解答</li> <li>一些相关 Cheatsheet</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>98</p> <h3>计算机组织与体系结构</h3> <p>陆俊林 2024春</p> <p><strong>课程听感</strong></p> <p>老师讲的挺好的, 讲课水平算信科中上等, 并且3学分的课按理来说有一天是奇偶周上课, 但是这一天不用上课, 老师安排自己看MOOC, 所以上起来就像两学分的课.</p> <p><strong>作业/任务量</strong></p> <ol> <li>一次 Report on the EDVAC</li> <li>每周MOOC课后题</li> </ol> <p><strong>考试</strong></p> <p>考试考的是老师上课和MOOC的并集, 所以既需要上课也需要看MOOC, 很抽象.</p> <p>期中考试比较简单, 拟合往年题.</p> <p>期末考试: 我在写这段话的时候刚考完期末, 15道不定项选择题.</p> <p>大题:</p> <ol> <li>读一段小汇编代码</li> <li>流水线分析, 数加入气泡之后总共几个周期, 有点像 ICS 的考试题</li> <li>外部中断的流程填空, 串行和并行数据传输的优缺点, MSI的优缺点</li> <li>经典Burst传输图, 背slides上的图就可以了</li> </ol> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Computer_Architectures-ljl-2024Spring-PKU">计算机组织与体系结构资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>课程讲义 (not available, copyright belongs to Prof. Junlin Lu)</li> <li>MOOC笔记</li> <li>课程作业</li> <li>一些其它资料 (往年考题和考试提纲)</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>85</p> <h3>数据库概论</h3> <p>陈立军 2024春</p> <p><strong>课程听感</strong></p> <p>听感一般, 老师讲课还可以, 但是上课人数是真的越来越少, 我基本上不上课就看回放, 这个学期好像也没有签到.</p> <p>大家都喜欢入主中南海😍🥰</p> <p><strong>作业/任务量</strong></p> <p>六次作业, 五次实习, 虽然每次都借助 ChatGPT 完成, 用不了半天时间, 但是东西还挺多的, 主要是 ChatGPT 面对这种问题答案往往是不对的.</p> <p><strong>考试</strong></p> <p>没有期中考试, 这是好的.</p> <p>期末考试听说会考很多 sides 上面的东西, 过拟合一下可怜的一点点往年题好了.</p> <p>考完之后发现需要好好拟合往年题, 不论是期中还是期末.</p> <p>首先是15道填空, 一个一分, 考的很细致, 比如如何使用关系代数判定函数依赖和多值依赖</p> <p>大题:</p> <ol> <li>五个简答题, 元组关系演算, 期中往年题计算一个SQL查询的结果, 另外的记不清了</li> <li>期中往年题, 关系代数计算, 比如左外链接, 计算最小值, 基础关系运算表示除法, 四个小题还有一个忘了</li> <li>期中往年题, 股票SQL查询</li> <li>第一小题是计算一个比较复杂的函数依赖的候选码, 判断是哪个范式; 第二小题是期末往年题, 给定关系模式 R 和函数依赖集 F, 画出合适的 E-R 图 (提示: 先给出保持函数依赖的分解, 再观察各关系主外码的关系)</li> <li>期中往年题, 篮球比赛ER图</li> <li>视图可串行化+三个并发协议, 看看 slides 上面的例题即可</li> </ol> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Introduction_to_Database_Systems-clj-2024Spring-PKU">数据库概论资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>课程讲义</li> <li>笔记 (基本上包含了老师上课口述的问题和知识, 从 <code>Releases</code> 下载)</li> <li>课程作业 (包含六次作业和五次实习)</li> <li>一些其它资料 (往年考题和考试提纲)</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>89.5</p> <h3>经济学原理 (Ⅱ)</h3> <p>庄晨 2023春</p> <p>Update June 5th, 2024: 祝愿带了我两个学期的经济学原理的李亦丁助教学长在美国的博士研究顺利!</p> <p><strong>课程听感</strong></p> <p>这门课程是庄晨教授在北大第一次授课, 课程听起来难以通过 slides 和老师的口述建立起连贯的知识体系, 或许这也是宏观经济学本身的问题, 不像微观经济学那样有明确的唯一的数学模型.</p> <p>感觉课程难度偏难, 这是因为老师强调经济学直觉, 对于一些问题没有拿出数学工具进行分析, 这就导致在一些宏观问题上有些迷惑, 一知半解.</p> <p><strong>作业/任务量</strong></p> <p>较少, 作业比课程 slides 清楚</p> <p><strong>考试</strong></p> <p>期中期末老师都给出了样例, 可以缓解题目参考较少的焦虑, 助教哥哥姐姐也在考试之前开腾讯会议带大家复习, 讲解考试样例🥰.</p> <p>另外其实可以找找庄晨教授在国外开课的课程讲义等资料作为参考复习.</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Principle_of_Economics_II-zc-2023Spring-PKU">经济学原理 (Ⅱ) 资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>自己总结的课程笔记, 在一些数学推导上下了一些功夫总结, 可供参考</li> <li>隔壁李博班的讲义</li> <li>期中期末的样例题目</li> <li>课程作业 (还被李亦丁学长发到小红书上去了)</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>96</p> <h3>AI引论</h3> <p>刘利斌 2023春</p> <p>Update 2025.02.20: 我来当助教啦</p> <p><strong>课程听感</strong></p> <p>这门课程是在2023年课程改革后的第一年, 比之前的AI引论好了不少 (之前的AI引论纯 flybitch), 在课程结构上更加符合认知规律了. 但是对于比较重要的 deep learning 部分, 和隔壁的 AI 基础相比讲授还是偏少, 期中之前的搜索讲的太多太细致了.</p> <p><strong>作业/任务量</strong></p> <p>作业不多, 但是lab想要满分还是需要一些时间的</p> <p><strong>考试</strong></p> <p>期中期末可以携带一张手写的 cheatsheet, 并且 cheatsheet 会被收走 (猜想可能是为了不让祖传cheatsheet) , 有难度, cheatsheet也用不上. 在此感慨隔壁 AI 基础考试半个小时拿到满分的 <a href="https://arthals.ink">卓宝</a> 同学真是太强了...</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Introduction_to_Artificial_Intelligence-llb-2023Spring-PKU">AI引论资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>自己总结的课程笔记 (较为粗糙, 仅供参考)</li> <li>课程lab解答</li> <li>一些python练习 (许多同学没有python基础)</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>94</p> <h3>程序设计实习</h3> <p>刘家瑛 2022春</p> <p><strong>课程听感</strong></p> <p>这门课程的教学质量算是信科中上水平的, 尤其是刘家瑛老师讲课还是很有趣可爱的, 有的时候还会讲一些关于保研出国的建议.</p> <p>这门课程前半学期是 c++ 类和对象的语法部分, 跟着 openjudge 上面的题目和课件正常学习就好了, 后半学期是算法部分, 对于非竞赛生可能需要多努力一些, 并且学着多使用 STL 会提高不少编程效率.</p> <p>因为疫情原因, 数学考试延期至下学期开学进行, 所以我有充足的时间练习算法题, 这就是仓库里为什么会有那么多算法题的解答.</p> <p><strong>作业/任务量</strong></p> <p>作业就是每周写语法, 算法题, 平时任务量不大, 但是著名的魔兽世界还是需要一些时间完成的, 笔者当时是五一之前上午期中考完试, 下午写的终极版魔兽世界, 对上一版魔兽世界做了非常多的修改, 之后又零零碎碎花了一些时间对拍 debug , 魔兽世界对拍 debug 真是非常好的方法.</p> <p><strong>考试</strong></p> <p>因为是疫情期间线上期末考试, 不太具有参考价值.</p> <p><strong>相关资料</strong></p> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Practice_of_Programming_in_C_and_CPP_cxsjsx-ljy-2022Spring-PKU">程序设计实习资料仓库</a></p> <p>这个仓库包括:</p> <ol> <li>作业</li> <li>课下练习</li> <li>期中整理好的题目, 答案以及一些手写笔记</li> <li>期末考题</li> <li>算法模板整理</li> <li>Qt 大作业</li> </ol> </li> </ol> <p><strong>成绩</strong></p> <p>91</p>https://www.lyt0112.com/blog/operating_systems_note_11-zhhttps://www.lyt0112.com/blog/operating_systems_note_11-zhOperating Systems Notes 11: 死锁Fri, 06 Jun 2025 15:40:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gemini-2.5-pro-preview-06-05</code></p> <p>This article uses LLM to improve efficiency, which can make mistakes. I have tried my best to check and proofread, but still cannot guarantee complete accuracy.</p> <p>For personal use, may be nagging for you.</p> <h2>1. 核心概念</h2> <p>我们首先要对死锁以及与它相关的几个概念有一个清晰的认识。</p> <h3>1.1 并发编程的问题</h3> <p>在复杂的并发程序 (如数据库MySQL、Web服务器Apache等) 中，开发者会遇到各种各样的缺陷。研究表明，这些缺陷主要分为两大类：死锁缺陷和非死锁缺陷 (如原子性违背、顺序错误等) 。其中，非死锁的缺陷占了绝大多数 (约97%) ，但这并不意味着死锁不重要。一旦发生死锁，其后果往往是灾难性的，可能导致整个系统挂起。</p> <h3>1.2 死锁 (Deadlock)</h3> <h4>1.2.1 定义</h4> <p>我们来看两个定义：</p> <ol> <li>一个进程如果正在等待一个永远也不可能为真的条件，那么这个进程就陷入了死锁。</li> <li>在一组进程中，每个进程都在无限期地等待该组中另一个进程所占有的资源，因而永远无法获取到自己所需的资源，这种现象称为<strong>进程死锁</strong>。这组进程就称为<strong>死锁进程</strong>。</li> </ol> <p>简单来说，就是两个或多个进程形成了一个"僵局"，比如进程A等着进程B手里的资源，而进程B又恰好在等进程A的资源，谁也不肯先放手，就这么永远地等下去了。</p> <p><strong>关键结论</strong>:</p> <ul> <li>所有参与死锁的进程都处于<strong>等待</strong>状态。</li> <li>死锁的进程只是当前系统中所有进程的一个子集。</li> </ul> <h4>1.2.2 为什么会发生死锁？</h4> <p>死锁的根源在于<strong>资源</strong>的争夺和不当的分配策略。</p> <ol> <li> <p><strong>资源特性</strong>:</p> <ul> <li><strong>可重用资源 (Reusable Resource)</strong>: 可被多个进程多次使用，不会被消耗掉。例如：CPU、内存、磁盘、文件、数据库、信号量。</li> <li><strong>可消耗资源 (Consumable Resource)</strong>: 只能使用一次，可以被创建和销毁。例如：信号、中断、消息。</li> <li>资源的<strong>数量是有限的</strong>，如果无限，自然就没有争抢了。</li> <li>资源的使用模式通常是"<strong>申请-分配-使用-释放</strong>"。</li> </ul> </li> <li> <p><strong>编程实践中的原因</strong>:</p> <ul> <li><strong>复杂的依赖关系</strong>: 在大型软件中，不同模块间的调用关系复杂，可能在不经意间形成一个锁的循环依赖，导致死锁。</li> <li><strong>封装的副作用</strong>: 模块化编程隐藏了实现细节，这本是好事。但调用者可能不知道一个看似简单的接口内部会去获取某个锁，当多个这样的接口被组合调用时，就可能意外地触发死锁。</li> </ul> </li> </ol> <h3>1.3 活锁 (Livelock)</h3> <p>活锁很有意思，它和死锁很像，但又有所不同。</p> <ul> <li><strong>定义</strong>: 进程没有被阻塞 (Block) ，它们的状态在持续改变，看起来很"活跃"，但却无法向前推进任何有效的工作。</li> <li><strong>例子</strong>: 想象两个人 (进程) 在一条狭窄的走廊相遇，都想给对方让路。A向左让，B也向左让，结果又堵住了；A向右让，B也向右让，又堵住了。两者都在不停地"尝试"和"让步" (状态在改变) ，但就是过不去 (没有进展) 。</li> </ul> <p>在代码中，活锁通常表现为进程在循环中不断尝试获取锁，但因为某些条件 (例如礼让策略) 总是失败。</p> <h3>1.4 饥饿 (Starvation)</h3> <ul> <li><strong>定义</strong>: 一个或多个进程由于资源分配策略不公，导致长时间甚至永远无法获得所需的资源，从而无法向前推进。</li> <li><strong>例子</strong>: 在一个优先级调度系统中，如果总有高优先级的任务到来，那么低优先级的任务可能永远也得不到CPU时间，这就"饿"死了。</li> </ul> <h3>1.5 死锁、活锁与饥饿的区别</h3> <p>| 特征 | 死锁 (Deadlock) | 活锁 (Livelock) | 饥饿 (Starvation) | | :----------- | :--------------------- | :-------------------- | :------------------------- | | <strong>进程状态</strong> | 阻塞 (Waiting/Blocked) | 运行 (Running/Active) | 阻塞或就绪 (Blocked/Ready) | | <strong>系统进展</strong> | 无进展 | 无进展 | 可能有其他进程在进展 | | <strong>原因</strong> | 循环等待资源且不释放 | 错误的重试/礼让逻辑 | 不公平的资源分配策略 |</p> <hr> <h2>2. 死锁的产生</h2> <p>一个系统中要发生死锁，必须<strong>同时</strong>满足以下四个必要条件。只要能破坏其中任意一个，死锁就不会发生。</p> <h3>2.1 四大必要条件</h3> <ol> <li> <p><strong>互斥使用 (Mutual Exclusion)</strong></p> <ul> <li><strong>描述</strong>: 一个资源在同一时刻只能被一个进程使用。如果其他进程请求该资源，则必须等待。</li> <li><strong>本质</strong>: 这是资源本身的固有属性，比如打印机，不可能两个进程同时打印。</li> </ul> </li> <li> <p><strong>占有且等待 (Hold and Wait)</strong></p> <ul> <li><strong>描述</strong>: 进程至少占有一个资源，并且在等待获取其他进程占有的额外资源。</li> <li><strong>例子</strong>: 进程P1占有了资源R1，然后又去请求资源R2，但R2被P2占有。此时P1就处于"占有R1且等待R2"的状态。</li> </ul> </li> <li> <p><strong>不可抢占 (No Preemption)</strong></p> <ul> <li><strong>描述</strong>: 资源不能被强制地从占有它的进程中夺走，只能由占有者在使用完毕后自愿释放。</li> <li><strong>例子</strong>: 一个进程打开了一个文件并持有文件锁，操作系统不能在它主动关闭文件前把这个锁抢走给别人。</li> </ul> </li> <li> <p><strong>循环等待 (Circular Wait)</strong></p> <ul> <li><strong>描述</strong>: 存在一个进程-资源的循环链，P1在等P2的资源，P2在等P3的资源，...，Pn在等P1的资源，形成一个闭环。</li> <li><strong>数学表示</strong>: 存在一个进程集合 ${P_0, P_1, ..., P_n}$，使得 $P_0$ 等待 $P_1$ 持有的资源，$P_1$ 等待 $P_2$ 持有的资源，...，$P_n$ 等待 $P_0$ 持有的资源。</li> </ul> </li> </ol> <hr> <h2>3. 资源分配图 (Resource Allocation Graph - RAG)</h2> <p>为了更直观地描述和分析死锁，我们引入了资源分配图。</p> <h3>3.1 RAG的构成</h3> <p>RAG是一个有向图 $G=(V, E)$，包含两类节点：</p> <ul> <li><strong>进程节点 (P)</strong>: 用圆形表示，如 $P_1, P_2$。</li> <li><strong>资源节点 (R)</strong>: 用方形表示。方框内的点表示该类资源的<strong>实例</strong>数量。例如，一个方框代表"打印机"这类资源，里面的两个点代表有两台打印机。</li> </ul> <p>图中包含两类有向边：</p> <ul> <li><strong>申请边 (Request Edge)</strong>: 从进程指向资源类，表示该进程正在申请该类资源的一个实例。$P_i \rightarrow R_j$。</li> <li><strong>分配边 (Assignment Edge)</strong>: 从资源实例指向进程，表示该资源实例已经被分配给了这个进程。$R_j \rightarrow P_i$。</li> </ul> <h3>3.2 RAG 图例</h3> <p>下面是一些RAG的例子，我们可以用Mermaid流程图来表示它们。</p> <h4>3.2.1 交通路口死锁</h4> <p>十字路口的四个区域可以看作四个资源，四辆车看作四个进程。每辆车都占用了自己当前的路口，同时又想进入前方的路口。</p> <pre><code class="language-mermaid">graph TD P1(P1) --> Ra[Ra] P2(P2) --> Rb[Rb] P3(P3) --> Rc[Rc] P4(P4) --> Rd[Rd] Ra --> P2 Rb --> P3 Rc --> P4 Rd --> P1 </code></pre> <p>这就形成了一个 <code>P1 -> R_a -> P2 -> R_b -> P3 -> R_c -> P4 -> R_d -> P1</code> 的循环等待，导致死锁。</p> <h3>3.3 死锁定理</h3> <p>RAG和死锁之间存在一个重要的关系，我们称之为死锁定理：</p> <ol> <li>如果RAG中<strong>没有环路</strong>，则系统中<strong>一定没有</strong>死锁。</li> <li>如果RAG中<strong>存在环路</strong>，则系统中<strong>可能存在</strong>死锁。 <ul> <li><strong>特殊情况</strong>：如果每个资源类都<strong>只有一个实例</strong>，那么环路是死锁存在的<strong>充分必要条件</strong> (即有环必死锁) 。</li> </ul> </li> </ol> <h4>3.3.1 有环但无死锁的例子</h4> <p>为什么有环路却"可能"没有死锁呢？这通常用来阐明在每类资源拥有多个实例的情况下，<strong>环路是死锁的必要不充分条件</strong>。看下面这个例子。</p> <pre><code class="language-mermaid">graph TD R1["R1 (2)"] R2["R2 (2)"] P1(P1) P2(P2) P3(P3) P4(P4) R2 --"持有"--> P1 R1 --"持有"--> P2 R1 --"持有"--> P3 R2 --"持有"--> P4 P1 --"请求"--> R1 P3 --"请求"--> R2 </code></pre> <p>在这个图中，存在环路 <code>P1 → R1 → P3 → R2 → P1</code>。</p> <p>虽然图中存在一个 <code>P1 → R1 → P3 → R2 → P1</code> 的循环等待，但我们可以通过一个简单的推演 (这其实就是资源图化简法的思路) 发现，系统仍然可以找到一个让所有进程都完成的执行序列，因此没有死锁：</p> <ol> <li> <p>我们观察到进程 <code>P2</code> 和 <code>P4</code>。它们虽然持有资源，但<strong>没有请求任何新资源</strong> (即没有从它们出发的指向资源框的请求边) 。这意味着它们不处于等待状态，可以顺利执行完毕并释放资源。</p> </li> <li> <p><strong>P2 (或 P4) 先完成</strong>：假设 <code>P2</code> 先执行完毕，它会释放它持有的1个 <code>R1</code> 资源实例。</p> <ul> <li>此时，系统可用的 <code>R1</code> 资源变为1个 (<code>Available R1 = 1</code>)。</li> </ul> </li> <li> <p><strong>P1的请求被满足</strong>：<code>P1</code> 一直在等待 <code>R1</code>。现在系统有可用的 <code>R1</code> 了，于是就可以把这个 <code>R1</code> 实例分配给 <code>P1</code>。</p> <ul> <li><code>P1</code> 获得了所需的全部资源 (它原来持有的<code>R2</code>和新获得的<code>R1</code>) ，可以继续执行直到完成。僵局被打破。</li> </ul> </li> <li> <p><strong>P1完成并释放资源</strong>：<code>P1</code> 完成后，会释放它持有的所有资源：1个 <code>R1</code> 实例和1个 <code>R2</code> 实例。</p> <ul> <li>此时系统中有更多的可用资源。</li> </ul> </li> <li> <p><strong>其他进程相继完成</strong>：<code>P1</code> 释放的 <code>R2</code> 可以满足 <code>P3</code> 的请求，<code>P3</code> 也能完成。<code>P4</code> 本来就可以自己完成。最终，所有进程都能顺利结束。</p> </li> </ol> <p>因为存在一个可以让所有进程都完成的执行序列 (例如 <code>&#x3C;P2, P1, P4, P3></code>) ，所以系统<strong>没有发生死锁</strong>。这个例子完美地说明了：当每个资源类有多个实例时，<strong>资源分配图中存在环路是死锁的必要条件，但不是充分条件</strong>。</p> <h3>3.4 资源分配图化简</h3> <p>我们可以通过一种称为"图化简"的方法来检测死锁。基本思想是：模拟系统资源的分配和释放过程，看看是否能满足所有进程的需求。</p> <p><strong>化简步骤</strong>:</p> <ol> <li>在图中寻找一个既不阻塞 (没有申请边) 也非孤立的进程节点 $P_i$。</li> <li>释放该进程 $P_i$ 所占有的所有资源，抹去所有与它相连的分配边，使其变为孤立节点。这些释放的资源现在可用于满足其他进程的请求。</li> <li>检查这些新释放的资源是否能满足某个正在等待的进程 $P_j$ 的请求。如果可以，将 $P_j$ 的申请边变为分配边。现在 $P_j$ 获得了所需资源，可以继续运行，未来它也会释放所有资源。我们可以把它也看作一个可以被"消去"的节点。</li> <li>重复以上步骤，直到无法再找到可化简的进程。</li> </ol> <p><strong>结论</strong>: 如果最终图中所有的进程都被化简掉 (成为孤立节点) ，则称该图是<strong>可完全化简的</strong>，系统<strong>没有死锁</strong>。反之，如果最后还剩下无法化简的进程节点，则系统存在死锁。</p> <hr> <h2>4. 解决死锁的方法</h2> <p>面对死锁，主要有四大类处理策略：</p> <ol> <li>**忽略该问题 (鸵鸟算法) **: 就像鸵鸟把头埋进沙子里一样，假装问题不存在。适用于发生概率极低，且处理代价远高于其危害的系统。很多主流操作系统 (如Windows, UNIX) 都采用此策略，它们假设死锁不会发生，将处理死锁的责任留给了程序员。</li> <li><strong>死锁预防 (Deadlock Prevention)</strong>: 在系统设计时，通过施加某些限制，从根本上破坏死锁产生的四个必要条件之一。这是一种<strong>静态</strong>策略。</li> <li><strong>死锁避免 (Deadlock Avoidance)</strong>: 在系统运行时，动态地跟踪资源分配，每当有资源请求时，先判断分配后是否会导致系统进入"不安全状态"。如果会，则拒绝分配。这是一种<strong>动态</strong>策略。</li> <li><strong>死锁检测与解除 (Deadlock Detection and Recovery)</strong>: 允许死锁发生，但系统有能力检测到它，并采取措施 (如剥夺资源、终止进程) 来解除死锁。</li> </ol> <h3>4.1 死锁预防</h3> <p>这是最直接的思路，即破坏四个必要条件中的一个。</p> <h4>4.1.1 破坏"互斥使用"</h4> <ul> <li><strong>思路</strong>: 让资源变得可共享，而不是独占。</li> <li><strong>方法</strong>: <strong>资源转换技术</strong>。一个典型的例子是 <strong>SPOOLing 技术</strong> (Simultaneous Peripheral Operations On-Line)。以打印机为例，它本身是独占设备。但系统可以设立一个打印机守护进程 (daemon) ，所有进程不直接访问打印机，而是将打印内容发送给这个 daemon 进程，由 daemon 统一管理打印队列。这样，对于进程来说，它们访问的"打印服务"是共享的，不会被阻塞。</li> </ul> <h4>4.1.2 破坏"占有且等待"</h4> <ul> <li><strong>思路</strong>: 不允许进程在占有资源的同时去等待新资源。</li> <li><strong>方案1</strong>: <strong>一次性申请</strong>。进程在开始运行前，必须一次性地申请它在整个运行过程中所需要的所有资源。只有系统能满足其全部请求时，才分配给它。 <ul> <li><strong>缺点</strong>: 严重降低资源利用率 (一个进程可能很早就申请了某个资源，但很晚才用) ；可能导致"饥饿" (一个需要很多资源的进程可能永远也等不到所有资源都空闲的时刻) 。</li> </ul> </li> <li><strong>方案2</strong>: <strong>释放已有资源</strong>。允许进程动态申请资源，但当它申请的新资源无法被满足时，它必须释放掉已经占有的所有资源。等以后需要时再重新申请。 <ul> <li><strong>缺点</strong>: 大大增加系统开销，进程可能要反复申请和释放资源。</li> </ul> </li> </ul> <h4>4.1.3 破坏"不可抢占"</h4> <ul> <li><strong>思路</strong>: 允许系统强行剥夺已被占有的资源。</li> <li><strong>方法</strong>: 当一个高优先级的进程请求一个被低优先级进程占有的资源时，操作系统可以抢占这个资源。</li> <li><strong>局限性</strong>: 这种方法只适用于那些状态容易保存和恢复的资源，如CPU、内存。对于像打印机这样的设备，你总不能抢占一个打印到一半的任务吧。</li> </ul> <h4>4.1.4 破坏"循环等待"</h4> <ul> <li><strong>思路</strong>: 避免形成等待环路。</li> <li><strong>方法</strong>: <strong>资源有序分配法 (Resource Ordering)</strong>。将系统中所有的资源类型进行线性排序 (例如，R1=1, R2=2, R3=3...) 。然后强制规定：任何进程在申请资源时，都必须严格按照资源编号的<strong>递增顺序</strong>进行申请。</li> <li><strong>为什么能行？</strong>: 假设一个进程已经申请了资源 $R_i$，它接下来只能申请编号大于 $i$ 的资源 $R_j$ ($j > i$)。这样就不可能出现一个进程占有 $R_j$ 反过来去申请 $R_i$ 的情况，从而保证了资源分配图不会出现环路。</li> <li><strong>缺点</strong>: 资源编号需要精心设计，可能会给编程带来不便。</li> </ul> <h3>4.2 死锁避免</h3> <p>死锁避免不像预防那样施加严格的限制，而是更加灵活。它允许前三个条件的存在，但在分配资源时会小心翼翼，确保不会踏入死胡同。这里的核心概念是<strong>安全状态</strong>。</p> <h4>4.2.1 安全状态 (Safe State)</h4> <ul> <li><strong>安全状态</strong>: 如果系统能找到一个<strong>安全序列</strong>，那么系统就处于安全状态。</li> <li><strong>安全序列</strong>: 一个进程序列 <code>$&#x3C;P_1, P_2, ..., P_n>$</code> 是安全的，指的是对于序列中的每一个进程 $P_i$，它未来所需要的最大资源量，可以被<strong>系统当前剩余的资源</strong>加上<strong>所有排在它前面的进程 ($P_j, j\le i$) 所持有的资源</strong>所满足。</li> <li><strong>直白解释</strong>: 安全状态意味着，系统有一种资源分配的调度顺序，可以保证所有进程都能在有限时间内获得所需资源，顺利执行完毕。</li> </ul> <p><strong>状态关系</strong>:</p> <ul> <li>系统状态分为<strong>安全状态</strong>和<strong>不安全状态</strong>。</li> <li><strong>死锁状态</strong> 是一种<strong>不安全状态</strong>。</li> <li><strong>安全状态</strong>一定<strong>没有死锁</strong>。</li> <li><strong>不安全状态</strong> <strong>不一定</strong>会<strong>导致死锁</strong>，只是系统无法再保证能按某种顺序为所有进程分配资源，存在进入死锁的可能性。</li> </ul> <pre><code class="language-mermaid">graph TD A[系统状态] --> B(安全状态) A --> C(不安全状态) C --> D(死锁状态) </code></pre> <h4>4.2.2 银行家算法 (Banker's Algorithm)</h4> <p>就是资源分配图化简法，但是考虑了进程的<strong>最大需求</strong>。</p> <p>这是由Dijkstra提出的最著名的死锁避免算法。它模拟银行家审批贷款的过程：银行家 (操作系统) 在批出贷款 (分配资源) 前，要确保即使这笔钱放出去了，自己手头的资金 (剩余资源) 依然能满足其他客户 (进程) 后续的最大需求，从而保证银行不会倒闭 (系统不会死锁) 。</p> <p><strong>算法所需的数据结构</strong>: 假设有n个进程和m类资源。</p> <ul> <li><code>Available[m]</code>: 一个向量，表示每类资源当前还<strong>可用</strong>的实例数量。</li> <li><code>Max[n][m]</code>: 一个矩阵，表示每个进程对每类资源<strong>最大</strong>的需求量。</li> <li><code>Allocation[n][m]</code>: 一个矩阵，表示每个进程当前已<strong>分配</strong>到的每类资源的实例数量。</li> <li><code>Need[n][m]</code>: 一个矩阵，表示每个进程<strong>还需</strong>要的每类资源的实例数量。 <ul> <li>这个矩阵是推算出来的：<code>Need[i][j] = Max[i][j] - Allocation[i][j]</code></li> </ul> </li> </ul> <p><strong>算法核心</strong>:</p> <ol> <li> <p><strong>资源请求</strong>: 当进程 $P_i$ 请求资源 <code>Request[i]</code> 时： a. 检查请求是否合法：<code>Request[i] &#x3C;= Need[i]</code>？如果一个进程请求的超过了它声明的最大需求，则为非法请求。 b. 检查系统是否有足够资源：<code>Request[i] &#x3C;= Available</code>？如果没有，进程必须等待。 c. <strong>假装分配</strong>: 如果前两步都通过，系统<strong>暂时</strong>将资源分配给它，并更新数据结构：</p> <ul> <li><code>Available = Available - Request[i]</code></li> <li><code>Allocation[i] = Allocation[i] + Request[i]</code></li> <li><code>Need[i] = Need[i] - Request[i]</code> d. <strong>安全检查</strong>: 调用<strong>安全性算法</strong>，检查分配后的新状态是否安全。</li> <li>如果安全，则正式完成分配。</li> <li>如果不安全，则撤销刚才的"假装分配"，恢复到原来的状态，让进程 $P_i$ 等待。</li> </ul> </li> <li> <p><strong>安全性算法</strong>: a. 初始化工作向量 <code>Work = Available</code>，和完成标记 <code>Finish[n]</code> (所有元素为<code>false</code>) 。 b. 从进程中寻找一个满足以下两个条件的进程 $P_i$：</p> <ul> <li><code>Finish[i] == false</code> (还没执行完)</li> <li><code>Need[i] &#x3C;= Work</code> (它需要的资源小于等于系统当前可用的资源) c. 如果找不到这样的进程，直接跳到第 e 步。 d. 如果找到了 $P_i$，则假设它执行完毕并释放所有资源。更新 <code>Work</code> 和 <code>Finish</code>：</li> <li><code>Work = Work + Allocation[i]</code></li> <li><code>Finish[i] = true</code></li> <li>返回第 b 步，继续寻找下一个可以满足的进程。 e. 检查 <code>Finish</code> 数组，如果所有元素都为 <code>true</code>，则说明系统处于<strong>安全状态</strong>。否则，为<strong>不安全状态</strong>。</li> </ul> </li> </ol> <h4>4.2.3 银行家算法应用示例1</h4> <ul> <li><strong>状态</strong>: 1类资源，总量12。P1, P2, P3。</li> </ul> <p>| 进程 | 目前占有量 | 最大需求量 | 尚需要量 (Need) | | :--- | :--------: | :--------: | :-------------: | | P1 | 1 | 4 | 3 | | P2 | 4 | 6 | 2 | | P3 | 5 | 8 | 3 |</p> <ul> <li><strong>系统剩余量 (Available)</strong>: <code>12 - (1+4+5) = 2</code></li> </ul> <p><strong>安全性检查</strong>:</p> <ol> <li><code>Work = 2</code>, <code>Finish = [F, F, F]</code></li> <li><strong>找 $P_i$ s.t. $Need[i] \leq Work$</strong>: <ul> <li>P1: <code>Need=3 > Work=2</code> (不行)</li> <li>P2: <code>Need=2 &#x3C;= Work=2</code> (<strong>可以！</strong>)</li> <li>P3: <code>Need=3 > Work=2</code> (不行)</li> </ul> </li> <li><strong>模拟P2执行</strong>: <ul> <li><code>Work = Work + Allocation[P2] = 2 + 4 = 6</code></li> <li><code>Finish = [F, T, F]</code></li> </ul> </li> <li><strong>回到第2步，用新的Work=6找</strong>: <ul> <li>P1: <code>Need=3 &#x3C;= Work=6</code> (<strong>可以！</strong>)</li> </ul> </li> <li><strong>模拟P1执行</strong>: <ul> <li><code>Work = Work + Allocation[P1] = 6 + 1 = 7</code></li> <li><code>Finish = [T, T, F]</code></li> </ul> </li> <li><strong>回到第2步，用新的Work=7找</strong>: <ul> <li>P3: <code>Need=3 &#x3C;= Work=7</code> (<strong>可以！</strong>)</li> </ul> </li> <li><strong>模拟P3执行</strong>: <ul> <li><code>Work = Work + Allocation[P3] = 7 + 5 = 12</code></li> <li><code>Finish = [T, T, T]</code></li> </ul> </li> </ol> <p><strong>结论</strong>: 由于所有进程的 <code>Finish</code> 标记都为 <code>true</code>，所以<strong>当前状态是安全的</strong>。一个安全序列是 <code>&#x3C;P2, P1, P3></code>。</p> <h4>4.2.4 银行家算法应用示例2</h4> <ul> <li><strong>状态</strong>: 5个进程 (P1-P5)，3类资源 (A,B,C)。</li> </ul> <p>| | 已分配 (Allocation) | 最大需求 (Max) | 尚需要 (Need) | | :----- | :-----------------: | :------------: | :-----------: | | | A B C | A B C | A B C | | <strong>P1</strong> | 0 1 0 | 7 5 3 | 7 4 3 | | <strong>P2</strong> | 2 0 0 | 3 2 2 | 1 2 2 | | <strong>P3</strong> | 3 0 2 | 9 0 2 | 6 0 0 | | <strong>P4</strong> | 2 1 1 | 2 2 2 | 0 1 1 | | <strong>P5</strong> | 0 0 2 | 4 3 3 | 4 3 1 |</p> <ul> <li><strong>剩余资源 (Available)</strong>: A=3, B=3, C=2</li> </ul> <p><strong>问题1：此状态是否安全？</strong></p> <ol> <li><code>Work = [3, 3, 2]</code>, <code>Finish = [F, F, F, F, F]</code></li> <li><strong>找 $P_i$ s.t. $Need[i] \leq Work$</strong>: <ul> <li>P1: <code>[7,4,3] > [3,3,2]</code> (不行)</li> <li>P2: <code>[1,2,2] &#x3C;= [3,3,2]</code> (<strong>可以！</strong>) -> 找到 P2。</li> </ul> </li> <li><strong>模拟P2执行</strong>: <ul> <li><code>Work = [3,3,2] + [2,0,0] = [5,3,2]</code></li> <li><code>Finish = [F, T, F, F, F]</code></li> </ul> </li> <li><strong>用新的Work=[5,3,2]找</strong>: <ul> <li>P1: <code>[7,4,3] > [5,3,2]</code> (不行)</li> <li>P3: <code>[6,0,0] > [5,3,2]</code> (不行)</li> <li>P4: <code>[0,1,1] &#x3C;= [5,3,2]</code> (<strong>可以！</strong>) -> 找到 P4。</li> </ul> </li> <li><strong>模拟P4执行</strong>: <ul> <li><code>Work = [5,3,2] + [2,1,1] = [7,4,3]</code></li> <li><code>Finish = [F, T, F, T, F]</code></li> </ul> </li> <li><strong>用新的Work=[7,4,3]找</strong>: <ul> <li>P1: <code>[7,4,3] &#x3C;= [7,4,3]</code> (<strong>可以！</strong>) -> 找到 P1。</li> </ul> </li> <li><strong>模拟P1执行</strong>: <ul> <li><code>Work = [7,4,3] + [0,1,0] = [7,5,3]</code></li> <li><code>Finish = [T, T, F, T, F]</code></li> </ul> </li> <li><strong>用新的Work=[7,5,3]找</strong>: <ul> <li>P3: <code>[6,0,0] &#x3C;= [7,5,3]</code> (<strong>可以！</strong>) -> 找到 P3。</li> </ul> </li> <li><strong>模拟P3执行</strong>: <ul> <li><code>Work = [7,5,3] + [3,0,2] = [10,5,5]</code></li> <li><code>Finish = [T, T, T, T, F]</code></li> </ul> </li> <li><strong>用新的Work=[10,5,5]找</strong>: <ul> <li>P5: <code>[4,3,1] &#x3C;= [10,5,5]</code> (<strong>可以！</strong>) -> 找到 P5。</li> </ul> </li> <li><strong>模拟P5执行</strong>: <ul> <li><code>Work = [10,5,5] + [0,0,2] = [10,5,7]</code></li> <li><code>Finish = [T, T, T, T, T]</code></li> </ul> </li> </ol> <p><strong>结论</strong>: 是安全状态。一个安全序列为 <code>&#x3C;P2, P4, P1, P3, P5></code>。</p> <p><strong>问题2：P1申请(0,2,0)能否分配？</strong></p> <ol> <li><strong>检查请求</strong>: <ul> <li><code>Request_P1 = [0,2,0] &#x3C;= Need_P1 = [7,4,3]</code> (合法)</li> <li><code>Request_P1 = [0,2,0] &#x3C;= Available = [3,3,2]</code> (有资源)</li> </ul> </li> <li><strong>假装分配</strong>: <ul> <li><code>Available = [3,3,2] - [0,2,0] = [3,1,2]</code></li> <li><code>Allocation_P1 = [0,1,0] + [0,2,0] = [0,3,0]</code></li> <li><code>Need_P1 = [7,4,3] - [0,2,0] = [7,2,3]</code></li> </ul> </li> <li><strong>用新状态进行安全检查</strong>: <ul> <li><code>Work = [3,1,2]</code>, <code>Finish = [F,F,F,F,F]</code></li> <li>P1: <code>[7,2,3] > [3,1,2]</code> (不行)</li> <li>P2: <code>[1,2,2] > [3,1,2]</code> (不行)</li> <li>P3: <code>[6,0,0] > [3,1,2]</code> (不行)</li> <li>P4: <code>[0,1,1] &#x3C;= [3,1,2]</code> (<strong>可以！</strong>) -> 找到 P4</li> <li><code>Work = [3,1,2] + [2,1,1] = [5,2,3]</code></li> <li><code>Finish = [F,F,F,T,F]</code></li> <li><strong>用新的Work=[5,2,3]找</strong>:</li> <li>P1: <code>[7,2,3] > [5,2,3]</code> (不行)</li> <li>P2: <code>[1,2,2] &#x3C;= [5,2,3]</code> (<strong>可以！</strong>) -> 找到 P2</li> <li><code>Work = [5,2,3] + [2,0,0] = [7,2,3]</code></li> <li><code>Finish = [F,T,F,T,F]</code></li> <li><strong>用新的Work=[7,2,3]找</strong>:</li> <li>P1: <code>[7,2,3] &#x3C;= [7,2,3]</code> (<strong>可以！</strong>) -> 找到 P1</li> <li>... 后续可以完成。</li> </ul> </li> </ol> <p><strong>结论</strong>: 可以分配。安全序列存在。</p> <h3>4.3 死锁检测与解除</h3> <p>这种策略不预防也不避免，而是采取"亡羊补牢"的方式。</p> <h4>4.3.1 死锁检测</h4> <ul> <li><strong>何时检测</strong>: <ol> <li>当有进程因资源请求失败而阻塞时。 (开销大)</li> <li>定时检测，比如每隔一段时间。</li> <li>当系统资源利用率明显下降时，可能是死锁的征兆。</li> </ol> </li> <li><strong>检测算法</strong>: <ul> <li>最常用的方法是维护一个<strong>等待图 (Wait-for Graph)</strong>，它是资源分配图的简化版，只包含进程节点。</li> <li>如果 $P_i$ 正在等待 $P_j$ 持有的资源，就在图中画一条从 $P_i$ 到 $P_j$ 的边。</li> <li>然后，在等待图中运行<strong>环路检测算法</strong>。如果发现环路，就意味着系统存在死锁。</li> </ul> </li> </ul> <h4>4.3.2 死锁解除 (恢复)</h4> <p>一旦检测到死锁，就需要采取措施打破僵局。代价越小越好。</p> <ol> <li><strong>撤销所有死锁进程</strong>: 最简单粗暴，但代价巨大，所有进程的工作成果都丢失了。</li> <li><strong>进程回退 (Rollback)</strong>: 利用系统的检查点 (Checkpoint) 机制，让死锁的进程回退到某个未发生死锁的先前状态，然后重新执行。</li> <li><strong>逐一撤销死锁进程</strong>: 按照某种原则 (如进程优先级、已执行时间、占有资源多少等) 选择一个"牺牲品"进程并终止它，释放其资源。然后再次检测死锁，如果还存在，再撤销下一个，直到死锁解除。</li> <li><strong>逐一抢占资源</strong>: 同样按某种原则，从一个死锁进程中抢占部分资源分配给其他进程，以打破环路。被抢占资源的进程必须回退到安全状态。</li> </ol> <hr> <h2>5. 经典问题：哲学家就餐问题</h2> <p>这个问题是Dijkstra提出的一个经典的并发同步问题，用以说明死锁。</p> <h3>5.1 问题描述</h3> <ul> <li>五个哲学家围坐在一张圆桌旁。</li> <li>每人面前一盘意面，每两人之间放着一只筷子，共五只。</li> <li>哲学家的动作是：思考 -> 感到饥饿 -> 拿筷子吃饭 -> 放下筷子 -> 继续思考。</li> <li><strong>规则</strong>: 必须同时拿到左右两边的两只筷子才能吃饭。</li> </ul> <h3>5.2 解决方案分析</h3> <h4>方案1：朴素的信号量解法</h4> <p>每个筷子是一个信号量。哲学家<code>i</code>先拿左边的筷子<code>fork[i]</code>，再拿右边的<code>fork[(i+1)%5]</code>。</p> <pre><code class="language-c">// 伪代码 void philosopher(int i) { while(true) { think(); P(fork[i]); // 拿左筷子 P(fork[(i+1) % 5]); // 拿右筷子 eat(); V(fork[(i+1) % 5]); // 放右筷子 V(fork[i]); // 放左筷子 } } </code></pre> <ul> <li><strong>问题</strong>: <strong>会发生死锁</strong>。如果五个哲学家同时感到饥饿，并同时拿起自己左手边的筷子，那么他们每个人都将永远等待自己右手边的筷子，而那只筷子正被邻座拿着。这就形成了循环等待。</li> </ul> <h4>方案2：使用管程 (Monitor)</h4> <p>将获取和释放筷子的操作封装在管程内部。但幻灯片中给出的<code>get_forks</code>实现是有问题的，它依然是顺序地申请左右筷子，如果获取左筷子后在等待右筷子时被阻塞，同样会造成死锁，并没有解决根本问题。一个正确的管程实现需要能<strong>原子地</strong>检查并获取两只筷子。</p> <h4>方案3：状态数组法 (推荐)</h4> <p>这是 Tanenbaum 提出的一个经典解法，可以避免死锁和饥饿。</p> <ul> <li><strong>核心思想</strong>: 引入<code>state</code>数组记录每个哲学家的状态 (思考、饥饿、进食) 。一个哲学家只有在他<strong>左右两边的邻居都没有在进食</strong>时，才允许他从"饥饿"状态转为"进食"状态。这个检查和状态转换是<strong>原子</strong>的 (通过<code>mutex</code>互斥锁保护) 。</li> </ul> <pre><code class="language-c">// 伪代码 #define N 5 #define THINKING 0 #define HUNGRY 1 #define EATING 2 int state[N]; semaphore mutex = 1; // 保护对state数组的访问 semaphore s[N] = {0}; // 每个哲学家一个信号量，用于阻塞 void philosopher(int i) { while(true) { think(); take_forks(i); // 核心逻辑 eat(); put_forks(i); // 核心逻辑 } } void take_forks(int i) { P(mutex); // 进入临界区 state[i] = HUNGRY; test(i); // 尝试获取筷子 V(mutex); // 退出临界区 P(s[i]); // 如果不能吃，则在此阻塞 } void put_forks(int i) { P(mutex); // 进入临界区 state[i] = THINKING; test((i+N-1) % N); // 检查左邻居能否开吃 test((i+1) % N); // 检查右邻居能否开吃 V(mutex); // 退出临界区 } void test(int i) { // 如果哲学家i饿了，并且左右邻居都没在吃 if (state[i] == HUNGRY &#x26;&#x26; state[(i+N-1) % N] != EATING &#x26;&#x26; state[(i+1) % N] != EATING) { state[i] = EATING; V(s[i]); // 唤醒哲学家i (如果他被阻塞了) } } </code></pre> <ul> <li><strong>优点</strong>: 这个方案不会死锁，因为获取筷子的条件是两只都可用。同时，通过<code>test</code>邻居，它也能保证一定的公平性，避免饥饿。</li> </ul> <h4>方案4：限制就餐人数 (破坏循环等待的变种)</h4> <ul> <li><strong>思想</strong>: 最多只允许 N-1 (即4个) 哲学家<strong>同时</strong>进入餐厅 (尝试拿筷子) 。</li> <li><strong>实现</strong>: 引入一个计数信号量 <code>room</code>，并初始化为4。</li> </ul> <pre><code class="language-c">// 伪代码 semaphore room = 4; // 餐厅最多坐4人 void philosopher(int i) { while(true) { think(); P(room); // 进入餐厅 P(fork[i]); P(fork[(i+1) % 5]); eat(); V(fork[(i+1) % 5]); V(fork[i]); V(room); // 离开餐厅 } } </code></pre> <ul> <li><strong>为什么能行？</strong>: 因为桌上总共5只筷子，4个哲学家最多拿走4x2=8只 (理论上) ，但实际上他们最多一人拿一只，也就是4只筷子。总有1只筷子是空闲的。这意味着，在最坏情况下 (4个哲学家都拿了左手筷子) ，那个没能进入餐厅的第5位哲学家的邻座，总能拿到他右手的筷子，从而吃上饭，吃完释放两只筷子，打破僵局。这实际上破坏了循环等待。</li> </ul> <hr> <h2>6. 思考题解答</h2> <h3>思考题1：画出5个进程陷入死锁的所有非同构模型</h3> <p>这实际上是寻找5个节点的所有强连通有向图的非同构类。我按最小边数和结构复杂度系统分析：</p> <h4>第1类：最小强连通图 (5条边)</h4> <p><strong>模型1: 单个5环</strong></p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P3 --> P4 --> P5 --> P1 </code></pre> <h4>第2类：6条边的强连通图</h4> <p>**模型2: 5环+1条弦 (跨2个节点) **</p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P3 --> P4 --> P5 --> P1 P1 --> P3 </code></pre> <p><strong>模型3: 4环+分支链</strong></p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P3 --> P4 --> P1 P5 --> P2 --> P5 </code></pre> <h4>第3类：7条边的强连通图</h4> <p><strong>模型4: 5环+2条相邻弦</strong></p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P3 --> P4 --> P5 --> P1 P1 --> P3 P2 --> P4 </code></pre> <p><strong>模型5: 5环+2条对称弦</strong></p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P3 --> P4 --> P5 --> P1 P1 --> P3 P3 --> P5 </code></pre> <p>**模型6: 3环+2环 (共享1个节点) **</p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P3 --> P1 P1 --> P4 --> P5 --> P1 </code></pre> <p><strong>模型7: 5环+2条非相邻、非对称弦</strong></p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P3 --> P4 --> P5 --> P1 P1 --> P3 P1 --> P4 </code></pre> <p>**模型8: 双4环结构 (共享1条边) **</p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P3 --> P1 P2 --> P4 --> P5 --> P2 P1 --> P4 </code></pre> <h4>第4类：8条边的强连通图</h4> <p><strong>模型9: 3环+双分支汇聚</strong></p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P3 --> P1 P4 --> P1 P5 --> P1 P1 --> P4 P2 --> P5 </code></pre> <p><strong>模型10: 中心星型+反向环</strong></p> <pre><code class="language-mermaid">graph TD P1 --> P2 P1 --> P3 P1 --> P4 P1 --> P5 P2 --> P3 --> P4 --> P5 --> P2 </code></pre> <p><strong>模型11: 双3环交叉结构</strong></p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P3 --> P1 P3 --> P4 --> P5 --> P3 P2 --> P4 P5 --> P1 </code></pre> <h4>第5类：9条边及以上的复杂结构</h4> <p>**模型12: 准完全图 (缺少部分边的强连通图) **</p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P1 P2 --> P3 --> P2 P3 --> P4 --> P3 P4 --> P5 --> P4 P5 --> P1 --> P5 P1 --> P3 P2 --> P4 P3 --> P5 </code></pre> <p><strong>模型13: 高度连接的复杂图</strong></p> <pre><code class="language-mermaid">graph TD P1 --> P2 --> P3 --> P4 --> P5 --> P1 P1 --> P4 P2 --> P5 P3 --> P1 P4 --> P2 P5 --> P3 </code></pre> <h4>总结</h4> <p>根据图论分析，5个节点的强连通有向图共有<strong>13种</strong>主要的非同构类。这些结构可以按边数分类：</p> <ul> <li><strong>5条边</strong>: 1种 (单5环)</li> <li><strong>6条边</strong>: 2种</li> <li><strong>7条边</strong>: 5种</li> <li><strong>8条边</strong>: 3种</li> <li><strong>9条边及以上</strong>: 2种典型结构</li> </ul> <p>每种结构都代表了一种可能的5进程死锁模式，死锁问题的复杂性远超简单的环形等待。</p> <h3>思考题2：学生用"超时"方法解决死锁，该给多少分？</h3> <p><strong>问题</strong>: 进程请求资源时启动计时器。如果因阻塞超时，就"释放"该进程并让它重新执行。</p> <p><strong>我的评价</strong>: 作为老师，我会给这位同学一个<strong>及格分，但不会给高分</strong>。比如 60-70分。</p> <p><strong>优点 (为什么给分)</strong>:</p> <ol> <li><strong>抓住了问题</strong>: 学生意识到了死锁是进程无限等待，并试图通过打破"无限"这个条件来解决问题，思路是对的。</li> <li><strong>提出了一种可行的恢复策略</strong>: 这本质上是一种<strong>死锁解除</strong>机制，通过强制终止 (或重启) 进程来打破等待。在某些实时系统或健壮性要求高的系统中，类似"看门狗"(Watchdog Timer)的机制确实在被使用，防止任务卡死。</li> <li><strong>简单易行</strong>: 实现起来相对简单，不需要复杂的图算法或状态跟踪。</li> </ol> <p><strong>缺点 (为什么不能给高分)</strong>:</p> <ol> <li><strong>治标不治本</strong>: 它没有解决死锁产生的根本原因，只是在死锁发生后进行粗暴的干预。死锁问题依然会反复出现。</li> <li><strong>超时阈值难以确定</strong>: <ul> <li>如果时间设得太<strong>短</strong>，一个正常的、只是计算时间或I/O时间稍长的进程可能会被无辜"杀死"。</li> <li>如果时间设得太<strong>长</strong>，系统可能已经在死锁状态下浪费了大量时间，才被发现。</li> </ul> </li> <li><strong>可能导致活锁</strong>: 想象两个进程总是以同样的时序去申请同样的两个资源，它们可能都会因为超时而被反复重启，然后又在同一点上卡住，再次超时、重启……系统在不停地忙碌，但没有做任何有效的工作，这就是一种活锁。</li> <li><strong>数据一致性问题</strong>: 强行"释放"或重启一个进程，可能会导致它操作的数据处于不一致或损坏的状态。例如，一个事务只完成了一半。这就需要非常复杂的事务和回滚机制来配合，学生的方法里没有提到这一点。</li> <li><strong>效率低下</strong>: 反复重启进程的代价非常高。</li> </ol>https://www.lyt0112.com/blog/operating_systems_note_10-zhhttps://www.lyt0112.com/blog/operating_systems_note_10-zhOperating Systems Notes 10: 经典同步问题Fri, 06 Jun 2025 15:39:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gemini-2.5-pro-preview-06-05</code></p> <p>This article uses LLM to improve efficiency, which can make mistakes. I have tried my best to check and proofread, but still cannot guarantee complete accuracy.</p> <p>For personal use, may be nagging for you.</p> <p>在多道程序环境下, 多个进程并发执行, 它们之间或多或少会存在一些依赖关系. 为了协调这些进程的执行, 确保程序的正确性, 我们需要一套机制来让它们进行通信和同步, 这就是所谓的IPC (Inter-Process Communication) . 本讲聚焦于几种经典的同步问题, 并要求使用信号量 (Semaphore) 的P、V操作或管程 (Monitor) 来解决.</p> <p>本课程我们主要关注以下几个问题：另类PV操作问题、食品供应问题、三峡大坝问题、狒狒过峡谷问题、睡眠理发师问题, 以及最后的一个资源管理问题.</p> <h2>1 解决同步问题的系统方法论</h2> <p>无论是用信号量还是管程, 解决问题的第一步都是相同的：<strong>分析问题本身</strong>.</p> <h3>1.1 分析模型 (与工具无关)</h3> <p>在写任何一行代码之前, 先用自然语言清晰地定义以下三个要素：</p> <ol> <li> <p><strong>识别"角色"(Actors) 和"资源"(Resources)</strong></p> <ul> <li><strong>角色</strong>: 系统中有哪些并发执行的实体？(例如：生产者、消费者、读者、写者、上行船只、东行狒狒)</li> <li><strong>资源</strong>: 它们需要共享和访问什么？(例如：缓冲区、共享数据、船闸、绳索)</li> </ul> </li> <li> <p><strong>定义"规则", 即约束条件 (Constraints)</strong> 这是最关键的一步. 规则分为两类：</p> <ul> <li><strong>互斥 (Mutual Exclusion)</strong>: "在任何时候, 只有<strong>一个</strong>角色能做某件事". 这通常是为了保护共享资源的完整性. <ul> <li><em>例子</em>: 任何时候只能有一个理发师在修改 <code>waiting_chairs</code> 计数器. 任何时候只能有一艘船在使用某一级船闸 <code>gate[i]</code>.</li> </ul> </li> <li><strong>同步 (Synchronization / Condition Synchronization)</strong>: "一个角色必须<strong>等待</strong>某个条件为真才能继续". 这是角色之间的协作和时序关系. <ul> <li><em>例子</em>: 消费者必须<strong>等待</strong>缓冲区里有产品. 理发师必须<strong>等待</strong>有顾客到来. 船只要想上行, 必须<strong>等待</strong>航向没有被下行船只占用.</li> </ul> </li> </ul> </li> </ol> <p>一旦用自然语言把所有"互斥"和"同步"的规则都列出来, 问题就解决了一半. 下一步才是选择工具, 将这些规则"翻译"成代码.</p> <h3>1.2 一个重要的问题</h3> <blockquote> <p>读者可能会提出两个个非常好的问题, 这两个问题意义相反, 但是背后的原因是相同的</p> <ol> <li>在睡眠理发师问题中, <code>customers</code> (现在等待的顾客数) 不也是一个共享变量吗？为什么它被直接实现为一个信号量, 而不是一个受<code>mutex</code>保护的整数？</li> <li>为什么在读者-写者问题中, <code>read_count</code> (正在读取的读者数) 被实现为一个普通整型变量, 而不是一个信号量？</li> </ol> </blockquote> <p>这是一个非常深刻的观察, 它揭示了信号量更强大的本质：<strong>信号量是一种封装了"计数"和"等待"的智能变量.</strong></p> <p>我们选择用信号量直接实现<code>customers</code>, 是因为理发师的同步规则 ("若无顾客则等待") 与信号量的P操作完美匹配. <code>P(customers)</code> 这一个动作就完成了"检查顾客数, 如果为零则睡眠"的全部逻辑.</p> <p>这是一种设计上的抽象和优化. 我们本可以这样做：</p> <pre><code class="language-c++">// 复杂的、非必要的实现 int customers_count = 0; semaphore mutex = 1; semaphore barber_is_sleeping = 0; // 单独的等待工具 // 理发师 P(mutex); if (customers_count == 0) { V(mutex); P(barber_is_sleeping); // 在独立的信号量上等待 } else { ... } </code></pre> <p>但这种实现更繁琐, 引入了更多的变量和复杂性. 直接使用 <code>semaphore customers = 0;</code> 更清晰、更优雅.</p> <p><strong>更精确的指导原则</strong>：</p> <ul> <li>当你的同步规则是简单的 <strong>"等待, 直到某个资源的计数 > 0"</strong> 时, 直接用一个信号量来代表这个资源是最佳实践. 例如：等待顾客(<code>customers</code>)、等待产品(<code>full</code>)、等待空位(<code>empty</code>).</li> <li>当你的同步规则<strong>更复杂</strong>, 需要读取一个计数值并基于它的值执行不同的逻辑分支时 (例如读者-写者问题中的<code>read_count</code>, 你需要在第一个读者进来的时候锁住写者不让他进来, 而这个操作信号量是不支持的) , 你应该使用一个普通整型变量, 并用一个互斥锁来保护它的读写操作.</li> </ul> <h3>1.3 选择工具并进行"翻译"</h3> <h4>1.3.1 方法论一：使用信号量 (P/V 操作)</h4> <p>信号量的核心思想是 <strong>"计数"</strong>. 你把每个约束条件看作一种或多种需要计数的"资源".</p> <ol> <li> <p><strong>翻译「互斥」规则</strong>:</p> <ul> <li><strong>方法</strong>: 为每一个需要互斥访问的共享资源 (或代码段) 定义一个<strong>二元信号量 (mutex)</strong>, 初值为 <strong>1</strong>.</li> <li><strong>模式</strong>: 在临界区代码前 <code>P(mutex)</code>, 在之后 <code>V(mutex)</code>.</li> <li><strong>思考</strong>: "这个信号量代表了进入临界区的'许可', 初始时有1个许可. "</li> </ul> </li> <li> <p><strong>翻译「同步」规则</strong>:</p> <ul> <li><strong>方法</strong>: 为每一个"等待条件"定义一个<strong>通用信号量</strong>, 并问自己：<strong>"这个信号量在计数什么？"</strong> <ul> <li>这个计数代表了角色正在等待的"资源"或"事件"的数量.</li> </ul> </li> <li><strong>确定初值</strong>: 信号量的初值等于系统启动时, 它所计数的资源的<strong>初始数量</strong>. <ul> <li><em>例子 (睡眠理发师)</em>: 顾客等待"空闲的理发师". 系统开始时, 理发师都在睡觉 (不空闲) , 所以 <code>barbers</code> 信号量初值为 <strong>0</strong>. 理发师等待"已到店的顾客". 系统开始时, 没有顾客, 所以 <code>customers</code> 信号量初值为 <strong>0</strong>.</li> <li><em>例子 (食品供应)</em>: 供应者A等待"A食品的空货架". 初始时货架全空, 所以 <code>emptyA</code> 信号量初值为 <strong>m</strong>.</li> </ul> </li> <li><strong>安排 P/V 操作</strong>: <ul> <li><strong>P 操作</strong>: 当一个角色<strong>需要/消耗</strong>一个资源时, 它就执行 <code>P</code> 操作. 如果资源数 (信号量的值) 为0, 它就自动等待. <ul> <li><em>例子</em>: 理发师需要一个顾客, 所以他 <code>P(customers)</code>.</li> </ul> </li> <li><strong>V 操作</strong>: 当一个角色<strong>生产/释放</strong>一个资源时, 它就执行 <code>V</code> 操作, 通知等待者资源增加了. <ul> <li><em>例子</em>: 顾客到店了, 他"生产"了一个"理发请求", 所以他 <code>V(customers)</code>.</li> </ul> </li> </ul> </li> </ul> </li> </ol> <h4>1.3.2 方法论二：使用管程 (Monitor)</h4> <p>管程的核心思想是 <strong>"封装和等待条件"</strong>. 它将共享的所有东西都锁在一个"房间"里, 角色按规则排队进入.</p> <ol> <li> <p><strong>翻译「互斥」规则</strong>:</p> <ul> <li><strong>方法</strong>: 将所有共享变量 (如 <code>countA</code>, <code>up_count</code>, <code>writer_active</code> 等) <strong>全部封装</strong>在一个管程对象内部.</li> <li><strong>思考</strong>: 管程自动保证了所有调用其方法 (过程) 的线程都是互斥的. 你<strong>不再需要</strong>手动创建 <code>mutex</code> 信号量. 这是管程相比信号量的一大优势：<strong>互斥被简化了</strong>.</li> </ul> </li> <li> <p><strong>翻译「同步」规则</strong>:</p> <ul> <li><strong>方法</strong>: 为每一个"等待原因"定义一个<strong>条件变量 (Condition Variable)</strong>. <ul> <li><strong>命名技巧</strong>: 给条件变量起一个能反映"等待者期望什么变为真"的名字. 例如, <code>can_go_east</code> (东行狒狒等待这个条件为真), <code>barber_available</code> (理发师等待这个条件为真).</li> </ul> </li> <li><strong>实现管程过程 (经典模式: <code>while-wait-signal</code>)</strong>: <ul> <li><strong><code>while (condition_is_not_met)</code></strong>: 在管程方法内部, <strong>永远使用 <code>while</code> 循环</strong>来检查等待条件, 而不是 <code>if</code>. 这是因为当你被唤醒时, 你期望的条件可能已经被另一个刚被唤醒的进程改变了. <code>while</code> 确保你继续执行时, 条件一定是满足的.</li> <li><strong><code>wait(condition_variable)</code></strong>: 在 <code>while</code> 循环中, 如果条件不满足, 就调用 <code>wait</code>. 这会<strong>原子地</strong>做两件事：1) 释放管程的锁；2) 在这个条件变量上睡眠.</li> <li><strong><code>signal(c)</code> / <code>broadcast(c)</code></strong>: 当你修改了共享状态后, 问自己："我的修改是否使得某个等待队列的条件成真了？" 如果是, 就调用 <code>signal</code> (唤醒一个) 或 <code>broadcast</code> (唤醒所有) 来通知等待者. <ul> <li><em>例子 (狒狒过峡谷)</em>: 当最后一个东行狒狒离开后 (<code>east_count--</code> 变为 0), 它使得 <code>west_count > 0</code> 这个条件对西行狒狒不再成立, 所以它应该 <code>broadcast(can_go_west)</code> 来唤醒所有等待的西行狒狒, 让它们重新检查.</li> </ul> </li> </ul> </li> </ul> </li> </ol> <h3>1.4 总结与最佳实践</h3> <p>| 特性 | 信号量 (P/V) | 管程 (Monitor) | | :----------- | :---------------------------------- | :---------------------------------------- | | <strong>核心思想</strong> | 计数资源/事件 | 封装状态, 等待条件 | | <strong>互斥实现</strong> | <strong>手动</strong> (使用<code>mutex</code>信号量) | <strong>自动</strong> (由管程结构保证) | | <strong>同步实现</strong> | <strong>隐式</strong> (通过信号量的值) | <strong>显式</strong> (通过条件变量<code>wait/signal</code>) | | <strong>易错点</strong> | 忘记<code>P/V</code>操作, 死锁, 信号量初值设错 | <code>wait</code>条件用<code>if</code>不用<code>while</code>, 忘记<code>signal</code> | | <strong>抽象层级</strong> | 较低, 更接近硬件 | 较高, 更结构化, 易于管理复杂状态 |</p> <h2>2 纯同步问题</h2> <p>纯同步问题是指进程之间仅仅存在执行顺序上的依赖关系, 而没有互斥访问共享资源的需求. 这种依赖关系通常可以用前驱图 (Precedence Graph) 来描述.</p> <h3>2.1 例子：前驱图</h3> <p>下面是前驱图的例子, 箭头代表了进程 (或代码段) 执行的先后顺序. 例如, 从 S 指向 p1 的箭头表示 p1 必须在 S 完成后才能开始.</p> <p><strong>通用前驱图 (General precedence)</strong></p> <pre><code class="language-mermaid">graph TD S --> p1 p1 --> p2 p1 --> p3 p2 --> p4 p3 --> p4 p3 --> p5 p4 --> p6 p5 --> p6 p6 --> p7 p6 --> p8 p7 --> F p8 --> F </code></pre> <p><strong>解法思路</strong>: 解决这类问题的通用方法是, 为每一个前驱关系 (图中的每一条边) 设置一个信号量.</p> <ol> <li><strong>信号量设置</strong>: 对于从进程 $P_i$ 指向 $P_j$ 的每一条边, 都设置一个初始值为0的信号量 $S_{ij}$.</li> <li><strong>进程 $P_i$</strong>: 在 $P_i$ 执行完毕后, 对所有从 $P_i$ 发出的边所对应的信号量执行 <code>V</code> 操作. 例如, 如果 $P_i$ 是 $P_j$ 和 $P_k$ 的前驱, 则 $P_i$ 结尾处需要执行 $V(S_{ij})$ 和 $V(S_{ik})$.</li> <li><strong>进程 $P_j$</strong>: 在 $P_j$ 开始执行前, 对所有指向 $P_j$ 的边所对应的信号量执行 <code>P</code> 操作. 例如, 如果 $P_j$ 的前驱是 $P_i$ 和 $P_k$, 则 $P_j$ 开始处需要执行 $P(S_{ij})$ 和 $P(S_{kj})$.</li> </ol> <p>通过这种方式, 可以保证图中所定义的所有前驱关系都能得到满足.</p> <h2>3 另类P、V操作问题</h2> <h3>3.1 问题描述</h3> <p>有一个系统, 对P、V操作的定义如下：</p> <ul> <li><strong>P(s)</strong>: <pre><code class="language-c++">s.count --; if (s.count &#x3C; 0) { 将本进程插入相应队列末尾等待; } </code></pre> </li> <li><strong>V(s)</strong>: <pre><code class="language-c++">s.count ++; if (s.count &#x3C;= 0) { 从相应等待队列队尾唤醒一个进程, 将其插入就绪队列; } </code></pre> </li> </ul> <p><strong>思考并回答</strong>: a. 这样定义P、V操作是否有问题？ b. 用这样的P、V操作实现N个进程竞争使用某一共享变量的互斥机制. c. 对于b的解法, 有无效率更高的方法. 如有, 试问降低了多少复杂性？</p> <h3>3.2 使用P、V操作的问题解答</h3> <p><strong>a. 这样定义P、V操作是否有问题？</strong></p> <p><strong>答</strong>: 有问题. 关键在于<code>V(s)</code>操作. 标准的<code>V</code>操作在唤醒进程时, 是从等待队列的<strong>队头</strong>唤醒一个进程, 这遵循了"先来先服务" (FCFS) 的原则, 可以保证等待的公平性, 避免某些进程饥饿 (长时间得不到执行) . 而题目中定义的<code>V</code>操作是从<strong>队尾</strong>唤醒进程, 这是一种"后来先服务" (LIFS) 的策略. 这会导致等待时间最长的进程可能一直得不到唤醒, 从而产生<strong>饥饿</strong>现象. 因此, 这种定义是不公平的, 在实际系统中可能会导致严重问题.</p> <p><strong>b. 用这样的P、V操作实现N个进程竞争共享变量的互斥</strong></p> <p><strong>答</strong>: 尽管存在公平性问题, 但我们仍然可以用它来实现互斥. 实现互斥的经典方法是使用一个初值为1的信号量.</p> <pre><code class="language-c++">// 信号量定义 semaphore mutex; mutex.count = 1; // N个进程的执行代码 Process_i() { while(true) { P(mutex); // --- 临界区开始 --- // 访问共享变量 // --- 临界区结束 --- V(mutex); // 非临界区代码 } } </code></pre> <p><strong>工作原理分析</strong>:</p> <ol> <li><code>mutex</code> 信号量的初值为1, 表示允许一个进程进入临界区.</li> <li>第一个进程调用 <code>P(mutex)</code>, <code>mutex.count</code> 变为0, 进程进入临界区.</li> <li>此时若有第二个进程调用 <code>P(mutex)</code>, <code>mutex.count</code> 变为-1, 该进程被阻塞, 并加入等待队列. 之后再来的进程也同样被阻塞.</li> <li>第一个进程完成临界区操作后, 调用 <code>V(mutex)</code>, <code>mutex.count</code> 变为0 (<code>-1+1=0</code>). 因为 <code>mutex.count &#x3C;= 0</code>, 所以会从等待队列的队尾唤醒一个进程.</li> <li>被唤醒的进程进入临界区, 其他进程继续等待. 这样就保证了任意时刻只有一个进程在临界区内, 实现了互斥.</li> </ol> <p><strong>c. 效率和复杂性分析</strong></p> <p><strong>答</strong>: 这里的"效率"可以从两个角度理解：一是算法的执行效率, 二是系统的公平性.</p> <ol> <li> <p><strong>执行效率</strong>: 对于单个P或V操作来说, 无论是从队头还是队尾操作, 其时间复杂度通常都是 $O(1)$. 所以单次操作的执行效率没有太大差别.</p> </li> <li> <p><strong>公平性与系统整体效率</strong>: 标准的队头唤醒 (FIFO) 方式, 其公平性好. 而题目中的队尾唤醒 (LIFO) 方式, 公平性差, 可能导致饥饿. 从系统整体来看, 饥饿现象会降低系统的效率和响应性.</p> </li> </ol> <p><strong>是否有更高效率的方法？</strong> 如果指的是解决互斥问题的效率, 使用信号量本身就是一种非常高效的方法. 关键在于<code>V</code>操作的实现. 标准的、从队头唤醒进程的<code>V</code>操作是更优的实现, 因为它保证了公平性. 所以, <strong>"更高效率"的方法就是使用标准定义的V操作</strong>.</p> <p><strong>降低了多少复杂性？</strong> 从实现上讲, 将队尾唤醒改为队头唤醒, 并没有增加或降低算法本身的实现复杂性. 但是, 它<strong>降低了系统行为的复杂性</strong>. 使用标准的FIFO策略, 我们更容易预测和分析系统的行为, 可以保证进程的等待时间是有限的, 从而避免了饥饿这个复杂且难以处理的问题. 可以说, 它通过保证公平性, 大大降低了系统出现异常行为的风险.</p> <h2>4 食品供货问题</h2> <h3>4.1 问题描述</h3> <p>某商店有两种食品A和B, 最大容量各为 <code>m</code> 个. 商店将A、B两种食品搭配出售 (每次各取一个) . 为保证新鲜, 遵循"先到食品先出售"原则. 有两个食品公司分别不断地供应A和B. 为保证正常销售, 当某种食品的数量比另一种的数量超过 <code>k</code> ($k &#x3C; m$) 个时, 暂停对数量大的食品进货. 试用P、V操作解决同步和互斥关系.</p> <h3>4.2 使用P、V操作的问题解答</h3> <p><strong>1. 关系分析</strong></p> <ul> <li><strong>互斥关系</strong>: 商店的库存 (食品A和B的数量) 是共享变量, 所有进程 (供应A、供应B、销售) 在修改库存数量时都必须互斥. 我们可以用一个信号量 <code>mutex</code> 来实现.</li> <li><strong>同步关系</strong>: <ul> <li><strong>销售员</strong>: 必须等到商店里同时有食品A和食品B时才能进行销售.</li> <li><strong>供应A</strong>: 当A的数量已满(<code>m</code>个)时, 或当A比B多<code>k</code>个时, 需要暂停供应.</li> <li><strong>供应B</strong>: 当B的数量已满(<code>m</code>个)时, 或当B比A多<code>k</code>个时, 需要暂停供应.</li> </ul> </li> </ul> <p><strong>2. 信号量设置</strong></p> <ul> <li><code>mutex</code>: 互斥信号量, 保护对库存数量的访问, 初值为 1.</li> <li><code>emptyA</code>, <code>emptyB</code>: 表示A和B的空闲货架数, 初值均为 <code>m</code>. 用于控制库存上限.</li> <li><code>foodA</code>, <code>foodB</code>: 表示已有的A和B食品数量, 初值均为 0. 用于销售员判断是否可以销售.</li> <li><code>limitA</code>: 控制"A比B数量多k个"的限制. 当A比B多<code>k</code>个时, A的供应者需要等待. 可以看作是A相对于B的"空闲容量". 初值为 <code>k</code>.</li> <li><code>limitB</code>: 控制"B比A数量多k个"的限制. 同理, 初值为 <code>k</code>.</li> </ul> <p><strong>3. 伪代码实现</strong></p> <pre><code class="language-c++">// 共享变量 int countA = 0, countB = 0; // 食品数量 // 信号量 semaphore mutex = 1; semaphore emptyA = m, emptyB = m; semaphore foodA = 0, foodB = 0; semaphore limitA = k, limitB = k; // A比B, B比A的富余量 // 供应A进程 ProviderA() { while(true) { P(emptyA); // 是否还有空货架放A? P(limitB); // B比A的数量是否已经多了k个？ // P(limitB)意味着消耗一个B对A的富余名额 P(mutex); // 生产一个A并放入 countA++; V(mutex); V(limitA); // 增加一个A对B的富余名额 V(foodA); // 增加一个食品A } } // 供应B进程 ProviderB() { while(true) { P(emptyB); // 是否还有空货架放B? P(limitA); // A比B的数量是否已经多了k个？ // P(limitA)意味着消耗一个A对B的富余名额 P(mutex); // 生产一个B并放入 countB++; V(mutex); V(limitB); // 增加一个B对A的富余名额 V(foodB); // 增加一个食品B } } // 销售员进程 Seller() { while(true) { P(foodA); // 是否有食品A? P(foodB); // 是否有食品B? P(mutex); // 取走A和B countA--; countB--; V(mutex); V(emptyA); // 货架空出 V(emptyB); // 货架空出 } } </code></pre> <h3>4.3 使用管程的解决方案</h3> <p>使用管程可以更结构化地解决此问题. 我们将商店的库存和操作封装在一个管程内.</p> <p><strong>1. 管程设计</strong></p> <ul> <li><strong>共享变量</strong>: <ul> <li><code>countA</code>, <code>countB</code>: 两种食品的当前数量.</li> </ul> </li> <li><strong>条件变量</strong>: <ul> <li><code>canSupplyA</code>: 当A食品无法供应时 (已满或比B多k个), 供应者A在此等待.</li> <li><code>canSupplyB</code>: 当B食品无法供应时, 供应者B在此等待.</li> <li><code>canSell</code>: 当A或B食品缺货时, 销售员在此等待.</li> </ul> </li> <li><strong>管程过程</strong>: <ul> <li><code>SupplyA(item)</code>: 供货商A调用.</li> <li><code>SupplyB(item)</code>: 供货商B调用.</li> <li><code>Sell()</code>: 销售员调用.</li> </ul> </li> </ul> <p><strong>2. 伪代码实现</strong></p> <pre><code class="language-c++">class FoodStore { int countA = 0, countB = 0; condition canSupplyA, canSupplyB, canSell; // 供应A食品 public void SupplyA() { while (countA >= m || countA - countB >= k) { wait(canSupplyA); } // 放入食品A countA++; // 唤醒可能在等待的销售员和供应者B notify(canSell); if (countB - countA &#x3C; k) { // 检查是否可以解除对B的限制 broadcast(canSupplyB); // 使用broadcast更安全, 唤醒所有等待的B供应者 } } // 供应B食品 public void SupplyB() { while (countB >= m || countB - countA >= k) { wait(canSupplyB); } // 放入食品B countB++; // 唤醒可能在等待的销售员和供应者A notify(canSell); if (countA - countB &#x3C; k) { // 检查是否可以解除对A的限制 broadcast(canSupplyA); } } // 销售 public void Sell() { while (countA &#x3C; 1 || countB &#x3C; 1) { wait(canSell); } // 取走食品 countA--; countB--; // 唤醒可能在等待的供应者 broadcast(canSupplyA); broadcast(canSupplyB); } } // 进程调用 ProviderA() { while(true) { FoodStore.SupplyA(); } } ProviderB() { while(true) { FoodStore.SupplyB(); } } Seller() { while(true) { FoodStore.Sell(); } } </code></pre> <p><strong>3. 说明</strong></p> <ul> <li><strong>封装与互斥</strong>: 管程 <code>FoodStore</code> 封装了所有共享状态 (<code>countA</code>, <code>countB</code>), 并自动保证了对这些状态的所有操作 (<code>SupplyA</code>, <code>SupplyB</code>, <code>Sell</code>) 都是互斥的, 无需手动使用 <code>mutex</code>.</li> <li><strong>条件等待</strong>: 每个进程在进入管程后, 使用 <code>while</code> 循环检查其执行条件. 如果条件不满足, 则调用 <code>wait()</code> 在相应的条件变量上等待, 这会自动释放管程的锁.</li> <li><strong>唤醒</strong>: 当一个进程改变了系统状态后 (如增加或减少了食品), 它会调用 <code>notify()</code> 或 <code>broadcast()</code> 来唤醒可能在等待的其它进程. 例如, <code>Sell</code> 过程完成后, 货架空出, 两种食品的数量关系也可能改变, 因此它 <code>broadcast</code> 唤醒所有可能在等待的供应者, 让它们重新检查条件. 使用 <code>while</code> 而不是 <code>if</code> 来检查等待条件, 确保了被唤醒的进程在继续执行前, 其条件一定是满足的, 这是一种健壮的并发编程模式.</li> </ul> <h2>5 三峡大坝船闸调度问题</h2> <h3>5.1 问题描述</h3> <p>三峡大坝有五级船闸 $T_1 \sim T_5$. 上游船只依次通过 $T_1 \to T_2 \to T_3 \to T_4 \to T_5$ 到达下游, 下游船只依次通过 $T_5 \to T_4 \to T_3 \to T_2 \to T_1$ 到达上游. 假设船闸为单向通行, 即在同一时间段内, 所有五级船闸要么都给上游船只使用, 要么都给下游船只使用. 试用P、V操作解决该调度问题.</p> <h3>5.2 使用P、V操作的问题解答</h3> <p><strong>1. 关系分析</strong></p> <ul> <li><strong>互斥关系</strong>: <ol> <li><strong>船闸互斥</strong>: 每一级船闸 ($T_1$ 到 $T_5$) 在同一时刻只能被一艘船使用.</li> <li><strong>方向互斥</strong>: 整个船闸系统在同一时间只能有一个通行方向. 这是一个典型的"读者-写者问题"的变体. 我们可以将上行和下行的船队看作两类"读者", 但这两类"读者"是互斥的.</li> </ol> </li> </ul> <p><strong>2. 信号量设置</strong></p> <ul> <li><code>gate[5]</code>: 一个信号量数组, <code>gate[i]</code> 代表第 $i+1$ 级船闸, 初值均为 1, 用于保证每级船闸的互斥使用.</li> <li><code>up_mutex</code>, <code>down_mutex</code>: 两个互斥信号量, 初值为 1, 用于保护上行船只计数器 <code>up_count</code> 和下行船只计数器 <code>down_count</code>.</li> <li><code>up_count</code>, <code>down_count</code>: 两个整型变量, 初值为 0, 记录正在船闸系统中航行的上行和下行船只数量.</li> <li><code>direction_mutex</code>: 关键的"方向"信号量, 初值为 1. 用于保证同一时间只有一个方向的船只可以通过. 第一个进入系统的船 (无论是上行还是下行) 将持有这个信号量, 最后一个离开系统的船将释放它.</li> </ul> <p><strong>3. 伪代码实现</strong></p> <pre><code class="language-c++">// 信号量和计数器 semaphore gate[5] = {1, 1, 1, 1, 1}; // 5个船闸 semaphore up_mutex = 1, down_mutex = 1; semaphore direction_mutex = 1; int up_count = 0, down_count = 0; // 上行船只进程 (下游 -> 上游: T5 -> T1) Upward_Ship() { // ---- 进入船闸系统 ---- P(up_mutex); if (up_count == 0) { // 如果是第一艘上行船 P(direction_mutex); // 尝试获取航行方向控制权 } up_count++; V(up_mutex); // ---- 依次通过船闸 ---- P(gate[4]); // 过 T5 // 正在过 T5 ... V(gate[4]); P(gate[3]); // 过 T4 // 正在过 T4 ... V(gate[3]); P(gate[2]); // 过 T3 // 正在过 T3 ... V(gate[2]); P(gate[1]); // 过 T2 // 正在过 T2 ... V(gate[1]); P(gate[0]); // 过 T1 // 正在过 T1 ... V(gate[0]); // ---- 离开船闸系统 ---- P(up_mutex); up_count--; if (up_count == 0) { // 如果是最后一艘上行船 V(direction_mutex); // 释放航行方向控制权 } V(up_mutex); } // 下行船只进程 (上游 -> 下游: T1 -> T5) Downward_Ship() { // ---- 进入船闸系统 ---- P(down_mutex); if (down_count == 0) { // 如果是第一艘下行船 P(direction_mutex); // 尝试获取航行方向控制权 } down_count++; V(down_mutex); // ---- 依次通过船闸 ---- P(gate[0]); // 过 T1 // 正在过 T1 ... V(gate[0]); P(gate[1]); // 过 T2 // 正在过 T2 ... V(gate[1]); P(gate[2]); // 过 T3 // 正在过 T3 ... V(gate[2]); P(gate[3]); // 过 T4 // 正在过 T4 ... V(gate[3]); P(gate[4]); // 过 T5 // 正在过 T5 ... V(gate[4]); // ---- 离开船闸系统 ---- P(down_mutex); down_count--; if (down_count == 0) { // 如果是最后一艘下行船 V(direction_mutex); // 释放航行方向控制权 } V(down_mutex); } </code></pre> <p><strong>说明</strong>:</p> <ul> <li><code>gate[i]</code> 保证了每个船闸的互斥使用.</li> <li><code>direction_mutex</code> 是解决问题的核心. 当一个方向 (例如上行) 的第一艘船到达时, 它会执行 <code>P(direction_mutex)</code>, 从而锁定了航行方向. 在此期间, 任何试图从相反方向 (下行) 进入的第一艘船都会因为 <code>P(direction_mutex)</code> 而被阻塞.</li> <li>只有当该方向的所有船只都通过并离开后 (<code>up_count</code> 减为 0) , 最后一艘船才会执行 <code>V(direction_mutex)</code>, 从而允许相反方向的船只开始通行. 这完美地实现了"单向通行"的要求.</li> </ul> <h3>5.3 使用管程的解决方案</h3> <p>此问题本质上是"两类读者互斥"的读者-写者问题变体. 管程非常适合解决此类问题. 我们将整个船闸系统的调度逻辑封装在一个管程中.</p> <p><strong>1. 管程设计</strong></p> <ul> <li><strong>共享变量</strong>: <ul> <li><code>up_count</code>, <code>down_count</code>: 记录正在系统中的上行和下行船只数.</li> <li><code>direction</code>: 表示当前航行方向 (<code>UP</code>, <code>DOWN</code>, 或 <code>NONE</code>).</li> </ul> </li> <li><strong>条件变量</strong>: <ul> <li><code>up_q</code>: 上行船只在此等待.</li> <li><code>down_q</code>: 下行船只在此等待.</li> </ul> </li> <li><strong>管程过程</strong>: <ul> <li><code>RequestUpstreamPass()</code>: 上行船只请求进入.</li> <li><code>FinishUpstreamPass()</code>: 上行船只完成通过.</li> <li><code>RequestDownstreamPass()</code>: 下行船只请求进入.</li> <li><code>FinishDownstreamPass()</code>: 下行船只完成通过.</li> </ul> </li> </ul> <p><strong>2. 伪代码实现</strong></p> <pre><code class="language-c++">class DamLockControl { int up_count = 0, down_count = 0; // 使用一个枚举或整数表示方向: 0-NONE, 1-UP, 2-DOWN int current_direction = 0; condition up_q, down_q; // 上行船只请求进入 public void RequestUpstreamPass() { // 如果当前是下行方向, 则等待 while (current_direction == 2) { wait(up_q); } up_count++; current_direction = 1; // 占定方向为上行 } // 上行船只完成通过 public void FinishUpstreamPass() { up_count--; if (up_count == 0) { current_direction = 0; // 释放方向 broadcast(down_q); // 通知所有等待的下行船只 } } // 下行船只请求进入 public void RequestDownstreamPass() { // 如果当前是上行方向, 则等待 while (current_direction == 1) { wait(down_q); } down_count++; current_direction = 2; // 占定方向为下行 } // 下行船只完成通过 public void FinishDownstreamPass() { down_count--; if (down_count == 0) { current_direction = 0; // 释放方向 broadcast(up_q); // 通知所有等待的上行船只 } } } // 船只进程 Upward_Ship() { DamLockControl.RequestUpstreamPass(); // 依次通过T5 -> T1... (这部分互斥可以用信号量或更细粒度的管程) DamLockControl.FinishUpstreamPass(); } Downward_Ship() { DamLockControl.RequestDownstreamPass(); // 依次通过T1 -> T5... DamLockControl.FinishDownstreamPass(); } </code></pre> <p><strong>3. 说明</strong></p> <ul> <li><strong>方向控制</strong>: 管程通过 <code>current_direction</code> 变量显式地管理航行方向. 当一个方向的船只请求进入时, 它会检查 <code>current_direction</code>. 如果方向冲突, 它就在相应的条件变量上等待.</li> <li><strong>进入与离开</strong>: 第一个进入的船只 (任一方向) 会设定 <code>current_direction</code>, 从而阻止相反方向的船只. 最后一个离开的船只负责重置 <code>current_direction</code> 并用 <code>broadcast</code> 唤醒所有等待的对向狒狒, 把通行权交给它们.</li> <li><strong>简化</strong>: 此管程方案优雅地解决了核心的"方向互斥"问题. 对于"每级船闸只能有一艘船"的次级互斥问题, 可以使用单独的信号量数组 (如原解法) , 或者为每级船闸设计一个简单的互斥管程. 将两者结合即可得到完整解法.</li> </ul> <h2>6 狒狒过峡谷问题</h2> <p>这个问题实际上是"读者-写者问题"的一个非常形象的变体.</p> <h3>6.1 问题概述</h3> <p>一根绳索横跨峡谷, 狒狒可以沿绳索过峡谷. 只要方向相同, 可以有多只狒狒同时在绳索上. 但如果不同方向的狒狒同时上绳, 就会在中间相遇, 产生死锁. 编写一个避免死锁的程序.</p> <p>不考虑饥饿问题或者考虑饥饿问题.</p> <h3>6.2 使用P、V操作的解答 (不考虑饥饿问题)</h3> <p>这个问题和三峡大坝问题非常相似. 我们可以把向东的狒狒看作一类"读者", 向西的狒狒看作另一类"读者", 这两类读者是互斥的.</p> <p><strong>1. 信号量设置</strong></p> <ul> <li><code>mutex</code>: 互斥信号量, 保护对东行和西行计数器的访问, 初值为 1.</li> <li><code>east_count</code>, <code>west_count</code>: 计数器, 记录正在绳索上向东和向西的狒狒数量, 初值为 0.</li> <li><code>rope</code>: 代表绳索使用权的信号量, 初值为 1. 第一个要上绳的狒狒群体 (无论是东行还是西行) 获取它, 最后一个离开的狒狒释放它.</li> </ul> <p><strong>2. 伪代码实现</strong></p> <pre><code class="language-c++">// 信号量和计数器 semaphore mutex = 1; semaphore rope = 1; int east_count = 0, west_count = 0; // 可以合并为一个方向计数器和一个方向变量 // 向东走的狒狒 Eastward_Baboon() { P(mutex); if (east_count == 0) { // 如果是第一只向东的狒狒 P(rope); // 尝试获取绳索 } east_count++; V(mutex); // --- 过峡谷 --- // crossing the rope... // --- 过完峡谷 --- P(mutex); east_count--; if (east_count == 0) { // 如果是最后一只向东的狒狒 V(rope); // 释放绳索 } V(mutex); } // 向西走的狒狒 Westward_Baboon() { P(mutex); // 这里我们用 west_count 来实现, 逻辑完全对称 if (west_count == 0) { // 如果是第一只向西的狒狒 P(rope); // 尝试获取绳索 } west_count++; V(mutex); // --- 过峡谷 --- // crossing the rope... // --- 过完峡谷 --- P(mutex); west_count--; if (west_count == 0) { // 如果是最后一只向西的狒狒 V(rope); // 释放绳索 } V(mutex); } </code></pre> <p><strong>说明</strong>: 这个解法是"读者优先"的变体. 例如, 如果有一批狒狒正在向东走, <code>rope</code> 信号量被持有. 此时, 任何想向西走的狒狒都会在 <code>P(rope)</code> 处被阻塞. 而新来的向东的狒狒则可以不受阻碍地直接上绳. 这可能导致西行的狒狒饥饿.</p> <h3>6.3 使用管程的解答 (不考虑饥饿问题)</h3> <p><strong>1. 管程设计</strong></p> <p>这个管程 <code>RopeBridge</code> 将封装所有共享状态和同步逻辑.</p> <ul> <li><strong>共享变量</strong>: <ul> <li><code>east_count</code>: 记录正在向东走的狒狒数量.</li> <li><code>west_count</code>: 记录正在向西走的狒狒数量.</li> </ul> </li> <li><strong>条件变量</strong>: <ul> <li><code>can_go_east</code>: 准备向东走的狒狒在此条件上等待.</li> <li><code>can_go_west</code>: 准备向西走的狒狒在此条件上等待.</li> </ul> </li> <li><strong>管程过程 (Procedures)</strong>: <ul> <li><code>ArriveEast()</code> / <code>LeaveEast()</code>: 东行狒狒调用的进入和离开方法.</li> <li><code>ArriveWest()</code> / <code>LeaveWest()</code>: 西行狒狒调用的进入和离开方法.</li> </ul> </li> </ul> <p><strong>2. 伪代码实现</strong></p> <pre><code class="language-c++">class RopeBridge { int east_count = 0; int west_count = 0; condition can_go_east, can_go_west; // 狒狒准备向东走时调用 public void ArriveEast() { // 如果有任何狒狒正在向西走, 则必须等待 while (west_count > 0) { wait(can_go_east); } // 允许通行, 东行计数加一 east_count++; } // 狒狒向东走完后调用 public void LeaveEast() { // 东行计数减一 east_count--; // 如果我是最后一个东行的狒狒, 就唤醒所有等待西行的狒狒 if (east_count == 0) { broadcast(can_go_west); } } // 狒狒准备向西走时调用 public void ArriveWest() { // 如果有任何狒狒正在向东走, 则必须等待 while (east_count > 0) { wait(can_go_west); } // 允许通行, 西行计数加一 west_count++; } // 狒狒向西走完后调用 public void LeaveWest() { // 西行计数减一 west_count--; // 如果我是最后一个西行的狒狒, 就唤醒所有等待东行的狒狒 if (west_count == 0) { broadcast(can_go_east); } } } // 外部调用逻辑 // 向东走的狒狒 Eastward_Baboon() { RopeBridge.ArriveEast(); // --- 正在过峡谷 --- RopeBridge.LeaveEast(); } // 向西走的狒狒 Westward_Baboon() { RopeBridge.ArriveWest(); // --- 正在过峡谷 --- RopeBridge.LeaveWest(); } </code></pre> <p><strong>3. 说明</strong> 这个解法是"读者优先"模式的管程实现. 例如, 当有一批狒狒正在向东走时 (<code>east_count > 0</code>), 任何新到达的、想向东走的狒狒都可以立即通过 <code>ArriveEast</code> 方法并上绳. 然而, 所有想向西走的狒狒都会在 <code>ArriveWest</code> 中的 <code>wait(can_go_west)</code> 处被阻塞. 只有当最后一个东行狒狒调用 <code>LeaveEast</code> 并执行 <code>broadcast(can_go_west)</code> 后, 西行狒狒才可能被唤醒.</p> <p>这种策略的缺点是, 如果东行狒狒源源不断地到来, 那么西行狒狒可能会永远等待下去, 导致<strong>饥饿</strong>.</p> <h3>6.4 使用P、V操作的解答 (考虑饥饿问题)</h3> <p>在6.2节的解法中, 一个方向的狒狒流可能会导致另一个方向的狒狒永久等待, 产生饥饿. 为了解决这个问题, 我们可以增加一个"旋转门" (turnstile) 信号量, 来保证对绳索的请求是公平的, 实现先到先服务 (FCFS).</p> <p>我觉得这是一个很巧妙的算法!</p> <p><strong>1. 信号量设置</strong></p> <ul> <li><code>mutex_e</code>, <code>mutex_w</code>: 分别保护 <code>east_count</code> 和 <code>west_count</code> 的互斥锁, 初值为 1.</li> <li><code>east_count</code>, <code>west_count</code>: 计数器, 记录正在绳索上的狒狒数量, 初值为 0.</li> <li><code>rope</code>: 代表绳索的使用权, 保证方向的互斥, 初值为 1.</li> <li><code>turnstile</code>: 新增的"旋转门"或"门卫"信号量, 所有狒狒在尝试获取绳索前都必须先通过它. 这确保了对<code>rope</code>信号量的竞争是公平的. 初值为 1.</li> </ul> <p><strong>2. 伪代码实现</strong></p> <pre><code class="language-c++">// 信号量和计数器 semaphore mutex_e = 1, mutex_w = 1; semaphore rope = 1; semaphore turnstile = 1; // 保证公平的旋转门 int east_count = 0, west_count = 0; // 向东走的狒狒 Eastward_Baboon() { P(turnstile); // 在旋转门前排队 P(mutex_e); east_count++; if (east_count == 1) { // 如果是第一只东行狒狒 P(rope); // 尝试为东行方向获取绳索 } V(mutex_e); V(turnstile); // 通过旋转门, 让下一个人/狒狒可以排队 // --- 过峡谷 --- P(mutex_e); east_count--; if (east_count == 0) { // 如果是最后一只东行狒狒 V(rope); // 释放绳索 } V(mutex_e); } // 向西走的狒狒 Westward_Baboon() { P(turnstile); // 在旋转门前排队 P(mutex_w); west_count++; if (west_count == 1) { // 如果是第一只西行狒狒 P(rope); // 尝试为西行方向获取绳索 } V(mutex_w); V(turnstile); // 通过旋转门 // --- 过峡谷 --- P(mutex_w); west_count--; if (west_count == 0) { // 如果是最后一只西行狒狒 V(rope); // 释放绳索 } V(mutex_w); } </code></pre> <p><strong>3. 说明</strong></p> <ul> <li><strong>公平性保证</strong>: <code>turnstile</code> 是解决饥饿问题的关键. 假设有一队东行狒狒正在过桥, <code>rope</code> 信号量被东行者持有. 此时, 一只西行狒狒 <code>W1</code> 到达, 它会通过 <code>turnstile</code> 并阻塞在 <code>P(rope)</code> 上. 紧接着, 一只新的东行狒狒 <code>E_new</code> 到达. <code>E_new</code> 会被 <code>P(turnstile)</code> 阻塞, 因为 <code>W1</code> 还没有执行 <code>V(turnstile)</code>. 这样, <code>E_new</code> 就必须排在 <code>W1</code> 之后. 当东行队伍全部过完并释放 <code>rope</code> 时, <code>W1</code> 就能获得绳索, <code>E_new</code> 则需等待 <code>W1</code> 的队伍过完. 这就避免了西行狒狒的饥饿.</li> </ul> <h3>6.5 使用管程的解答 (考虑饥饿问题)</h3> <p>由于管程调度器往往是先到先服务, 是公平的, 所以我们只要保证在管程中, 所有等待的狒狒都在同一个条件变量上排队, 就可以保证公平性.</p> <p>但是这样会导致狒狒只能一个一个过, 即使只有同一个方向的也会在一个过去之后再过下一个, 我还没想到更好的算法, 如果有人有更好的算法, 欢迎在评论区提出!</p> <p><strong>1. 管程设计</strong></p> <ul> <li><strong>共享变量</strong>: <ul> <li><code>east_count</code>, <code>west_count</code>: 记录正在绳索上的狒狒数量.</li> <li><code>rope_is_busy</code>: 一个布尔标志, 表示绳索是否被任何一个方向占用.</li> </ul> </li> <li><strong>条件变量</strong>: <ul> <li><code>can_try</code>: 一个单一的条件变量, 所有等待的狒狒都在此排队.</li> </ul> </li> <li><strong>管程过程</strong>: <ul> <li><code>Arrive(direction)</code>: 狒狒到达时调用, 传入其方向.</li> <li><code>Leave(direction)</code>: 狒狒离开时调用.</li> </ul> </li> </ul> <p><strong>2. 伪代码实现</strong></p> <pre><code class="language-c++">class FairRopeBridge { int east_count = 0; int west_count = 0; // 使用一个单一的条件变量来模拟公平的等待队列 condition can_try; // 狒狒到达, 准备上绳 public void Arrive(direction) { // 检查是否可以上绳. // 如果当前是相反方向, 则必须等待. if (direction == EAST) { while (west_count > 0) { wait(can_try); } east_count++; } else { // direction == WEST while (east_count > 0) { wait(can_try); } west_count++; } } // 狒狒离开 public void Leave(direction) { if (direction == EAST) { east_count--; // 如果我是最后一个, 唤醒所有等待者, 让他们重新竞争 if (east_count == 0) { broadcast(can_try); } } else { // direction == WEST west_count--; // 如果我是最后一个, 唤醒所有等待者 if (west_count == 0) { broadcast(can_try); } } } } // 外部调用逻辑 Eastward_Baboon() { FairRopeBridge.Arrive(EAST); // --- 正在过峡谷 --- FairRopeBridge.Leave(EAST); } Westward_Baboon() { FairRopeBridge.Arrive(WEST); // --- 正在过峡谷 --- FairRopeBridge.Leave(WEST); } </code></pre> <p><strong>3. 说明</strong></p> <ul> <li><strong>公平调度</strong>: 此管程模型通过将所有等待的狒狒（无论方向）都放在同一个条件变量 <code>can_try</code> 上, 实现了公平性. 当一批狒狒过完峡谷, 最后一个离开的狒狒会调用 <code>broadcast(can_try)</code>. 这会唤醒所有在 <code>wait(can_try)</code> 上睡眠的进程.</li> <li><strong>竞争与 <code>while</code> 循环</strong>: 被唤醒的狒狒们会重新开始竞争进入管程. <strong>由于调度器通常是公平的</strong>, 等待时间最长的狒狒有很大概率先被调度. 它会重新检查 <code>while</code> 循环的条件 (<code>west_count > 0</code> 或 <code>east_count > 0</code>). 如果绳索对它来说是空闲的, 它就能成功跳出循环并上绳. 其他被唤醒的、方向相反的狒狒会发现条件不满足, 重新进入 <code>wait</code> 状态. 这种 <code>while-wait-broadcast</code> 的模式是实现公平调度的经典方法.</li> </ul> <h2>7 睡眠理发师问题</h2> <h3>7.1 问题描述</h3> <p>理发店有一位理发师、一把理发椅和N把供顾客等候的椅子.</p> <ul> <li>如果没有顾客, 理发师就在理发椅上睡觉.</li> <li>当一个顾客到来时, 他必须唤醒理发师.</li> <li>如果理发师正在理发, 新来的顾客会看是否有空椅子. 如果有, 就坐下等待；如果没有, 就离开.</li> </ul> <h3>7.2 使用P、V操作的问题解答 (一位理发师)</h3> <p><strong>1. 关系分析</strong> 这是一个生产者-消费者模型. 顾客是"生产者" (生产理发请求) , 理发师是"消费者" (消费理发请求) , 椅子是缓冲区. 但是和生产者-消费者模型不同的是, 不能在顾客坐下 (生产理发请求) 之后立刻结束, 必须等理发师理发结束 (消费理发请求) 之后才能结束.</p> <ul> <li><strong>同步关系</strong>: <ul> <li>理发师需要等待顾客的到来才能开始工作.</li> <li>顾客需要等待理发师空闲才能理发.</li> </ul> </li> <li><strong>互斥关系</strong>: 对等候椅数量 <code>waiting_chairs</code> 的修改需要互斥.</li> </ul> <p><strong>2. 信号量设置</strong></p> <ul> <li><code>customers</code>: 信号量, 表示等待理发的顾客数量. 理发师通过 <code>P(customers)</code> 来检查是否有顾客, 如果没有就会睡眠. 初值为 0.</li> <li><code>barbers</code>: 信号量, 表示空闲的理发师数量. 顾客通过 <code>P(barbers)</code> 来等待理发师空闲. 初值为 0 (或 1, 取决于初始状态理发师是否在睡觉). 我们设为0, 表示初始没有空闲理发师, 需要顾客唤醒.</li> <li><code>mutex</code>: 互斥信号量, 用于保护对 <code>waiting_chairs</code> 计数器的访问, 初值为 1.</li> <li><code>waiting_chairs</code>: 一个整型变量, 记录可用的等候椅数量, 初值为 N.</li> </ul> <p><strong>3. 伪代码实现</strong></p> <pre><code class="language-c++">// 常量和变量 #define N 5 // 假设有5把椅子 int waiting_chairs = N; // 可用的等候椅数量, 就是生产者-消费者模型中的 empty 信号量 // 信号量 semaphore customers = 0; // 等待的顾客数, 就是生产者-消费者模型中的 full 信号量 semaphore barbers = 0; // 空闲的理发师数, 加入的新信号量, 因为必须理完发才能走, 所以必须找到一个空闲的理发师 semaphore mutex = 1; // 保护 waiting_chairs, 就是生产者-消费者模型中的 mutex 信号量 // 顾客进程-生产者 Customer() { P(mutex); if (waiting_chairs > 0) { waiting_chairs--; // 坐下一把椅子 V(mutex); // 释放锁 V(customers); // 通知理发师, 我来了 // 如果是生产者-消费者模型, 这里就可以结束了, 因为进入就可以结束了, 但是理发坐下之后还得等 P(barbers); // 等待理发师准备好 (即理发师被叫醒给自己理发) // --- 正在理发 --- // get_haircut(); } else { // 没有空椅子了 V(mutex); // 必须释放锁再离开 // --- 顾客离开 --- // leave_shop(); } } // 理发师进程-消费者 Barber() { while(true) { P(customers); // 等待顾客到来. 如果没有顾客, 则在椅子上睡眠. // 下述三行其实就是生产者-消费者模型中的 V(empty) 操作, 因为顾客坐下之后, 等待用的椅子就多了一把, 所以 empty 信号量加一 P(mutex); waiting_chairs++; // 一个顾客从等待区坐到理发椅上, 空出一把椅子 V(mutex); // 如果是生产者-消费者模型, 这里就可以结束了, 因为使用完物品就可以结束了 V(barbers); // 我这个理发师被叫醒了, 可以开始理发了 // --- 理发进行中 --- // cut_hair(); // --- 理发结束 --- } } </code></pre> <p>可能出现饥饿问题, 也就是第一个顾客叫醒的理发师, 可能被第二个顾客抢走.</p> <h3>7.3 使用管程的解决方案 (一位理发师)</h3> <p>管程将理发店的状态 (等待的顾客) 和操作 (理发、等待) 封装起来, 使逻辑更清晰.</p> <p><strong>1. 管程设计</strong></p> <ul> <li><strong>共享变量</strong>: <code>waiting_count</code>, 记录在等候椅上的人数.</li> <li><strong>条件变量</strong>: <ul> <li><code>customer_is_waiting</code>: 理发师在此等待顾客来.</li> <li><code>barber_is_ready</code>: 顾客在此等待理发师睡醒.</li> </ul> </li> <li><strong>管程过程</strong>: <ul> <li><code>GetHaircut()</code>: 由顾客调用.</li> <li><code>NextCustomer()</code>: 由理发师调用.</li> </ul> </li> </ul> <p><strong>2. 伪代码实现</strong></p> <pre><code class="language-c++">class BarberShop { int waiting_count = 0; final int N = 5; // 椅子数量 condition customer_is_waiting, barber_is_ready; // 顾客调用的过程 public function GetHaircut() returns bool { if (waiting_count == N) { return false; // 没有椅子, 理发失败 } waiting_count++; // 唤醒理发师 notify(customer_is_waiting); // 等待理发师为我服务, 如果是生产者-消费者模型, 这里就可以结束了 wait(barber_is_ready); return true; // 理发成功 } // 理发师调用的过程 public void NextCustomer() { // 如果没有等待的顾客, 就睡觉 while (waiting_count == 0) { wait(customer_is_waiting); } waiting_count--; // 叫醒一个顾客, 如果是生产者-消费者模型, 这里就可以结束了 notify(barber_is_ready); } } // 进程 Customer() { if (BarberShop.GetHaircut()) { // 正在理发... } else { // 离开... } } Barber() { while(true) { BarberShop.NextCustomer(); // cut_hair()... } } </code></pre> <p><strong>3. 说明</strong> 顾客调用 <code>GetHaircut</code>, 如果成功进入等待队列, 就 <code>notify</code> 理发师并 <code>wait</code> 在自己的条件上. 理发师调用 <code>NextCustomer</code>, <code>wait</code> 等待顾客, 被唤醒后 <code>notify</code> 一个顾客来理发. 这种客户和理发师之间的"握手"非常清晰.</p> <h3>7.4 问题解答 (M个理发师)</h3> <p>如果理发店有 M 个理发师, 如何修改？</p> <p>如果有多个消费者, 不需要修改代码, 因为本身生产者-消费者模型中, 消费者是多个的, 所以不需要修改.</p> <h2>8 第二类读者写者问题 (写者优先)</h2> <h3>8.1 问题描述</h3> <p>要求： a. 多个读者可以同时进行读. b. 写者必须互斥 (一次只有一个写者, 且读写不能同时) . c. 写者优先于读者 (一旦有写者在等待, 后续到达的读者必须等待, 直到所有等待的写者都完成后才能读) .</p> <h3>8.2 使用P、V操作的问题解答</h3> <p><strong>1. 关系分析</strong> 写者优先的核心在于：当一个写者希望写入时, 它应该尽快获得访问权, 甚至要插队到已经在等待的读者前面.</p> <p><strong>2. 信号量设置</strong></p> <ul> <li><code>read_count</code>, <code>write_count</code>: 读者和写者的计数器, 初值为 0.</li> <li><code>mutex_r</code>, <code>mutex_w</code>: 分别保护 <code>read_count</code> 和 <code>write_count</code> 的互斥锁, 初值为 1.</li> <li><code>r_gate</code>: 一个"读者大门"信号量. 当有写者在等待时, 此门关闭, 阻止新读者进入. 初值为 1.</li> <li><code>w_resource</code>: 代表共享资源的"写者锁", 也用于实现读者和写者的互斥. 初值为 1.</li> </ul> <p><strong>3. 伪代码实现</strong></p> <pre><code class="language-c++">int read_count = 0, write_count = 0; semaphore mutex_r = 1, mutex_w = 1; // 保护计数器的锁 semaphore r_gate = 1; // 读者进入的大门 semaphore w_resource = 1; // 资源本身的锁, 也是写者锁 // 读者进程 Reader() { P(r_gate); // 尝试通过读者大门 P(mutex_r); read_count++; if (read_count == 1) { // 如果是第一个读者 P(w_resource); // 锁住资源, 阻止写者 } V(mutex_r); V(r_gate); // 通过后, 立刻让其他读者也通过大门 // --- 读操作 --- // reading... P(mutex_r); read_count--; if (read_count == 0) { // 如果是最后一个读者 V(w_resource); // 释放资源, 允许写者进入 } V(mutex_r); } // 写者进程 Writer() { P(mutex_w); write_count++; if (write_count == 1) { // 如果是第一个写者 P(r_gate); // 关上读者大门, 阻止新读者进入 } V(mutex_w); P(w_resource); // 获取资源的独占访问权 (写者锁) // --- 写操作 --- // writing... V(w_resource); // 释放资源 P(mutex_w); write_count--; if (write_count == 0) { // 如果是最后一个写者 V(r_gate); // 打开读者大门, 允许读者进入 } V(mutex_w); } </code></pre> <p><strong>说明</strong>:</p> <ul> <li><strong>写者如何优先</strong>: 当第一个写者到达时 (<code>write_count</code> 变为 1), 它会立即 <code>P(r_gate)</code>. 这会导致所有后续到来的读者全部被阻塞在 <code>P(r_gate)</code> 处. 它们甚至没有机会去修改 <code>read_count</code> 或尝试获取 <code>w_resource</code>.</li> <li><strong>写者执行</strong>: 写者进程会继续执行 <code>P(w_resource)</code>. 如果当前有读者正在读, 它会等待这些读者全部结束 (最后一个读者会 <code>V(w_resource)</code>). 一旦 <code>w_resource</code> 被释放, 等待的写者就能立刻获得它, 开始写入.</li> <li><strong>写者离开</strong>: 当最后一个等待的写者完成工作后 (<code>write_count</code> 变为 0), 它会 <code>V(r_gate)</code>, 把读者大门打开, 此时在门外等候的读者们才能进入.</li> </ul> <p>这种机制确保了只要有写者在等待, 就不会有新的读者开始读取, 体现了写者优先.</p> <h3>8.3 使用管程的解决方案</h3> <p>写者优先的逻辑在管程中可以通过增加一个写者等待计数器来实现.</p> <p><strong>1. 管程设计</strong></p> <ul> <li><strong>共享变量</strong>: <ul> <li><code>read_count</code>: 正在读的读者数.</li> <li><code>write_waiting_count</code>: 正在等待的写者数.</li> <li><code>writer_active</code>: 是否有写者正在写.</li> </ul> </li> <li><strong>条件变量</strong>: <code>can_read</code>, <code>can_write</code>.</li> <li><strong>管程过程</strong>: <code>StartRead</code>, <code>EndRead</code>, <code>StartWrite</code>, <code>EndWrite</code>.</li> </ul> <p><strong>2. 伪代码实现</strong></p> <pre><code class="language-c++">class WriterPriorityRW { int read_count = 0; int write_waiting_count = 0; bool writer_active = false; condition can_read, can_write; public void StartWrite() { write_waiting_count++; // 如果有读者在读, 或者有写者在写, 则等待 while (read_count > 0 || writer_active) { wait(can_write); } write_waiting_count--; writer_active = true; } public void EndWrite() { writer_active = false; // 优先唤醒等待的写者 if (write_waiting_count > 0) { notify(can_write); } else { // 否则唤醒所有等待的读者 broadcast(can_read); } } public void StartRead() { // 如果有写者在写, 或者有写者在等待, 则等待 while (writer_active || write_waiting_count > 0) { wait(can_read); } read_count++; } public void EndRead() { read_count--; // 如果是最后一个读者, 则唤醒一个写者 if (read_count == 0) { notify(can_write); } } } </code></pre> <p><strong>3. 说明</strong></p> <ul> <li><strong>写者优先的实现</strong>: 关键在于 <code>StartRead</code> 和 <code>StartWrite</code> 中的 <code>write_waiting_count</code> 计数器. <ul> <li>一个写者到达时, 先将 <code>write_waiting_count</code> 加一, 表明"有写者驾到".</li> <li>一个读者准备读之前, 必须检查 <code>writer_active</code> 和 <code>write_waiting_count</code>. 只要 <code>write_waiting_count > 0</code>, 即使当前没有写者在写, 读者也必须等待. 这就赋予了写者优先权.</li> </ul> </li> <li><strong>唤醒逻辑</strong>: 在 <code>EndWrite</code> 中, 优先检查并唤醒其他等待的写者. 只有在没有写者等待时, 才会唤醒读者. 在 <code>EndRead</code> 中, 最后一个读者离开时, 需要检查是否有写者在等待, 并负责唤醒它们.</li> </ul> <h2>9 利用信号量管理共享资源</h2> <p>这是一个复杂的问题, 通过分析一个有问题的代码, 逐步引出两种经典的并发编程模式.</p> <h3>9.1 问题描述</h3> <p>一个共享资源有如下特性：</p> <ol> <li>当使用者少于 3 个时, 新进程可以立刻获得资源.</li> <li>当 3 个资源都被占用后, 新进程必须等待. 直到<strong>当前使用资源的 3 个进程都释放完资源</strong>后, 其他等待的进程才能获得资源 (一批一批地进入) .</li> </ol> <h3>9.2 初始的错误程序分析</h3> <p><strong>程序代码 (简化版)</strong>:</p> <pre><code class="language-c++">// 申请资源 P(mutex); if (must_wait) { // must_wait is (active == 3) waiting++; V(mutex); P(block); P(mutex); // 再次获取锁, 修改waiting waiting--; } active++; must_wait = (active == 3); V(mutex); // 释放资源 P(mutex); active--; if (active == 0) { int n = min(waiting, 3); for (i=0; i&#x3C;n; i++) { V(block); } must_wait = false; } V(mutex); </code></pre> <p><strong>a. 解释其出错的位置</strong></p> <p><strong>答</strong>: 错误发生在被 <code>P(block)</code> 唤醒之后.</p> <ol> <li>假设进程$P_4$, $P_5$, $P_6$... 都在 <code>P(block)</code> 处等待.</li> <li>当 <code>active</code> 变为 0 时, 最后一个离开的进程 (比如$P_3$) 会执行 <code>V(block)</code> 三次, 唤醒 $P_4$, $P_5$, $P_6$.</li> <li>这三个进程被唤醒后, 会<strong>依次</strong>尝试获取 <code>mutex</code>.</li> <li>假设 $P_4$ 第一个获取 <code>mutex</code>. 它执行 <code>waiting--</code>, 然后 <code>active++</code> (此时 <code>active</code>=1), <code>must_wait</code> 仍然是 <code>false</code>, 然后释放 <code>mutex</code>.</li> <li>现在轮到 $P_5$. 它获取 <code>mutex</code>, 执行 <code>waiting--</code>, <code>active++</code> (此时 <code>active</code>=2), <code>must_wait</code> 仍然是 <code>false</code>, 释放 <code>mutex</code>.</li> <li><strong>问题来了</strong>: 此时, 如果一个<strong>新进程</strong> $P_{10}$ 到达, 它执行申请资源的代码. 它会发现 <code>must_wait</code> 是 <code>false</code>！于是它不会去 <code>P(block)</code> 等待, 而是直接 <code>active++</code> (此时 <code>active</code>=3), 并将 <code>must_wait</code> 设置为 <code>true</code>. $P_{10}$"插队"成功了.</li> <li>之后, 之前被唤醒的 $P_6$ 才能获取 <code>mutex</code>, 它执行时 <code>active</code> 已经变成3, <code>must_wait</code> 已经为 <code>true</code>, 但它还是会执行 <code>active++</code>, 导致 <code>active</code> 变成4, 这违反了最多3个进程使用的规则.</li> </ol> <p><strong>根本原因</strong>: 进程被唤醒后, 它所处的"环境" (即 <code>must_wait</code> 的状态) 可能已经被其他进程改变了.</p> <p><strong>b. <code>if</code> 换成 <code>while</code> 是否解决问题？</strong></p> <p><strong>答</strong>: 将 <code>if(must_wait)</code> 换成 <code>while(must_wait)</code> <strong>可以解决"插队"和 <code>active</code> 超出3的问题</strong>, 但会引入<strong>新的问题</strong>.</p> <ul> <li> <p><strong>如何解决</strong>: 如果P10插队并设置了 <code>must_wait = true</code>, 那么当P6被唤醒并再次检查 <code>while(must_wait)</code> 条件时, 它会发现条件成立, 于是重新执行 <code>V(mutex)</code> 和 <code>P(block)</code>, 再次进入等待状态. 这避免了 <code>active > 3</code> 的情况. 这种"<strong>循环检查条件</strong>"是并发编程的一个重要原则.</p> </li> <li> <p><strong>有什么难点仍然存在？</strong>: <strong>死锁</strong>. 在上面的场景中, $P_6$被唤醒后, 发现条件不满足, 又回去睡觉了. 但是谁来唤醒它呢？最后一个离开者 ($P_3$) 已经完成了它的唤醒任务 (<code>V(block)</code>了三次) . 现在 <code>active</code> 是3 ($P_4$, $P_5$, $P_{10}$), 在它们全部离开之前, 不会有新的 <code>V(block)</code> 操作. 而 $P_6$ 却在 <code>P(block)</code> 上永久地等待下去. 这就造成了<strong>死锁</strong>.</p> </li> </ul> <h3>9.3 正确解法一: "I'll Do It for You" 模式</h3> <p><strong>程序代码</strong>:</p> <pre><code class="language-c++">// 申请资源 (Acquire) P(mutex); if (must_wait) { waiting++; V(mutex); P(block); // 等待被别人处理 } else { active++; must_wait = (active == 3); V(mutex); } // 释放资源 (Release) P(mutex); active--; if (active == 0) { int n = min(waiting, 3); waiting -= n; active = n; for (i=0; i&#x3C;n; i++) { V(block); } must_wait = (active == 3); } V(mutex); </code></pre> <p><strong>a. 解释工作方式和正确性</strong> 这种模式被称为 "I'll Do It for You" (我来帮你做).</p> <ul> <li><strong>核心思想</strong>: 申请资源的进程如果需要等待, 它什么都不做, 只是排队 (<code>P(block)</code>). 唤醒它的进程 (即释放资源的进程) 会<strong>替它完成</strong>所有状态变量的修改.</li> <li><strong>工作流程</strong>: <ol> <li><strong>申请</strong>: 进程检查 <code>must_wait</code>. 如果为 <code>true</code>, 则 <code>waiting++</code> 然后就去 <code>P(block)</code> 睡觉. 它<strong>不自己</strong>去 <code>active++</code>.</li> <li><strong>释放</strong>: 当最后一个使用者 (<code>active</code>变为0) 释放资源时, 它扮演了"组织者"的角色. 它查看有多少进程在等待 (<code>waiting</code>), 决定唤醒 <code>n</code> 个 (最多3个) . <strong>关键在于</strong>：它在唤醒它们之前, 就<strong>预先</strong>把 <code>active</code> 设置为 <code>n</code>, 把 <code>waiting</code> 减去 <code>n</code>, 并更新好 <code>must_wait</code> 状态.</li> <li><strong>唤醒后</strong>: 被唤醒的进程从 <code>P(block)</code> 返回后, <strong>什么也不用做</strong>, 它已经被"记作"是 <code>active</code> 状态了, 可以直接去使用资源.</li> </ol> </li> </ul> <p><strong>正确性</strong>: 这种方法是正确的, 因为所有状态变量的修改都在一个单一的临界区内 (释放者的临界区) 完成. 这避免了多个被唤醒进程之间以及新来进程之间的竞争和状态不一致问题.</p> <p><strong>b. 给出新进程插队的例子</strong> 这个程序<strong>不能完全避免</strong>新进程插队.</p> <ul> <li><strong>场景</strong>: <ol> <li>假设 <code>active=2</code>, <code>must_wait=false</code>, <code>waiting=0</code>.</li> <li>进程 $P_{new}$ 到达, 执行申请代码. 它通过了 <code>if(must_wait)</code> 检查, 即将执行 <code>active++</code>.</li> <li>在 $P_{new}$ 执行 <code>active++</code> 之前, 发生上下文切换. 一个正在使用资源的进程 $P_{old}$ 执行释放代码. 它将 <code>active</code> 减为 1.</li> <li>此时, 另一个等待了很久的进程 $P_{waiter}$ 正在 <code>P(block)</code> 等待 (假设之前有等待队列) .</li> <li>现在切换回 $P_{new}$. 它继续执行, <code>active</code> 变成 2. 它没有插在 $P_{waiter}$ 前面, 因为 $P_{waiter}$ 的唤醒条件 (<code>active==0</code>) 还没满足.</li> </ol> </li> </ul> <p><strong>重新审视问题</strong>: "这个程序不能完全避免新到达的进程插到已有等待进程前得到资源".</p> <ul> <li><strong>场景</strong>: <ol> <li><code>active=2</code>, <code>waiting=5</code>, <code>must_wait=true</code>.</li> <li>$P_1$, $P_2$ 正在使用资源. $P_3$-$P_7$ 在 <code>P(block)</code> 等待.</li> <li>$P_1$ 释放资源, <code>active</code> 变为 1. <code>must_wait</code> 仍然是 <code>true</code>.</li> <li>此时, 一个新进程 $P_8$ 到达. 它执行申请代码, 看到 <code>must_wait</code> 为 <code>true</code>, 于是 <code>waiting++</code> (变为6), 然后去 <code>P(block)</code> 等待.</li> <li>$P_2$ 释放资源, <code>active</code> 变为 0. 它看到 <code>waiting=6</code>, 于是唤醒3个进程 ($P_3$,$P_4$,$P_5$). 它将 <code>active</code> 设为 3, <code>waiting</code> 设为 3, <code>must_wait</code> 设</li> <li>现在 $P_3$, $P_4$, $P_5$ 在使用资源. $P_6$, $P_7$, $P_8$ 在等待.</li> <li><strong>此时, 如果一个新进程 $P_9$ 到达, 它会发现 <code>must_wait</code> 是 <code>false</code> 吗？</strong> 不会, 因为 <code>must_wait</code> 已经被设为 <code>true</code>.</li> </ol> </li> </ul> <p><strong>真正的插队机会</strong>: 插队发生于<strong>信号量本身</strong>的等待队列和我们自己维护的 <code>waiting</code> 计数器之间.</p> <ol> <li><code>active=2</code>, <code>must_wait=false</code>.</li> <li>进程 $P_{waiter}$ 到达, 执行 <code>P(mutex)</code>.</li> <li>切换到新进程 $P_{new}$, 它也执行 <code>P(mutex)</code>, 于是被阻塞在 <code>mutex</code> 的等待队列里.</li> <li>切换回 $P_{waiter}$. 它执行 <code>active++</code> 使 <code>active=3</code>, 设置 <code>must_wait=true</code>, 然后 <code>V(mutex)</code>.</li> <li><code>V(mutex)</code> 唤醒了 $P_{new}$. $P_{new}$ 看到 <code>must_wait=true</code>, 于是去 <code>P(block)</code> 等待. 在这个场景里, 先到达的 $P_{waiter}$ 获得了资源.</li> </ol> <p>这个模式下的插队问题非常微妙, 通常与"Thundering Herd Problem"有关, 即多个进程被唤醒去竞争同一个锁. 这里的模型简化了这个问题. 它的主要优点是逻辑清晰, 由一个进程负责管理状态.</p> <p><strong>c. 解释 "I'll Do It for You" 模式</strong> 该模式的核心是, 当一个进程需要等待某个条件满足时, 它不主动在唤醒后重新检查条件或修改状态. 它仅仅是作为一个被动的等待者. 而负责满足这个条件的进程 (通常是释放资源的进程) , 会主动地、代替那些等待者完成所有的状态转换. 就像一个秘书, 把所有事情都安排好了, 然后通知老板们："你们现在可以开始工作了", 老板们 (被唤醒的进程) 无需再关心任何准备工作.</p> <h3>9.4 正确解法二: "Pass the Baton" 模式</h3> <p><strong>程序代码</strong>:</p> <pre><code class="language-c++">semaphore mutex = 1, block = 0; int active = 0, waiting = 0; bool must_wait = false; void Acquire() { // 申请资源 (Acquire) P(mutex); if (must_wait) { waiting++; V(mutex); P(block); // 等待接力棒, 第四个进程开始需要等候, 因为 block 初始为 0 waiting--; // 唤醒后, 我获得了mutex的所有权 (接力棒) } active++; must_wait = (active == 3); if (waiting > 0 &#x26;&#x26; !must_wait) { V(block); // 传递接力棒 } else { V(mutex); // 释放锁 } } void Release() { // 释放资源 (Release) P(mutex); active--; if (active == 0) { must_wait = false; } if (waiting > 0 &#x26;&#x26; !must_wait) { V(block); // 开始传递接力棒 } else { V(mutex); // 释放锁 } } </code></pre> <p><strong>a. 解释工作方式和正确性</strong> 该模式被称为 "Pass the Baton" (传递接力棒).</p> <ul> <li><strong>核心思想</strong>: 互斥锁 <code>mutex</code> 在被唤醒的进程间直接传递, 就像接力赛中的"接力棒". 一个进程完成自己的临界区后, 不直接释放锁给公众, 而是直接将"锁的所有权"传递给下一个需要进入的、正在等待的进程.</li> <li><strong>工作流程</strong>: <ol> <li><strong>申请</strong>: 如果需要等待 (<code>must_wait</code> 为 <code>true</code>), 进程释放 <code>mutex</code> 并 <code>P(block)</code> 等待.</li> <li><strong>释放/传递</strong>: 当一个进程 (无论是释放者还是刚进入的申请者) 完成操作后, 它会检查是否还有进程在等待 (<code>waiting > 0</code>) 并且进入条件满足 (<code>!must_wait</code>). 如果满足, 它不执行 <code>V(mutex)</code>, 而是执行 <code>V(block)</code>.</li> <li><strong>接力棒传递</strong>: <code>V(block)</code> 唤醒一个在 <code>P(block)</code> 处等待的进程. 这个被唤醒的进程在返回时, <strong>它就拥有了互斥锁 <code>mutex</code> 的所有权</strong>, 因为它没有通过 <code>P(mutex)</code> 来获得, 而是由上一个进程"递给"它的. 然后它继续执行临界区代码 (<code>active++</code> 等) .</li> <li><strong>最后一人</strong>: 当最后一个需要被唤醒的进程完成操作后, 它检查条件, 发现不再需要唤醒别人了, 于是它执行 <code>V(mutex)</code>, 将锁"放回"架子上, 供所有新来的进程竞争.</li> </ol> </li> </ul> <p><strong>正确性</strong>: 这种方式保证了被唤醒的进程可以立即执行, 无需再次竞争 <code>mutex</code>, 从而避免了"唤醒后发现条件又变了"的问题. 它形成了一个"唤醒链", 效率很高.</p> <p><strong>b. 与上一解法在唤醒进程个数上的不同</strong></p> <ul> <li><strong>"I'll Do It for You"</strong>: 是一次性唤醒一批进程. 释放者在一个循环里执行 <code>V(block)</code> <code>n</code> 次, <strong>同时</strong>唤醒 <code>n</code> 个进程. 这 <code>n</code> 个进程随后会并发执行.</li> <li><strong>"Pass the Baton"</strong>: 是一次只唤醒一个进程. 一个进程 <code>V(block)</code> 唤醒下一个, 下一个再唤醒下下一个, 形成一个<strong>串行</strong>的唤醒链. 每次只有一个进程在临界区内活动.</li> </ul> <p><strong>c. 解释 "Pass the Baton" 模式</strong> 这个模式的精髓在于<strong>将锁的所有权和唤醒信号绑定</strong>. 执行 <code>V(block)</code> 的进程不仅是在唤醒一个等待者, 更是在对它说："我把临界区的钥匙 (mutex) 现在直接交给你了, 你继续". 这避免了被唤醒的进程再去和外面那些新来的进程一起竞争锁, 保证了等待队列的公平性和执行的有序性, 是一种非常高效和优雅的并发控制模式.</p> <h3>9.5 使用管程的解法</h3> <p>下述算法的 <code>active_count</code> 没有被保护, 所以可能出现竞争问题, 但是我还没想出更好的算法, 如果有人有更好的算法, 欢迎在评论区提出!</p> <p><strong>1. 管程设计</strong></p> <ul> <li><strong>共享变量</strong>: <ul> <li><code>active_count</code>: 当前正在使用资源的进程数.</li> <li><code>must_wait</code>: 一个布尔标志, 当资源满员后设置为 <code>true</code>, 阻止新进程进入, 直到下一批开始.</li> </ul> </li> <li><strong>条件变量</strong>: <ul> <li><code>next_batch_q</code>: 等待下一批的进程在此睡眠.</li> </ul> </li> <li><strong>管程过程</strong>: <code>Acquire()</code> 和 <code>Release()</code>.</li> </ul> <p><strong>2. 伪代码实现</strong></p> <pre><code class="language-c++">class ResourceManager { int active_count = 0; bool must_wait = false; condition next_batch_q; // 申请资源 public void Acquire() { // 如果上一批已满员, 则必须等待 while (must_wait) { wait(next_batch_q); } active_count++; // 如果我是本批的第3个, 则关上大门 if (active_count == 3) { must_wait = true; } } // 释放资源 public void Release() { active_count--; // 如果我是本批最后一个释放资源的 if (active_count == 0) { // 打开大门, 并通知所有等待者 must_wait = false; broadcast(next_batch_q); } } } // 进程代码 Process_i() { while(true) { ResourceManager.Acquire(); // --- 使用资源 --- ResourceManager.Release(); } } </code></pre> <p><strong>3. 说明</strong></p> <ul> <li><strong>批次控制</strong>: <code>must_wait</code> 标志是实现"批处理"的关键. 当第三个进程获得资源时, 它将 <code>must_wait</code> 设置为 <code>true</code>, 这就像关上了一扇大门, 所有后续到来的进程都会在 <code>wait(next_batch_q)</code> 处被阻塞.</li> <li><strong>批次切换</strong>: 只有当 <code>active_count</code> 降为0时 (即上一批的所有3个进程都已释放资源), 最后一个离开的进程才会将 <code>must_wait</code> 设回 <code>false</code> 并 <code>broadcast</code> 唤醒所有等待的进程.</li> <li><strong>健壮性</strong>: 被 <code>broadcast</code> 唤醒的进程会重新检查 <code>while (must_wait)</code>. 虽然所有等待者都被唤醒, 但只有前3个能够成功通过循环并获得资源. 第4个及以后的进程会发现 <code>active_count</code> 又变成了3, <code>must_wait</code> 再次变为 <code>true</code>, 于是它们会继续 <code>wait</code>, 等待再下一批. 这种 <code>while</code> 循环检查机制是管程编程的黄金法则, 确保了逻辑的正确性.</li> </ul>https://www.lyt0112.com/blog/operating_systems_note_09-zhhttps://www.lyt0112.com/blog/operating_systems_note_09-zhOperating Systems Notes 09: 并发机制Fri, 06 Jun 2025 15:38:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gemini-2.5-pro-preview-06-05</code></p> <p>This article uses LLM to improve efficiency, which can make mistakes. I have tried my best to check and proofread, but still cannot guarantee complete accuracy.</p> <p>For personal use, may be nagging for you.</p> <h2>1. 并发的特征与挑战</h2> <p>并发是操作系统设计的基石。当多个执行单元 (进程/线程) 同时存在于一个系统中时，它们的执行具有以下特征，并带来相应的问题：</p> <ul> <li><strong>间断性</strong>: 执行过程不是连续的，会被操作系统调度中断，切换到其他执行单元。</li> <li><strong>共享</strong>: 多个执行单元可能会访问和操作共同的资源或数据。</li> <li><strong>不可预测性</strong>: 各个执行单元的相对执行速度无法预知，取决于调度策略、系统负载等多种因素。</li> <li><strong>不确定性</strong>: 由于执行速度的不可预测性，程序的执行结果可能是不确定的，这会导致与时间有关的错误。</li> </ul> <h3>1.1. 案例分析：与时间有关的错误</h3> <h4>1.1.1. 银行账户取款问题</h4> <p>假设一个银行账户有5000元，两个ATM机 (T1和T2) 同时对该账户进行取款操作。</p> <ul> <li>T1: 取款1000元</li> <li>T2: 取款2000元</li> </ul> <p>一个可能的错误执行序列如下：</p> <p>| 步骤 | ATM T1 操作 | ATM T2 操作 | 账户余额 (x) | 说明 | | :--- | :-------------- | :-------------- | :----------- | :-------------------------- | | 1 | <code>read(x)</code> | | 5000 | T1 读取余额 5000 | | 2 | | <code>read(x)</code> | 5000 | T2 也读取余额 5000 | | 3 | <code>x := x - 1000</code> | | 4000 | T1 计算新余额 | | 4 | <code>write(x)</code> | | 4000 | T1 将 4000 写回 | | 5 | | <code>x := x - 2000</code> | 3000 | T2 基于它<strong>旧的</strong>读取值计算 | | 6 | | <code>write(x)</code> | 3000 | T2 将 3000 写回 |</p> <p><strong>最终结果</strong>: 账户余额为3000元，但正确结果应为 5000 - 1000 - 2000 = 2000元。银行损失了1000元。这个问题的根源在于T1和T2的操作发生了<strong>交叉</strong>，导致T2的操作覆盖了T1的操作结果。</p> <h4>1.1.2. 共享计数器问题 (C代码及汇编)</h4> <p>一个常见的并发问题是多个线程同时对一个共享变量进行自增操作。</p> <p><strong>C 代码:</strong></p> <pre><code class="language-c">for (i = 0; i &#x3C; niters; i++) cnt++; </code></pre> <p><strong>对应的汇编代码 (以一个线程为例):</strong></p> <pre><code class="language-asm">L3: movq cnt(%rip), %rdx ; (Li) Load: 将 cnt 的值加载到寄存器 %rdx addq $1, %rdx ; (Ui) Update: 将寄存器 %rdx 的值加 1 movq %rdx, cnt(%rip) ; (Si) Store: 将寄存器 %rdx 的值写回内存中的 cnt ... </code></pre> <p><code>L</code>, <code>U</code>, <code>S</code> 这三个步骤合起来才能完成一次 <code>cnt++</code>。在并发环境下，这三个步骤并非原子操作 (不可分割) ，可能被中断。</p> <p><strong>错误的执行交错:</strong> 假设 <code>cnt</code> 初始值为 0，两个线程都想执行 <code>cnt++</code>。</p> <p>| 线程 | 指令 | %rdx1 | %rdx2 | cnt | 说明 | | :--- | :------------ | :---- | :---- | :--- | :------------------ | | 1 | <code>L1</code> (Load) | 0 | - | 0 | 线程1加载 cnt=0 | | 2 | <code>L2</code> (Load) | 0 | 0 | 0 | 线程2也加载 cnt=0 | | 1 | <code>U1</code> (Update) | 1 | 0 | 0 | 线程1计算结果为 1 | | 2 | <code>U2</code> (Update) | 1 | 1 | 0 | 线程2计算结果也为 1 | | 1 | <code>S1</code> (Store) | 1 | 1 | 1 | 线程1将 1 写回 | | 2 | <code>S2</code> (Store) | 1 | 1 | 1 | 线程2将 1 写回 |</p> <p><strong>最终结果</strong>: <code>cnt</code> 的值为1，而不是预期的2。这就是<strong>竞争条件 (Race Condition)</strong> 的典型例子。</p> <p><strong>竞争条件 (Race Condition) 定义</strong>: 两个或多个进程/线程读写某些共享数据，而最终的结果取决于它们运⾏的精确时序。</p> <h4>1.1.3. 线程参数传递问题</h4> <p>在循环中创建线程并传递循环变量的地址是一个非常经典的错误。</p> <p><strong>错误代码示例:</strong></p> <pre><code class="language-c">// Main Thread void *thread(void *vargp); int main() { pthread_t tid; int i; for (i = 0; i &#x3C; 100; i++) { // 传递 i 的地址 pthread_create(&#x26;tid, NULL, thread, &#x26;i); } ... } // Peer Thread void *thread(void *vargp) { // 解引用指针获取值 int i = *((int *)vargp); ... // 保存 i 的值用于后续分析 save_value(i); return NULL; } </code></pre> <p><strong>问题分析</strong>: 所有新创建的线程都共享同一个变量 <code>i</code> 的内存地址。主线程的<code>for</code>循环可能很快就执行完毕，<code>i</code> 的值变成了100。而新创建的线程在这之后才开始执行，当它们去解引用<code>vargp</code>时，访问到的都是主线程栈上那个已经变成100 (或某个中间值) 的<code>i</code>。</p> <p><strong>实验结果</strong>: 实验表明，在多核服务器上，很多线程获取到的 <code>i</code> 值是重复的，甚至是混乱的，很少有线程能拿到从0到99的唯一值。这证明了竞争条件确实发生了。</p> <p><strong>正确做法</strong>: 应该为每个线程传递一个独一无二的内存地址。通常的做法是在主线程中为每个线程动态分配内存 (<code>malloc</code>) ，或者传递值本身 (如果值的大小不超过<code>void*</code>) 。</p> <pre><code class="language-c">// 修正后的主线程循环 for (i = 0; i &#x3C; 100; i++) { int *arg = malloc(sizeof(int)); *arg = i; pthread_create(&#x26;tid, NULL, thread, arg); } // 修正后的子线程 void *thread(void *vargp) { int i = *((int *)vargp); free(vargp); // 释放内存 ... } </code></pre> <h2>2. 进程/线程间的制约关系</h2> <p>在并发环境中，进程/线程之间主要存在两种制约关系。</p> <h3>2.1. 互斥 (Mutual Exclusion)</h3> <ul> <li><strong>原因</strong>: 多个进程/线程需要排他性地使用某个共享资源 (如打印机、共享变量) 。</li> <li><strong>定义</strong>: 当一个进程在使用共享资源时，其他试图使用该资源的进程必须等待。</li> <li><strong>临界资源 (Critical Resource)</strong>: 一次只允许一个进程/线程访问的资源。</li> <li><strong>临界区 (Critical Section)</strong>: 程序中访问临界资源的代码片段。</li> </ul> <p><strong>临界区使用原则</strong>:</p> <ol> <li><strong>有空让进</strong>: 临界区空闲时，允许一个等待的进程进入。</li> <li><strong>无空等待 (互斥)</strong>: 临界区非空闲时，其他进程必须等待。</li> <li><strong>有限等待</strong>: 任何进程请求进入临界区，应在有限时间内得到满足，防止"饿死"。</li> <li><strong>让权等待</strong>: 进程在等待进入临界区时，应放弃CPU，进入阻塞状态，避免"忙等待"。</li> </ol> <h3>2.2. 同步 (Synchronization)</h3> <ul> <li><strong>原因</strong>: 多个进程/线程为了合作完成一个共同任务，需要按照一定的时序关系来执行。</li> <li><strong>定义</strong>: 一个进程的执行需要依赖另一个进程的消息或信号。在收到信号前，该进程会阻塞等待。</li> <li><strong>例子</strong>: 生产者-消费者问题。消费者必须等待生产者生产了产品后才能消费。</li> </ul> <p><strong>用前驱图表示同步关系</strong>: 前驱图是一个有向无环图，用于描述进程间的执行顺序。箭头 <code>p1 -> p2</code> 表示 <code>p1</code> 必须在 <code>p2</code> 之前完成。</p> <p><strong>前驱图 (Precedence Graph)</strong></p> <pre><code class="language-mermaid">graph TD S --> p1 p1 --> p2 p1 --> p5 p2 --> p3 p3 --> p4 p4 --> p5 p5 --> p6 p3 --> p7 p7 --> p6 p6 --> p8 p8 --> F </code></pre> <hr> <h2>3. 解决互斥问题的方案</h2> <h3>3.1. 软件方案</h3> <p>软件方案通过巧妙的算法逻辑来确保互斥，但通常较为复杂且效率不高。</p> <ul> <li><strong>解法1 (单一标志法)</strong>: 使用一个<code>bool free</code>变量。 <ul> <li><strong>问题</strong>: 在<code>while(free);</code>和<code>free=true;</code>之间可能发生上下文切换，两个进程都可能通过<code>while</code>检查，然后都进入临界区。违反"无空等待"。</li> </ul> </li> <li><strong>解法2 (轮转法)</strong>: 使用一个<code>turn</code>变量，<code>turn=true</code>允许P进，<code>turn=false</code>允许Q进。 <ul> <li><strong>问题</strong>: 必须严格轮流进入临界区。如果P不想进入，但<code>turn</code>标志归它，Q也无法进入。违反"有空让进"。</li> </ul> </li> <li><strong>解法3 (双标志法)</strong>: 每个进程有自己的<code>pturn</code>, <code>qturn</code>标志，表示自己想进入。 <ul> <li><strong>问题</strong>: 两个进程可能同时设置自己的标志为<code>true</code>，然后都在<code>while</code>循环中等待对方，导致<strong>死锁</strong>。</li> </ul> </li> <li><strong>Dekker算法 (1965)</strong>: 结合解法2和3，引入<code>turn</code>变量来解决死锁。是第一个被证明正确的纯软件解法，但实现复杂。</li> <li><strong>Peterson算法 (1981)</strong>: 一个更简洁优美的软件解法。</li> </ul> <p><strong>Peterson 算法详解</strong></p> <pre><code class="language-c">#define N 2 // 进程数量 int turn; // 轮到谁 int interested[N]; // 兴趣数组，初始为FALSE void enter_region(int process) { int other = 1 - process; // 另一个进程 interested[process] = TRUE; // 1. 表示自己感兴趣 turn = process; // 2. 将优先权让给后一个运行这行代码的进程 (即可能是对方，如果是自己，那自己就进入临界区) // 3. 当对方感兴趣且优先权在对方时，循环等待 while (turn == process &#x26;&#x26; interested[other] == TRUE) { // busy waiting } } void leave_region(int process) { interested[process] = FALSE; // 离开临界区，不再感兴趣 } </code></pre> <p><strong>工作原理</strong>:</p> <ol> <li><strong>互斥</strong>: 如果两个进程同时调用<code>enter_region</code>，它们都会设置自己的<code>interested</code>为<code>TRUE</code>。但<code>turn</code>变量的写入是原子性的，后写入的会覆盖先写入的。假设进程1后写，则<code>turn=1</code>。此时进程0在<code>while</code>中会发现<code>turn==0 &#x26;&#x26; interested[1]==TRUE</code>不成立，跳出循环进入临界区。而进程1会发现<code>turn==1 &#x26;&#x26; interested[0]==TRUE</code>成立，陷入等待。</li> <li><strong>有空让进</strong>: 如果进程1不感兴趣 (<code>interested[1]==FALSE</code>)，进程0的<code>while</code>条件不成立，直接进入。</li> <li><strong>有限等待</strong>: 不会死锁。即使一个进程在<code>while</code>中等待，一旦另一个进程离开临界区 (设置<code>interested</code>为<code>FALSE</code>) ，等待的进程就能立即进入。</li> </ol> <h3>3.2. 硬件方案</h3> <p>硬件方案利用特殊的CPU指令来提供原子操作，实现起来更简单高效。</p> <h4>3.2.1. 关闭中断 (Disable Interrupts)</h4> <pre><code class="language-c">while (true) { disable_interrupts(); // critical section enable_interrupts(); // remainder section } </code></pre> <ul> <li><strong>原理</strong>: 在单处理器系统中，关闭中断可以阻止操作系统进行上下文切换，从而保证临界区代码的连续执行。</li> <li><strong>优点</strong>: 简单、高效。</li> <li><strong>缺点</strong>: <ul> <li><strong>代价高</strong>: 长期关闭中断会影响系统响应其他事件的能力。</li> <li><strong>不适用于多处理器</strong>: 在多核CPU上，一个核心关闭中断并不能阻止其他核心并发访问共享内存。</li> <li><strong>滥用风险</strong>: 如果把这个权力交给用户进程，一个恶意或有bug的程序可能会导致整个系统瘫痪。因此，它只适用于操作系统内核自身。</li> </ul> </li> </ul> <blockquote> <p><strong>思考题提问</strong>：单处理器下，关闭中断是否符合临界区的使用原则 (有空让进、无空等待、有限等待) ？ <strong>思考题解答</strong>：在单处理器系统中，关闭中断的方式<strong>符合</strong>"有空让进"和"无空等待"原则。因为只有一个处理器，关闭中断后不会被其他进程抢占，能保证互斥和不会出现空等。但它<strong>不一定符合</strong>"有限等待"原则：如果某个进程长时间占用临界区，其他进程会一直等待，甚至可能被饿死。此外，这种方式<strong>不符合</strong>"让权等待"原则，因为等待的进程无法主动让出CPU，整个系统调度被阻塞，属于一种特殊的忙等。</p> </blockquote> <h4>3.2.2. 测试并加锁 (Test-and-Set Lock, TSL) 指令</h4> <p>TSL是一条<strong>原子指令</strong>，它执行两个操作：读取一个内存位置 (锁变量) 的值到寄存器，然后将该内存位置设置为1。</p> <pre><code class="language-asm">enter_region: TSL REGISTER, LOCK ; 原子操作: 将LOCK的值复制到REGISTER, 并将LOCK设为1 CMP REGISTER, #0 ; 比较之前LOCK的值是否为0 JNE enter_region ; 如果不为0 (锁已被占用), 则循环等待 RET ; 如果为0 (成功获取锁), 返回并进入临界区 leave_region: MOVE LOCK, #0 ; 将LOCK的值设为0, 释放锁 RET </code></pre> <ul> <li><strong>原理</strong>: <code>TSL</code>指令的原子性保证了在检查锁和设置锁之间不会有上下文切换。</li> <li><strong>忙等待 (Busy Waiting) / 自旋锁 (Spin Lock)</strong>: 这种实现方式会让等待的进程在一个循环中持续消耗CPU时间，因此也称为自旋锁。</li> <li><strong>优先级反转</strong>: 如果一个低优先级进程持有锁，而一个高优先级进程在自旋等待，就会发生优先级反转。高优先级进程无法执行，而低优先级进程可能得不到CPU时间来释放锁。</li> </ul> <blockquote> <p><strong>思考题提问</strong>: TSL指令对多处理器系统<strong>有效</strong>吗？为什么？ <strong>思考题解答</strong>: TSL指令对多处理器系统<strong>有效</strong>。因为<code>TSL</code>指令会锁定内存总线，确保在它执行期间，其他CPU核心无法访问同一个内存地址<code>LOCK</code>。这保证了操作的原子性是跨核心的。<code>XCHG</code> (原子交换) 指令也能达到同样的效果。</p> </blockquote> <hr> <h2>4. 高级同步机制</h2> <p>软件和硬件方案都存在问题 (复杂性、忙等待等) 。为了解决这些问题，操作系统和编程语言提供了更高级、更易用的同步机制。</p> <h3>4.1. 信号量 (Semaphore) 及 P/V 操作</h3> <p>由Dijkstra在1965年提出，是一种功能强大且经典的同步工具。</p> <ul> <li><strong>定义</strong>: 信号量是一个特殊的整数变量，只能通过两个原子操作来访问：<code>P</code>和<code>V</code>。 <ul> <li><code>P</code> (Proberen, test): 检查并尝试减少信号量的值。</li> <li><code>V</code> (Verhogen, increment): 增加信号量的值。</li> </ul> </li> </ul> <p><strong>本课程定义的 P/V 操作</strong>:</p> <pre><code class="language-c">struct semaphore { int count; // 计数值 queueType queue; // 等待队列 }; // P(s) 操作 - 申请资源 P(s) { s.count--; if (s.count &#x3C; 0) { // 资源不足，阻塞当前进程 block_process(); add_to_queue(s.queue); reschedule(); } } // V(s) 操作 - 释放资源 V(s) { s.count++; if (s.count &#x3C;= 0) { // 有进程在等待，唤醒一个 wakeup_process_from_queue(s.queue); move_to_ready_queue(); } } </code></pre> <ul> <li><strong><code>s.count</code>的含义</strong>: <ul> <li><code>s.count >= 0</code>: 表示可用资源的数量。</li> <li><code>s.count &#x3C; 0</code>: 其绝对值表示正在等待该资源的进程数量。</li> </ul> </li> <li><strong>P/V操作是原语 (Atomic Action)</strong>: 它们的执行不可分割，通常由操作系统通过关闭中断或硬件指令来保证。</li> </ul> <blockquote> <p><strong>问题解答</strong>: 信号量及PV操作<strong>既可以解决互斥问题，也可以解决同步问题</strong>。</p> <ul> <li><strong>解决互斥</strong>: 使用一个<strong>二元信号量</strong> (也叫互斥锁 <code>mutex</code>) ，初值为1。在临界区前后分别调用 <code>P(mutex)</code> 和 <code>V(mutex)</code>。</li> <li><strong>解决同步</strong>: 使用一个<strong>计数信号量</strong>，其初值表示可用资源的数量。例如，同步某个事件的发生，初值为0。等待事件的进程执行 <code>P</code> 操作被阻塞，触发事件的进程执行 <code>V</code> 操作来唤醒等待者。</li> </ul> </blockquote> <h4>4.1.1. 案例：生产者-消费者问题</h4> <p>这是同步问题的经典模型。</p> <ul> <li><strong>问题描述</strong>: 生产者进程向一个有界缓冲区中放入产品，消费者进程从中取出产品。</li> <li><strong>同步要求</strong>: <ol> <li>缓冲区满时，生产者必须停止生产并等待。</li> <li>缓冲区空时，消费者必须停止消费并等待。</li> <li>对缓冲区的访问是临界区，必须互斥。</li> </ol> </li> </ul> <p><strong>信号量解决方案</strong>:</p> <pre><code class="language-c">#define N 100 // 缓冲区大小 semaphore mutex = 1; // 互斥信号量，保护缓冲区访问，初值为1 semaphore empty = N; // 同步信号量，记录空闲缓冲区数量，初值为N semaphore full = 0; // 同步信号量，记录产品数量，初值为0 </code></pre> <p><strong>生产者代码</strong>:</p> <pre><code class="language-c">void producer() { while (TRUE) { item = produce_item(); P(&#x26;empty); // 1. 申请一个空缓冲区 (若无则等待) P(&#x26;mutex); // 2. 锁住缓冲区 insert_item(item); V(&#x26;mutex); // 3. 解锁缓冲区 V(&#x26;full); // 4. 通知有一个产品可用 } } </code></pre> <p><strong>消费者代码</strong>:</p> <pre><code class="language-c">void consumer() { while (TRUE) { P(&#x26;full); // 1. 申请一个产品 (若无则等待) P(&#x26;mutex); // 2. 锁住缓冲区 item = remove_item(); V(&#x26;mutex); // 3. 解锁缓冲区 V(&#x26;empty); // 4. 通知有一个空缓冲区可用 consume_item(item); } } </code></pre> <blockquote> <p><strong>思考题解答</strong>:</p> <ul> <li><strong>颠倒两个P操作的顺序会怎样?</strong> 如果生产者代码变为 <code>P(&#x26;mutex); P(&#x26;empty);</code>。当缓冲区满时 (<code>empty=0</code>)，生产者会先成功执行<code>P(&#x26;mutex)</code>获得互斥锁，然后执行<code>P(&#x26;empty)</code>被阻塞。但因为它持有<code>mutex</code>锁，消费者即使消费了产品想执行<code>V(&#x26;empty)</code>，也无法进入临界区 (被<code>P(&#x26;mutex)</code>阻塞) ，也就无法唤醒生产者。系统发生<strong>死锁</strong>。</li> <li><strong>颠倒两个V操作的顺序会怎样?</strong> <code>V(&#x26;full); V(&#x26;mutex);</code> 颠倒为 <code>V(&#x26;mutex); V(&#x26;full);</code>。这<strong>不会</strong>导致逻辑错误或死锁。释放互斥锁和通知产品可用是两个独立的操作，它们的顺序不影响正确性。但通常建议先<code>V(mutex)</code>再<code>V(full)</code>，这样可以尽快释放临界区，让其他进程进入，提高并发度。</li> </ul> </blockquote> <h4>4.1.2. 案例：第一类读者-写者问题</h4> <ul> <li><strong>问题描述</strong>: 多个进程共享数据，分为读者和写者。</li> <li><strong>要求</strong>: <ol> <li>允许多个读者同时读。</li> <li>只允许一个写者写。</li> <li>读者和写者不能同时访问。</li> </ol> </li> </ul> <p><strong>采用读者优先解法:</strong></p> <p>在这种策略下，只要有读者在读，后续的读者都可以直接进入，写者必须等待所有读者结束后才能进入。可能会导致写者"饿死"。</p> <p><strong>信号量和变量</strong>:</p> <pre><code class="language-c">semaphore w = 1; // 控制写的互斥信号量 semaphore mutex = 1; // 用于保护对 read_count 的修改 int read_count = 0; // 记录当前正在读的读者数量 </code></pre> <p><strong>写者代码</strong>:</p> <pre><code class="language-c">void writer() { while (TRUE) { P(w); // 申请写权限 // 写操作 V(w); // 释放写权限 } } </code></pre> <p><strong>读者代码</strong>:</p> <pre><code class="language-c">void reader() { while (TRUE) { P(mutex); // 锁住 read_count read_count++; if (read_count == 1) { // 第一个读者 P(w); // 阻止写者进入 } V(mutex); // 解锁 read_count // 读操作 P(mutex); // 锁住 read_count read_count--; if (read_count == 0) { // 最后一个读者 V(w); // 允许写者进入 } V(mutex); // 解锁 read_count } } </code></pre> <h3>4.2. 管程 (Monitor)</h3> <p>信号量虽然强大，但使用时容易出错 (比如P/V顺序写反导致死锁) 。管程是一种更高级的、语言层面的同步机制，旨在简化并发编程。</p> <ul> <li><strong>定义</strong>: 管程是一个程序模块，它包含： <ol> <li>一组共享数据结构。</li> <li>一组操作这些数据的过程 (方法) 。</li> <li>一个初始化部分。</li> </ol> </li> <li><strong>核心特性</strong>: <ol> <li><strong>自动互斥</strong>: 编译器保证在任何时刻，最多只有一个进程能在管程内部执行其过程。进程调用管程过程时，会自动获得互斥锁。</li> <li><strong>条件变量 (Condition Variable)</strong>: 用于解决同步问题。它不是一个值，而是一个等待队列。提供<code>wait</code>和<code>signal</code>操作。 <ul> <li><code>c.wait()</code>: 调用此操作的进程会被阻塞，并<strong>释放管程的互斥锁</strong>，然后进入条件变量<code>c</code>的等待队列。</li> <li><code>c.signal()</code>: 如果有进程在条件变量<code>c</code>上等待，则唤醒其中一个。</li> </ul> </li> </ol> </li> </ul> <h4>4.2.1. Hoare 管程 vs. Mesa 管程</h4> <p>当一个在管程中的进程P执行 <code>c.signal()</code> 唤醒了另一个等待的进程Q时，管程中就有了两个活跃进程P和Q。如何处理？</p> <ul> <li> <p><strong>Hoare 管程 (P waits for Q)</strong>:</p> <ul> <li><strong>规则</strong>: P立刻挂起，Q马上执行。P进入一个"紧急等待队列"，优先级高于管程入口的等待队列。当Q执行完毕或再次<code>wait</code>时，P才能恢复执行。</li> <li><strong>优点</strong>: <code>signal</code>之后，被唤醒的进程Q可以确定它等待的条件现在是满足的。可以用<code>if</code>来判断条件。</li> <li><strong>缺点</strong>: 实现复杂，需要多次上下文切换。</li> </ul> </li> <li> <p><strong>Mesa 管程 (P continues, Q waits)</strong>:</p> <ul> <li><strong>规则</strong>: <code>signal</code>操作 (在Mesa中称为<code>notify</code>) 只是一个"提示"。P继续执行，Q从等待队列移到就绪队列，但不会立即执行。Q何时执行取决于调度器。</li> <li><strong>优点</strong>: 实现简单，上下文切换少。</li> <li><strong>缺点</strong>: 当Q最终被调度执行时，它等待的条件可能已经被其他进程改变了。因此，Q被唤醒后必须<strong>重新检查条件</strong>。这导致了著名的<strong>while循环</strong>范式。</li> </ul> </li> </ul> <p><strong>Hoare管程 - 生产者消费者</strong></p> <pre><code class="language-pascal">monitor ProducerConsumer condition full, empty; integer count; procedure insert(item: integer); begin // Hoare管程, signal后条件确定为真, 用if即可 if count == N then wait(full); ... if count == 1 then signal(empty); end; ... end; </code></pre> <p><strong>Mesa管程 - 生产者消费者</strong></p> <p>核心思想是，被唤醒的线程 (无论是生产者还是消费者) 必须用<code>while</code>循环重新检查条件。这是因为从<code>c.notify</code> (通知) 发生，到等待的线程被唤醒并重新获得管程锁的这段时间内，共享状态 (如缓冲区是满是空) 可能已经被其他线程改变了。</p> <p><code>append</code>和<code>take</code>函数的实现如下：</p> <pre><code class="language-c">// Producer Code void append(char x) { // 在Mesa管程中，唤醒的线程必须重新检查条件，因为从notify()发生到线程重新获得管程锁的这段时间内，共享状态 (如缓冲区是满是空) 可能已经被其他线程改变了。 // 这就是为什么必须使用while循环，而不是if语句。 while (count == N) { c.wait(notfull); // 如果缓冲区满了，则等待 } // 添加项目到缓冲区 buffer[nextin] = x; nextin = (nextin + 1) % N; count++; c.notify(notempty); // 通知任何等待的消费者。 } // Consumer Code // 注意：函数签名从 `take(char x)` 改为 `take(char *x)` // 为了通过输出参数返回一个值，使其在C中有效。 void take(char *x) { while (count == 0) { c.wait(notempty); // 如果缓冲区为空，则等待 } // 从缓冲区中移除项目 *x = buffer[nextout]; nextout = (nextout + 1) % N; count--; c.notify(notfull); // 通知任何等待的生产者。 } </code></pre> <p><strong>Mesa管程的改进</strong>:</p> <ul> <li><code>broadcast</code>: 唤醒在某个条件变量上等待的<strong>所有</strong>进程。当不确定哪个进程能满足条件时非常有用。</li> <li><strong>超时 <code>wait</code></strong>: <code>wait</code>操作可以带一个超时参数，防止因信号丢失而导致的永久等待 (饥饿) 。</li> </ul> <h4>4.2.2. Java 中的管程</h4> <p>Java的 <code>synchronized</code> 关键字和 <code>Object</code> 类的 <code>wait()</code>, <code>notify()</code>, <code>notifyAll()</code> 方法是Mesa管程模型的一种实现。</p> <ul> <li><strong><code>synchronized</code></strong>: 任何对象都可以作为锁。当一个线程进入一个对象的<code>synchronized</code>方法或代码块时，它就获得了该对象的锁。这实现了自动互斥。</li> <li><strong><code>wait()</code>, <code>notify()</code>, <code>notifyAll()</code></strong>: 相当于Mesa管程的 <code>cwait</code>, <code>cnotify</code>, <code>cbroadcast</code>。它们必须在<code>synchronized</code>块中调用。</li> </ul> <p><strong>Java 实现生产者消费者</strong>:</p> <pre><code class="language-java">// our_monitor 类的 insert 方法 public synchronized void insert(int val) { // 必须使用 while 循环检查条件 while (count == N) { try { wait(); // 释放锁并等待 } catch (InterruptedException e) {} } // ... 插入数据 ... count++; // 唤醒一个等待的消费者 notifyAll(); // 使用notifyAll更健壮，防止信号丢失 } </code></pre> <h3>4.3. Pthreads 同步机制</h3> <p>Pthreads (POSIX Threads) 是一套标准的线程API，它提供了两种主要的同步工具：互斥锁和条件变量。这套API非常接近Mesa管程模型。</p> <h4>4.3.1. 互斥锁 (Mutex)</h4> <ul> <li><code>pthread_mutex_t</code>: 互斥锁变量类型。</li> <li><code>pthread_mutex_init()</code>: 初始化互斥锁。</li> <li><code>pthread_mutex_lock()</code>: 加锁。如果锁已被占用，线程阻塞。</li> <li><code>pthread_mutex_unlock()</code>: 解锁。</li> <li><code>pthread_mutex_destroy()</code>: 销毁互斥锁。</li> </ul> <h4>4.3.2. 条件变量 (Condition Variable)</h4> <ul> <li><code>pthread_cond_t</code>: 条件变量类型。</li> <li><code>pthread_cond_init()</code>: 初始化条件变量。</li> <li><code>pthread_cond_wait(cond, mutex)</code>: <ol> <li><strong>原子地</strong>解锁 <code>mutex</code>。</li> <li>使线程阻塞在 <code>cond</code> 上。</li> <li>当被唤醒后，<strong>重新自动地</strong>锁上 <code>mutex</code>。</li> </ol> </li> <li><code>pthread_cond_signal(cond)</code>: 唤醒至少一个在<code>cond</code>上等待的线程 (类似<code>notify</code>) 。</li> <li><code>pthread_cond_broadcast(cond)</code>: 唤醒所有在<code>cond</code>上等待的线程 (类似<code>broadcast</code>) 。</li> <li><code>pthread_cond_destroy()</code>: 销毁条件变量。</li> </ul> <h3>3.3.3. Pthreads 解决生产者-消费者问题</h3> <p><strong>代码框架</strong>:</p> <pre><code class="language-c">pthread_mutex_t the_mutex; pthread_cond_t condc, condp; // c:消费者等待条件, p:生产者等待条件 int buffer = 0; void *producer(void *ptr) { for (...) { pthread_mutex_lock(&#x26;the_mutex); // 加锁 // 缓冲区不为空(已被填充), 生产者等待 while (buffer != 0) { pthread_cond_wait(&#x26;condp, &#x26;the_mutex); } buffer = i; // 生产 pthread_cond_signal(&#x26;condc); // 唤醒消费者 pthread_mutex_unlock(&#x26;the_mutex); // 解锁 } } void *consumer(void *ptr) { for (...) { pthread_mutex_lock(&#x26;the_mutex); // 加锁 // 缓冲区为空, 消费者等待 while (buffer == 0) { pthread_cond_wait(&#x26;condc, &#x26;the_mutex); } buffer = 0; // 消费 pthread_cond_signal(&#x26;condp); // 唤醒生产者 pthread_mutex_unlock(&#x26;the_mutex); // 解锁 } } </code></pre> <blockquote> <p><strong>重点讨论</strong>: 为什么 <code>pthread_cond_wait</code> 必须用 <code>while</code> 循环包裹？</p> <ol> <li><strong>虚假唤醒 (Spurious Wakeup)</strong>: 在某些系统实现中，线程可能在没有<code>signal</code>或<code>broadcast</code>的情况下被唤醒。</li> <li><strong>Mesa模型特性</strong>: 正如之前讨论的，<code>signal</code>只是一个提示。从线程被唤醒到它实际运行并重新获得锁之间，它等待的条件可能已经被其他线程改变了。</li> </ol> <p>如果使用 <code>if</code>，线程被唤醒后会盲目地继续执行，可能会操作一个不满足条件的共享状态，导致错误。<code>while</code>循环确保线程在继续执行前，必须重新验证条件是否为真。</p> </blockquote> <hr> <h2>5. 锁的实现与现代硬件</h2> <h3>5.1. 锁 (Mutex) 的实现</h3> <p>锁是实现其他高级同步机制的基础。</p> <h4>5.1.1. 基于开关中断的实现</h4> <p>这种方法有严重缺陷。 <strong>错误实现</strong>:</p> <pre><code class="language-c">lock() { disable_interrupts(); while (value != FREE); // 忙等待，且中断被关闭 value = BUSY; enable_interrupts(); } </code></pre> <p><strong>问题</strong>: 如果锁被占用，<code>while</code>循环会一直执行，而中断是关闭的，持有锁的线程永远无法被调度来释放锁，导致系统死锁。</p> <p><strong>稍好的实现</strong>:</p> <pre><code class="language-c">lock() { disable_interrupts(); while (value != FREE) { enable_interrupts(); // 循环时临时开中断 // some delay... disable_interrupts(); // 再次检查前关中断 } value = BUSY; enable_interrupts(); } </code></pre> <p><strong>问题</strong>: 在 <code>enable_interrupts()</code> 和下一次 <code>disable_interrupts()</code> 之间，可能会一直被新的 <code>lock</code> 调用阻塞导致饥饿。</p> <p><strong>正确的无忙等待实现 (OS内核级)</strong>:</p> <pre><code class="language-c">lock() { disable_interrupts(); if (value == FREE) { value = BUSY; } else { // (1) add_thread_to_queue; // (2) switch_to_next_thread; // (3) } enable_interrupts(); } </code></pre> <blockquote> <p><strong>思考题解答</strong>:</p> <p>这段代码展示了操作系统内核在获取锁失败时，如何让线程休眠等待。为防止竞态条件，从关中断到线程安全地休眠或成功获取锁的整个过程，其原子性至关重要。</p> <ul> <li><strong>在位置 (1) 开中断（入队前）：不可行</strong> ❌ <ul> <li><strong>风险</strong>: <strong>"丢失唤醒" (Lost Wakeup)</strong>。如果在此处开启中断，持有锁的线程可能会立即运行并释放锁。<code>unlock</code> 操作会检查等待队列，但因为当前线程还未入队，所以它不会被唤醒。当中断返回后，当前线程会继续执行，将自己加入一个空队列并进入休眠，从而永久错过了已经发生的唤醒信号。</li> <li><strong>结论</strong>: 检查锁的状态和将线程加入等待队列必须合并为一个原子操作。</li> </ul> </li> <li><strong>在位置 (2) 开中断（休眠前）：不可行</strong> ❌ <ul> <li><strong>风险</strong>: <strong>同样是"丢失唤醒"</strong>。线程已在队列中，但尚未调用 <code>switch_to_next_thread</code> 进入休眠状态。如果此时被唤醒（例如，状态被置为 <code>READY</code>），它紧接着会继续执行 <code>switch_to_next_thread</code>，该操作会将其状态置为 <code>BLOCKED</code> 并让出CPU。结果是，线程刚被唤醒，马上又睡着了，导致唤醒操作被无效化。</li> <li><strong>结论</strong>: 将线程加入队列和使其休眠也必须是一个原子操作。</li> </ul> </li> <li><strong>在位置 (3) 开中断（唤醒后）：可行且必要</strong> ✅ <ul> <li><strong>状态</strong>: 线程执行到这里，意味着它已经被其他线程（通过 <code>unlock</code>）唤醒，并且调度器已选择它重新运行。此时，该线程已经"获得"了锁的所有权，但CPU仍处于之前 <code>lock</code> 操作时关闭中断的状态。</li> <li><strong>操作</strong>: 在 <code>lock()</code> 函数返回、进入临界区代码之前，<strong>必须</strong>重新开启中断，以保证系统的正常响应。代码中，执行路径会自然地落到最后的 <code>enable_interrupts()</code>，这在逻辑上是完全正确的。</li> </ul> </li> </ul> </blockquote> <h4>5.1.2. 基于 TSL 指令的实现 (带让出CPU)</h4> <p>为了避免纯粹的自旋消耗CPU，可以在尝试获取锁失败后，主动让出CPU。</p> <pre><code class="language-asm">mutex_lock: TSL REGISTER, MUTEX ; 尝试获取锁 CMP REGISTER, #0 ; 检查之前是否锁着 JZE ok ; 成功获取，跳转到ok CALL thread_yield ; 失败，调用线程调度，让出CPU JMP mutex_lock ; 被唤醒后，重新尝试 ok: RET </code></pre> <p>这种方式结合了硬件原子指令和操作系统的调度，比纯自旋锁要好，但仍然有尝试-失败的开销。</p> <h3>5.2. 现代并发机制拓展</h3> <h4>5.2.1. Futex (Fast Userspace Mutex)</h4> <p>Futex是Linux中一种高效的锁机制，它结合了用户空间和内核空间的优点。</p> <ul> <li><strong>快速路径 (Fast Path)</strong>: 在无竞争的情况下，锁的获取和释放完全在用户空间通过原子操作完成，无需进入内核，开销极小。</li> <li><strong>慢速路径 (Slow Path)</strong>: 当发生锁竞争时，线程通过系统调用进入内核，将自己置于等待队列并睡眠，由内核负责唤醒。</li> <li><strong>两阶段锁</strong>: 这种思想可以演变为两阶段锁：第一阶段在用户态自旋一小段时间 (期望锁很快被释放) ，如果失败，第二阶段再进入内核休眠。</li> </ul> <h4>5.2.2. 现代硬件支持</h4> <ul> <li><strong>指令重排 (Instruction Reordering)</strong>: 为了优化性能，CPU和编译器可能会改变指令的执行顺序。这在单线程下不影响结果，但在多线程下可能破坏程序员预期的同步逻辑。需要使用<strong>内存屏障 (Memory Fence/Barrier)</strong> 来阻止重排。</li> <li><strong>更多原子指令</strong>: <ul> <li><strong>CAS (Compare-and-Swap)</strong>: <code>CAS(addr, old, new)</code> 原子地检查 <code>*addr</code> 是否等于 <code>old</code>，如果是，就把它更新为 <code>new</code>。这是实现<strong>无锁数据结构</strong> (lock-free) 和乐观锁的基础。</li> <li><strong>Fetch-and-Add</strong>: 原子地读取一个值并给它加上一个数。</li> </ul> </li> <li><strong>CSP (Communicating Sequential Processes) 模型</strong>: 与通过共享内存和锁进行同步不同，CSP模型强调进程之间通过显式的<strong>通信通道 (Channel)</strong> 来传递消息和同步。Go语言的<code>channel</code>就是基于此模型，它能有效避免竞争条件和死锁问题。</li> </ul>https://www.lyt0112.com/blog/operating_systems_note_08-zhhttps://www.lyt0112.com/blog/operating_systems_note_08-zhOperating Systems Notes 08: 文件系统 2Sun, 18 May 2025 19:17:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gemini-2.5-pro-preview-06-05</code></p> <p>This article uses LLM to improve efficiency, which can make mistakes. I have tried my best to check and proofread, but still cannot guarantee complete accuracy.</p> <p>For personal use, may be nagging for you.</p> <h2>1. 文件系统的管理</h2> <p>文件系统的管理主要涵盖三个方面：<strong>可靠性</strong>、<strong>一致性</strong>和<strong>安全性</strong>。</p> <h3>1.1 文件系统的可靠性</h3> <p>可靠性指的是文件系统抵御和预防各种物理性或人为性破坏的能力。</p> <h4>1.1.1 坏块问题</h4> <p>磁盘上可能会出现物理损坏的块，称为坏块。文件系统需要能够识别、标记并隔离这些坏块，避免将数据写入其中。</p> <h4>1.1.2 备份 (Backup)</h4> <p>备份是通过转储操作，为文件或整个文件系统创建多个副本，以便在发生数据丢失或损坏时进行恢复。主要有以下几种备份方式：</p> <ul> <li><strong>全量转储 (Full Dump)</strong>: 定期将<strong>所有</strong>文件完整地拷贝到备份存储器（如磁带、另一块硬盘）上。这种方式最简单，但如果数据量大且变化少，会非常耗时且浪费存储空间。</li> <li><strong>增量转储 (Incremental Dump)</strong>: 只转储自上次备份以来被<strong>修改过</strong>的文件。这种方式可以显著减少备份所需的时间和空间开销。</li> <li><strong>物理转储 (Physical Dump)</strong>: 从磁盘的第一个物理块（0号块）开始，按顺序将所有磁盘块的内容原封不动地输出到备份介质。这种方式不关心文件系统的逻辑结构，备份和恢复速度快，但不够灵活。</li> <li><strong>逻辑转储 (Logical Dump)</strong>: 从一个或多个指定的目录开始，递归地遍历文件树，只转储那些自某个给定日期之后发生过修改的文件和目录。这种方式更灵活，可以支持更复杂的需求，例如恢复单个文件或目录。</li> </ul> <h3>1.2 文件系统的一致性</h3> <h4>1.2.1 问题来源</h4> <p>文件系统的操作通常不是原子性的。例如，更新一个文件可能需要修改数据块、i-node（索引节点）和空闲块列表。这些修改通常先在内存的缓冲区中进行，然后再一次性或分批写回磁盘。如果在数据完全写回磁盘之前系统发生崩溃（例如突然断电），磁盘上的文件系统状态就可能处于一种中间状态，导致不一致。</p> <p>例如，一个数据块可能既被一个文件引用，又同时存在于空闲块列表中。</p> <h4>1.2.2 解决方案</h4> <h5>1.2.2.1 文件系统检查工具 (fsck)</h5> <p>为了解决不一致问题，可以设计一个实用程序（在UNIX/Linux中通常是 <code>fsck</code>），在系统启动时运行，检查并修复文件系统的逻辑结构。</p> <ul> <li> <p><strong>UNIX <code>fsck</code> 的工作过程示例</strong>: <code>fsck</code> 会使用两张表来辅助检查，表的条目数与磁盘块数相同。</p> <ul> <li><strong>表1</strong>: 用于记录每个磁盘块在<strong>文件中</strong>被引用的次数。</li> <li><strong>表2</strong>: 用于记录每个磁盘块在<strong>空闲块列表</strong>中出现的次数。</li> </ul> <p><code>fsck</code> 会遍历整个文件系统的元数据（如i-node和间接块），填充这两张表。理想情况下，对于任何一个磁盘块，它要么在表1中的计数为1，表2中的计数为0（已被分配）；要么在表1中的计数为0，表2中的计数为1（是空闲的）。</p> <p>下面是几种不一致的情况及其修复方法：</p> <ul> <li><strong>情况A：一个块在空闲列表中，但未被任何文件使用。</strong> 这是正常状态。</li> <li><strong>情况B：一个块在空闲列表中，同时也被文件使用（表1计数>0，表2计数>0）。</strong> 这是严重错误。<code>fsck</code> 会将其从空闲列表中移除来解决。</li> <li><strong>情况C：一个块既不在空闲列表，也未被任何文件使用（表1计数=0，表2计数=0）。</strong> 这会导致块资源泄露。<code>fsck</code> 会将其添加到空闲列表中。</li> <li><strong>情况D：一个块被两个或多个文件同时使用（表1计数>1）。</strong> 这也是严重错误。<code>fsck</code> 通常会复制该块，让每个文件拥有自己的副本。</li> </ul> <pre><code class="language-mermaid">graph TD A[开始检查] --> B{遍历所有i-node}; B --> C{填充'文件引用计数表'}; A --> D{扫描空闲块列表}; D --> E{填充'空闲块计数表'}; F{分析两张表}; C --> F; E --> F; F --> G{不一致?}; G -- 是 --> H[根据规则修复]; G -- 否 --> I[结束]; H --> I; </code></pre> </li> </ul> <h5>1.2.2.2 文件系统写入方式</h5> <p>为了在性能和一致性之间取得平衡，发展出了不同的写入策略。</p> <ul> <li><strong>通写 (Write-through)</strong>: 内存缓冲区的修改<strong>立即</strong>写回磁盘。这种方式能最大程度保证数据一致性，但因为频繁的磁盘I/O，性能非常差。FAT文件系统是典型的例子。</li> <li><strong>延迟写 (Lazy-write)</strong>: 修改只在内存缓冲区中进行，由操作系统决定何时将这些"脏"的缓冲区（write-back cache）写回磁盘。这种方式性能很好，但如果系统在写回前崩溃，数据丢失的风险很高，可恢复性差。</li> <li><strong>可恢复写 (Journaling / Transaction Log)</strong>: 这是在安全性和性能之间的一个优秀折中。在对文件系统的元数据进行实际修改之前，先把要做的<strong>操作步骤</strong>（事务日志，Journal/Log）记录下来并写入磁盘。如果系统在修改过程中崩溃，重启后只需读取日志，就能重做（redo）未完成的操作，或撤销（undo）不完整的操作，从而快速恢复到一致状态。NTFS和现代Linux文件系统（如ext4）都采用了这种技术。</li> </ul> <h3>1.3 文件系统的安全性</h3> <p>安全性旨在确保数据不会丢失或被未经授权的用户访问。</p> <h4>1.3.1 威胁来源</h4> <ul> <li><strong>数据丢失</strong>: 可能源于硬件或软件故障、自然灾害，甚至是人为失误。<strong>备份</strong>是应对这类威胁的主要手段。</li> <li><strong>入侵者</strong>: <ul> <li>非技术人员的偶然窥探。</li> <li>有目的性的入侵者窥探。</li> <li>明确的偷窃企图。</li> <li>商业或军事间谍活动。</li> </ul> </li> </ul> <h4>1.3.2 文件保护机制</h4> <h5>1.3.2.1 用户身份验证</h5> <p>这是保护的第一道防线，用于在用户登录时验证其身份。常见方法包括：</p> <ul> <li><strong>用户知道什么</strong>: 口令（Password）、密码。</li> <li><strong>用户拥有什么</strong>: 磁卡、智能卡、USB Key。</li> <li><strong>用户是什么 (生物特征)</strong>: 指纹、虹膜、人脸识别、声纹等。</li> <li><strong>CAPTCHA测试</strong>: 用于区分人类和计算机程序。</li> </ul> <h5>1.3.2.2 访问控制</h5> <p>当用户身份被确认后，系统需要决定该用户能对哪些文件进行哪些操作。主要有两种实现模型：</p> <p>| 特性 | 访问控制表 (ACL - Access Control List) | 能力表 (Capability List) | | :----------- | :------------------------------------- | :------------------------------------- | | <strong>核心思想</strong> | 以 <strong>资源 (文件)</strong> 为中心 | 以 <strong>用户 (主体)</strong> 为中心 | | <strong>数据结构</strong> | 每个文件附加一个列表，记录(用户, 权限) | 每个用户持有一个列表，记录(文件, 权限) | | <strong>查询方式</strong> | "谁能访问我？" | "我能访问谁？" | | <strong>存放位置</strong> | 内核空间 | 内核空间 | | <strong>常见场景</strong> | 文件系统（如Unix权限、NTFS ACL） | Kerberos, OAuth (能力凭证) |</p> <ul> <li><strong>思考：这两种访问控制方式的优缺点是什么？</strong> <ul> <li><strong>ACL的优点</strong>：管理特定资源的权限非常直观和方便。很容易回答"谁能访问这个文件？"。</li> <li><strong>ACL的缺点</strong>：当需要查看某个用户的所有权限时，必须遍历系统中所有文件的ACL，效率低下。权限的撤销也很直接（从ACL中移除即可）。</li> <li><strong>能力表的优点</strong>：查看某个用户的所有权限非常高效。用户在访问时主动出示"能力凭证"，验证逻辑简单。</li> <li><strong>能力表的缺点</strong>：权限的撤销比较困难，因为能力凭证已经被分发出去，系统需要有机制让它们失效。同时，很难回答"谁能访问这个文件？"，需要检查所有用户的能力表。</li> </ul> </li> </ul> <h5>1.3.2.3 拓展访问控制模型</h5> <ul> <li><strong>RBAC (Role-Based Access Control, 基于角色的访问控制)</strong>: 在用户和权限之间引入"角色"层。权限被赋予角色，而用户被分配角色。当需要修改一组用户的权限时，只需修改角色的权限即可，大大简化了管理。例如，公司里的"财务"角色拥有访问财务报表的权限，"人事"角色拥有访问员工档案的权限。</li> <li><strong>ABAC (Attribute-Based Access Control, 基于属性的访问控制)</strong>: 这是最灵活的模型。访问决策基于用户、资源、环境等多种<strong>属性</strong>的组合。例如，可以制定一个规则："'医生'角色的用户，在'工作时间'内，从'医院内网'访问其'自己病人'的'病历'，可以被允许"。</li> </ul> <h5>1.3.2.4 UNIX的文件保护机制</h5> <p>UNIX采用了一种简化的、两级访问控制机制。</p> <ul> <li> <p><strong>第一级：对访问者的识别</strong></p> <ul> <li><strong>文件主 (owner)</strong>: 创建文件的用户。</li> <li><strong>文件主的同组用户 (group)</strong>: 与文件主在同一个用户组的用户。</li> <li><strong>其他用户 (other)</strong>: 系统中的所有其他用户。</li> </ul> </li> <li> <p><strong>第二级：对操作权限的识别</strong></p> <ul> <li><strong>读操作 (r)</strong>: read</li> <li><strong>写操作 (w)</strong>: write</li> <li><strong>执行操作 (x)</strong>: execute</li> </ul> </li> </ul> <p>这两种分类组合成了经典的 <code>rwxrwxrwx</code> 9-bit 权限模式。例如：<code>rwx r-x r--</code></p> <ul> <li><code>rwx</code> (二进制111，八进制7): 文件主拥有读、写、执行权限。</li> <li><code>r-x</code> (二进制101，八进制5): 同组用户拥有读、执行权限。</li> <li><code>r--</code> (二进制100，八进制4): 其他用户仅拥有读权限。</li> </ul> <p><code>chmod 755 file</code> 命令就是将文件的权限设置为 <code>rwxr-xr-x</code>。</p> <h3>1.4 数据恢复技术</h3> <p>数据恢复的原理在于，当文件被删除或分区被格式化时，存储介质上的数据通常没有被立即清除，只是文件系统用于索引这些数据的元信息（如目录项、FAT表、i-node）被修改或清除了。只要这些数据没有被新的数据覆盖，就有可能被恢复。</p> <hr> <h2>2. 文件系统的性能</h2> <p>磁盘I/O是计算机系统中最慢的环节之一，因此提高文件系统性能的核心在于<strong>减少磁盘访问次数</strong>。</p> <h3>2.1 磁盘高速缓存 (Disk Cache / Buffer Cache)</h3> <p>这是最重要和最有效的性能提升手段。</p> <ul> <li><strong>原理</strong>: 在内存中开辟一块区域，用于缓存从磁盘读出的数据块的副本。</li> <li><strong>工作流程</strong>: <ol> <li>当进程请求读取某个磁盘块时，系统首先检查该块是否已在缓存中。</li> <li>如果在（称为<strong>缓存命中，Cache Hit</strong>），则直接从内存中读取数据，无需访问磁盘。</li> <li>如果不在（称为<strong>缓存未命中，Cache Miss</strong>），系统会从磁盘读取该块，存入缓存，然后再提供给进程。</li> </ol> </li> <li><strong>局部性原理</strong>: 由于程序的访问具有<strong>时间局部性</strong>（一个数据被访问后，短时间内可能再次被访问）和<strong>空间局部性</strong>（一个数据被访问后，其附近的数据也可能很快被访问），缓存的命中率通常很高。</li> <li><strong>缓存置换算法</strong>: 当缓存满了之后，需要选择一个块来替换出去。常用算法是 <strong>LRU (Least Recently Used, 最近最少使用)</strong>，即替换掉最长时间没有被访问过的块。</li> <li><strong>一致性问题</strong>: 延迟写（write-back）策略会带来一致性问题。如果一个被修改的缓存块（脏块）在写回磁盘前系统崩溃，修改就会丢失。</li> </ul> <pre><code class="language-mermaid">graph TD subgraph "操作系统内核 (Kernel Level)" A[文件子系统] B[缓冲区缓存 Buffer Cache] C[设备驱动] A &#x3C;--> B B &#x3C;--> C end subgraph "用户态 (User Level)" D[用户程序] end subgraph "硬件 (Hardware Level)" E[磁盘] end D -- "系统调用" --> A C &#x3C;--> E </code></pre> <h3>2.2 提前读取 (Prefetch / Read-ahead)</h3> <ul> <li><strong>思路</strong>: 基于<strong>空间局部性原理</strong>，当系统读取一个块时，它会猜测程序接下来可能会访问相邻的块，于是"提前"将这些块也读入缓存。</li> <li><strong>开销</strong>: 额外开销很小，因为磁盘寻道和旋转定位的时间已经付出，多读几个连续的块只增加了少量数据传输时间。</li> </ul> <h3>2.3 合理分配磁盘空间</h3> <ul> <li><strong>思路</strong>: 将逻辑上连续的文件块，在物理上也存放在相邻的位置，最好是在同一个柱面上。</li> <li><strong>目标</strong>: 减少磁盘臂的移动（寻道时间）。</li> <li><strong>例子：柱面组 (Cylinder Group)</strong>: 像Berkeley FFS这样的文件系统会将磁盘划分为多个柱面组。每个柱面组都有自己的i-node区和数据块区。当创建一个新文件时，系统会尽量将其i-node和数据块都分配在同一个柱面组内，从而将访问局部化。</li> </ul> <h3>2.4 磁盘调度</h3> <p>当有多个磁盘I/O请求在队列中等待时，调度算法决定了为哪个请求服务的顺序。 一次访盘时间 = 寻道时间 + 旋转延迟时间 + 传输时间。 调度的主要目标是<strong>减少总的寻道时间</strong>。</p> <ul> <li><strong>问题示例</strong>: <ul> <li>磁盘请求队列 (按到达顺序): 98, 183, 37, 122, 14, 124, 65, 67</li> <li>磁头初始位置: 53</li> <li>磁盘柱面范围: 0-199 (假设)</li> </ul> </li> </ul> <h4>2.4.1 先来先服务 (FCFS - First-Come, First-Served)</h4> <ul> <li><strong>策略</strong>: 按请求到达的顺序处理。</li> <li><strong>服务序列</strong>: 53 -> 98 -> 183 -> 37 -> 122 -> 14 -> 124 -> 65 -> 67</li> <li><strong>磁头移动距离</strong>: (98-53) + (183-98) + (183-37) + (122-37) + (122-14) + (124-14) + (124-65) + (67-65) = 45 + 85 + 146 + 85 + 108 + 110 + 59 + 2 = <strong>640</strong> 个磁道。</li> <li><strong>评价</strong>: 公平，但效率低下，磁头可能在磁盘两端来回移动。</li> </ul> <h4>2.4.2 最短寻道时间优先 (SSTF - Shortest Seek Time First)</h4> <ul> <li><strong>策略</strong>: 优先服务与当前磁头位置最近的请求。</li> <li><strong>服务序列</strong>: 53 -> 65 -> 67 -> 37 -> 14 -> 98 -> 122 -> 124 -> 183</li> <li><strong>磁头移动距离</strong>: (65-53) + (67-65) + (67-37) + (37-14) + (98-14) + (122-98) + (124-122) + (183-124) = 12 + 2 + 30 + 23 + 84 + 24 + 2 + 59 = <strong>236</strong> 个磁道。</li> <li><strong>评价</strong>: 性能比FCFS好很多，但可能导致"饥饿"现象，即离磁头较远的请求可能长时间得不到服务。</li> </ul> <h4>2.4.3 扫描算法 (SCAN / Elevator Algorithm)</h4> <ul> <li><strong>策略</strong>: 磁头在一个方向上移动，服务所有沿途的请求，直到到达磁盘末端，然后反转方向继续。</li> <li><strong>服务序列 (假设初始向磁道号减小的方向移动)</strong>: 53 -> 37 -> 14 -> (到达0) -> 65 -> 67 -> 98 -> 122 -> 124 -> 183</li> <li><strong>磁头移动距离</strong>: (53-0) + (183-0) = 53 + 183 = <strong>236</strong> 个磁道。</li> <li><strong>评价</strong>: 性能较好，且避免了饥饿。但对两端的请求不公平，中间区域的请求被服务得更频繁。</li> </ul> <h4>2.4.4 单向扫描算法 (C-SCAN - Circular SCAN)</h4> <ul> <li><strong>策略</strong>: 磁头只在一个方向上服务请求（例如从0到199）。到达末端后，立即返回到起始端（0号），不服务任何请求，然后开始下一轮扫描。</li> <li><strong>服务序列 (假设初始向磁道号增加的方向移动)</strong>: 53 -> 65 -> 67 -> 98 -> 122 -> 124 -> 183 -> (到199) -> (跳回0) -> 14 -> 37</li> <li><strong>评价</strong>: 提供了更均匀的等待时间。</li> </ul> <h4>2.4.5 N-Step-SCAN 和 FSCAN</h4> <p>这两种是SCAN的变种，旨在解决"磁头臂粘性"问题（即在处理当前队列时，新来的请求如果恰好在磁头附近，会插队，导致磁头长时间停留在一个区域）。</p> <ul> <li><strong>N-Step-SCAN</strong>: 将请求队列分成长度为N的子队列，按顺序处理。在处理一个子队列时，新来的请求放入其他队列。</li> <li><strong>FSCAN</strong>: 使用两个队列。扫描开始时，所有请求在一个队列，另一个为空。扫描期间，新请求放入空队列，直到当前队列处理完毕再切换。</li> </ul> <h4>2.4.6 练习题解答</h4> <ul> <li> <p><strong>练习1</strong>:</p> <ul> <li>请求列表 (柱面, 磁头, 扇区): (5,4,1), (5,1,5), (5,4,5), (5,2,8)</li> <li><strong>分析</strong>: 所有请求都在同一个柱面（5号）。因此，寻道时间为0。我们需要优化旋转延迟。假设磁头从0扇区开始旋转，服务顺序应按扇区号从小到大排列。</li> <li><strong>最优次序</strong>: (5,4,1) -> (5,1,5) -> (5,4,5) -> (5,2,8)。注意，(5,1,5)和(5,4,5)扇区号相同，可以在同一旋转位置被不同磁头服务，它们的先后顺序不影响时间。</li> </ul> </li> <li> <p><strong>练习2</strong>:</p> <ul> <li>请求列表 (柱面, 磁头, 扇区): ①(9,6,3), ②(7,5,6), ③(15,20,6), ④(9,4,4), ⑤(20,9,5), ⑥(7,15,2)</li> <li>磁头初始位置: 8号柱面</li> <li><strong>分析</strong>: 这是一个综合优化问题，需要结合寻道和旋转。我们采用SSTF策略来决定柱面访问顺序。 <ol> <li>当前在柱面8。最近的请求是柱面7和9。</li> <li>访问柱面9的请求①和④。移动1个柱面。</li> <li>访问柱面7的请求②和⑥。移动2个柱面。</li> <li>访问柱面15的请求③。移动8个柱面。</li> <li>访问柱面20的请求⑤。移动5个柱面。</li> </ol> </li> <li><strong>最优柱面访问次序</strong>: 8 -> 9 -> 7 -> 15 -> 20。</li> <li><strong>最终请求服务次序</strong>: 先后访问柱面9上的请求（①和④），再访问柱面7上的请求（⑥和②），然后是柱面15（③），最后是柱面20（⑤）。在同一柱面内，按扇区号优化。所以响应次序是 <strong>④ -> ① -> ⑥ -> ② -> ③ -> ⑤</strong> (假设磁头从0扇区开始转，先遇到4扇区再遇到3扇区，先遇到2扇区再遇到6扇区)。</li> </ul> </li> </ul> <h3>2.5 信息的优化分布 (Optimized Information Layout on Disk)</h3> <ul> <li> <p><strong>问题</strong>: 记录在磁道上的物理排列方式会影响顺序读写操作的效率。</p> </li> <li> <p><strong>例子场景</strong>:</p> <ul> <li>一个处理程序要求按顺序处理文件中的8个逻辑记录。</li> <li>磁盘旋转一周为20毫秒 (假设每转处理完所有可见记录)。</li> <li>处理器处理一个记录需要5毫秒。</li> </ul> </li> <li> <p><strong>图示分析 (Interleaving - 交叉因子)</strong>:</p> <ul> <li><strong>无交叉 (Sequential Layout)</strong>: 逻辑记录1, 2, 3, ... 存放在物理扇区 1, 2, 3, ... <ul> <li>读取记录1 (假设1ms传输) -> 处理记录1 (5ms)。</li> <li>在处理记录1的5ms期间，磁盘继续旋转。当处理完毕准备读取记录2时，记录2所在的扇区可能已经转过磁头，需要等待几乎一整圈 (接近20ms) 才能再读到记录2。</li> <li>总时间 = 8 * (1ms读 + 5ms处理 + ~19ms等待) = 8 * 25ms = 200ms (估算)。</li> </ul> </li> <li><strong>有交叉 (Interleaved Layout)</strong>: 为了匹配处理速度和磁盘旋转速度，逻辑记录的存放可以跳过一些物理扇区。 <ul> <li>例如，如果每处理一个记录磁盘转过N个扇区，那么逻辑记录i和逻辑记录i+1之间应该间隔N-1个物理扇区。</li> <li>假设5ms处理时间对应磁盘转过1/4圈 (5ms/20ms)。如果一圈有8个扇区 (简化) ，则转过2个扇区。那么交叉因子可以是2。</li> <li>记录1在扇区1。读1，处理1。此时磁盘可能到了扇区3附近。如果记录2放在扇区3，则可以立即读取。</li> <li><strong>物理扇区应该如何安排</strong>: <ul> <li>逻辑记录: 1 2 3 4 5 6 7 8</li> <li>物理扇区: 1 4 7 2 5 8 3 6 (假设交叉因子为2，即跳过2个物理扇区)</li> </ul> </li> <li><strong>目标</strong>: 当CPU处理完当前记录后，下一个逻辑记录所在的物理扇区正好旋转到磁头下，从而避免或减少旋转等待时间。</li> </ul> </li> </ul> </li> </ul> <h3>2.6 RAID技术 (Redundant Arrays of Independent Disks)</h3> <p>RAID通过将多块独立的磁盘组合成一个逻辑单元，来提供比单个磁盘更高的性能、更大的容量和更好的容错能力。</p> <ul> <li> <p><strong>核心思想</strong>:</p> <ol> <li><strong>数据分条 (Striping)</strong>: 将数据分成小块（条带），并行地写入/读出多块磁盘，以提高吞吐率。</li> <li><strong>冗余 (Redundancy)</strong>: 通过镜像或校验码来提供容错能力。</li> </ol> </li> <li> <p><strong>主要RAID级别</strong>:</p> <ul> <li><strong>RAID 0 (条带化)</strong>: 纯粹的数据分条，没有冗余。读写性能最佳，但任何一块磁盘损坏都会导致所有数据丢失。</li> </ul> <pre><code class="language-mermaid">graph TD D0["Disk 0"] D1["Disk 1"] D2["Disk 2"] D3["Disk 3"] subgraph "Logic Data" S0[Stripe 0] --> D0; S1[Stripe 1] --> D1; S2[Stripe 2] --> D2; S3[Stripe 3] --> D3; S4[Stripe 4] --> D0; S5[Stripe 5] --> D1; end </code></pre> <ul> <li><strong>RAID 1 (镜像)</strong>: 将数据完全复制到另一块磁盘。提供最高的数据安全性，但磁盘利用率只有50%。</li> </ul> <pre><code class="language-mermaid">graph TD D0["Disk 0 (Primary)"] D1["Disk 1 (Mirror)"] subgraph "Logic Data" S0[Stripe 0] --> D0; S0_M[Stripe 0] --> D1; S1[Stripe 1] --> D0; S1_M[Stripe 1] --> D1; end </code></pre> <ul> <li><strong>RAID 3 (字节级带奇偶校验的条带化)</strong>: 数据以字节为单位分条，并使用一块专用磁盘存储奇偶校验码。</li> <li><strong>RAID 4 (块级带奇偶校验的条带化)</strong>: 与RAID 3类似，但以块为单位。校验盘成为写入瓶颈。</li> <li><strong>RAID 5 (块级带分布式奇偶校验的条带化)</strong>: 将校验块分布到阵列中的所有磁盘上，消除了RAID 4的校验盘瓶颈。是性能、成本和可靠性之间的一个良好平衡。`</li> <li><strong>RAID 6 (双重分布式奇偶校验)</strong>: 在RAID 5的基础上增加了第二个独立的校验块。可以容忍两块磁盘同时损坏，可靠性更高，但写入性能和成本代价也更大。</li> <li><strong>RAID 1+0 (或RAID 10)</strong>: 先做镜像，再做条带化。性能和可靠性都很好，但成本高。</li> <li><strong>RAID 0+1</strong>: 先做条带化，再做镜像。容错性不如RAID 10。</li> </ul> </li> </ul> <hr> <h2>3. 文件系统的结构</h2> <h3>3.1 文件系统通用层次模型</h3> <p>一个典型的文件系统可以被看作是分层的结构。</p> <pre><code class="language-mermaid">graph TD A[应用程序] --> B[逻辑文件系统层]; B --> C[文件组织模块层]; C --> D[基本文件系统层]; D --> E[基本I/O控制层]; E --> F[物理磁盘]; </code></pre> <ul> <li><strong>逻辑文件系统层</strong>: 管理元数据，如目录结构、文件属性。负责权限检查（安全）。</li> <li><strong>文件组织模块层</strong>: 知道文件和它们的逻辑块是如何映射到磁盘上的物理块的。负责逻辑块号到物理块号的转换。</li> <li><strong>基本文件系统层</strong>: 负责向设备驱动程序发出具体的读/写物理块的命令。</li> <li><strong>基本I/O控制层</strong>: 设备驱动程序和中断处理程序，直接与硬件交互。</li> </ul> <h3>3.2 虚拟文件系统 (VFS - Virtual File System)</h3> <p>VFS是内核中的一个抽象层，它为用户态程序提供了一个统一的文件系统接口，从而屏蔽了底层不同类型文件系统的差异。</p> <pre><code class="language-mermaid">graph TD A["用户程序 (open, read, write)"] --> B["系统调用接口 (sys_open, sys_read)"]; subgraph "内核空间" B --> C["虚拟文件系统 (VFS)"]; C --> D["ext4 模块"]; C --> E["NTFS 模块"]; C --> F["NFS 模块"]; end </code></pre> <p>有了VFS，你的程序无需关心它操作的文件是在ext4分区、NTFS分区还是在一个网络文件系统（NFS）上，可以使用同样的方式来访问。</p> <h3>3.3 日志结构文件系统 (LFS - Log-structured File System)</h3> <ul> <li><strong>核心思想</strong>: 为了将所有随机写操作转换为顺序写，从而极大地提高写入性能，LFS将整个磁盘看作一个巨大的、只追加的日志（Log）。</li> <li><strong>工作方式</strong>: 任何修改（包括数据、i-node、目录等）都会被打包成一个段（segment），然后顺序地写入到日志的末尾。一个后台的清理线程会周期性地扫描日志，回收旧的、不再有效的空间。</li> </ul> <h3>3.4 日志文件系统 (Journaling File System)</h3> <p>这是从LFS借鉴了"日志"思想并加以简化和实用化的产物。它不把所有数据都写入日志，通常<strong>只记录元数据的变更</strong>。</p> <ul> <li> <p><strong>典型删除操作步骤</strong>:</p> <ol> <li><strong>写日志</strong>: 向日志区写入一个条目，记录"我将要：1.从目录中删除文件X；2.释放i-node Y；3.归还数据块Z到空闲池"。</li> <li><strong>提交日志</strong>: 确保日志条目已安全写入磁盘。</li> <li><strong>执行操作</strong>: 实际地去修改目录、i-node和空闲块列表。</li> <li><strong>清除日志</strong>: 操作完成后，标记日志条目为已完成（或直接擦除）。</li> </ol> <p>如果在第3步时系统崩溃，重启后只需检查日志，发现有一个未完成的事务，然后重新执行这三步操作即可，保证了文件系统的一致性。</p> </li> </ul> <hr> <h2>4. 分布式文件系统</h2> <p>分布式文件系统允许多台计算机通过网络共享文件，并且对用户来说，远程文件仿佛就在本地一样（透明性）。</p> <h3>4.1 HDFS (Hadoop Distributed File System) 概述</h3> <p>HDFS是专为在大规模廉价硬件集群上存储和处理海量数据而设计的。</p> <ul> <li><strong>HDFS架构</strong>: <ul> <li><strong>NameNode (主节点)</strong>: 负责管理文件系统的命名空间（目录树）和所有文件的元数据（文件由哪些块组成，这些块存储在哪些DataNode上）。它是系统的<strong>单点故障</strong>来源。</li> <li><strong>DataNode (从节点)</strong>: 负责存储实际的数据块，并响应来自客户端或NameNode的读写请求。</li> </ul> </li> </ul> <pre><code class="language-mermaid">graph TD Client_Read[客户端 Read] Client_Write[客户端 Write] NameNode subgraph "机架1" DN11[DataNode] DN12[DataNode] end subgraph "机架2" DN21[DataNode] DN22[DataNode] end Client_Read -- "1. 请求元数据" --> NameNode NameNode -- "2. 返回块位置" --> Client_Read Client_Read -- "3. 直接读取数据" --> DN11 Client_Read -- "3. 直接读取数据" --> DN21 Client_Write -- "1. 请求写入" --> NameNode NameNode -- "2. 分配块位置" --> Client_Write Client_Write -- "3. 写入数据管道" --> DN12 DN12 -- "4. 复制" --> DN22 DN22 -- "5. 复制" --> DN11 </code></pre> <ul> <li><strong>关键特性</strong>: <ul> <li><strong>大文件和块存储</strong>: 文件被切分成巨大的块（默认128MB或256MB），以块为单位存储和复制。这减少了元数据的规模。</li> <li><strong>一次写入，多次读取</strong>: 为流式数据访问优化，吞吐量高。支持文件追加，但不支持任意位置修改。</li> <li><strong>数据冗余和机架感知</strong>: 每个块默认有3个副本。HDFS会尽量将副本分散到不同的机架上（例如，1个在本地机架，2个在远程机架），以防止整个机架掉电或网络故障导致数据不可用。</li> <li><strong>高可用 (High Availability)</strong>: 为了解决NameNode的单点故障问题，引入了<strong>Active-Standby NameNode</strong>模式。一个Active NameNode对外服务，一个Standby NameNode作为热备份，它们通过一个共享存储（如NFS或JournalNode集群）来同步元数据。如果Active节点宕机，Standby节点可以迅速接管。</li> </ul> </li> </ul> <p>这里有两道期末考试常考的练习题, 可以参考我写的<a href="https://github.com/EmptyBlueBox/Operating_Systems-2025Spring-PKU/blob/main/Resource/%E6%80%9D%E8%80%83%E9%A2%98.md">思考题答案</a>中的解答.</p>https://www.lyt0112.com/blog/operating_systems_note_07-zhhttps://www.lyt0112.com/blog/operating_systems_note_07-zhOperating Systems Notes 07: 文件系统 1Wed, 23 Apr 2025 02:09:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gemini-2.5-pro-preview-06-05</code></p> <p>This article uses LLM to improve efficiency, which can make mistakes. I have tried my best to check and proofread, but still cannot guarantee complete accuracy.</p> <p>For personal use, may be nagging for you.</p> <h2>1. 文件系统的基本概念</h2> <h3>1.1 问题导引</h3> <p>在我们开始之前，请大家先思考几个问题，这些问题将贯穿我们整个章节的学习：</p> <ul> <li>怎样理解“文件系统是对磁盘的抽象”这句话?</li> <li>从用户角度看，文件系统的功能是什么？我们如何建立、删除、打开、关闭、读写文件？如何确定和修改文件的权限？</li> <li>从系统角度看，文件系统是如何实现的？它如何管理每个文件？如何设计并实现文件目录？如何管理磁盘空间？</li> <li>文件系统还需要考虑哪些其他需求？比如性能和安全。</li> <li>文件系统与其他操作系统功能（如I/O系统）的接口是怎样的？</li> </ul> <p>带着这些问题，我们来逐一揭开文件系统的神秘面纱。</p> <h3>1.2 文件 (File)</h3> <h4>1.2.1 什么是文件？</h4> <p><strong>“文件是对磁盘的抽象”</strong>。这是一个非常重要的概念。磁盘的物理结构是磁道、扇区，它只能通过低级的指令（如“读写第X磁道第Y扇区”）来访问，这非常不便。文件系统将这些底层细节隐藏起来，提供给我们一个更高层次、更易于理解和操作的视图。</p> <p>在逻辑上，<strong>文件</strong>是指一组带标识（标识即为文件名）的、有完整意义的信息项的序列。</p> <ul> <li><strong>信息项</strong>: 构成文件内容的基本单位，可以是一个字节，也可以是多个字节。这些信息项之间具有顺序关系。</li> <li><strong>文件内容的意义</strong>: 由创建和使用文件的用户或程序来解释。操作系统本身不关心文件内容是文本、图像还是可执行程序。</li> </ul> <p>一个文件可以看作是信息项的线性序列，通常会有一个<strong>读写指针</strong>来标识当前访问的位置。</p> <pre><code>| 信息项0 | 信息项1 | ... | 信息项i | ... | 信息项n-1 | ^ | 读写指针 </code></pre> <p>在UNIX/Linux系统中，这个抽象被推向了极致，也就是著名的**“万物皆文件” (Everything is a file)**。</p> <ul> <li>普通文件 (如 <code>my_document.txt</code>) 是文件。</li> <li>硬件设备 (如磁盘分区 <code>/dev/sda2</code>，终端 <code>/dev/tty2</code>) 也是文件。</li> <li>甚至内核的各种数据结构也通过 <code>/proc</code> 目录以文件的形式暴露出来。</li> </ul> <p>这极大地简化了应用程序与系统各种资源的交互方式，因为它们都可以使用同一套文件操作API（<code>open</code>, <code>read</code>, <code>write</code>, <code>close</code>）来访问。</p> <h4>1.2.2 文件的分类</h4> <p>根据文件的性质和用途，特别是在UNIX系统中，文件可以分为以下几类：</p> <ul> <li><strong>普通文件 (Regular File)</strong>: 包含用户的信息，内容通常是ASCII文本或二进制数据。这是我们最常见的文件类型。</li> <li><strong>目录文件 (Directory File)</strong>: 用于管理文件系统的系统文件。它的内容是该目录下包含的文件和子目录的列表。</li> <li><strong>特殊文件 (Special File)</strong>: 用于I/O。 <ul> <li><strong>字符设备文件</strong>: 用于模拟串行I/O设备，如终端、打印机。数据以字符为单位进行传输。</li> <li><strong>块设备文件</strong>: 用于模拟磁盘等块设备。数据以数据块为单位进行传输。</li> </ul> </li> <li><strong>管道文件 (Pipe)</strong>: 用于进程间通信。</li> <li><strong>套接字 (Socket)</strong>: 用于不同机器间的网络通信。</li> <li><strong>符号链接文件 (Symbolic Link)</strong>: 其内容是到另一个文件的路径。</li> </ul> <h4>1.2.3 文件的逻辑结构</h4> <p>文件的逻辑结构是指在用户看来，文件内部是如何组织的。这由用户的访问方式决定，主要有以下几种：</p> <ul> <li><strong>流式文件 (Stream File)</strong>: 文件被看作一个无结构的字节序列（如UNIX中的文件）。这是最简单、最常用的一种结构。</li> <li><strong>记录式文件 (Record File)</strong>: 文件由一组定长或变长的记录构成。</li> <li><strong>树形结构</strong>: 文件由记录的树状结构组织而成，便于按键值查找。</li> </ul> <pre><code class="language-mermaid">graph TD subgraph "文件的逻辑结构" A["字节序列 (流式文件)"] B["记录序列 (记录式文件)"] C["树形结构"] end </code></pre> <p>此外，还有一些更复杂的结构，如索引结构、索引顺序结构、散列结构等，它们通常用于数据库系统中，以优化数据检索效率。</p> <h4>1.2.4 文件的访问方式</h4> <ul> <li><strong>顺序存取 (Sequential Access)</strong>: 从文件开头按字节或记录的顺序依次读写。这是最基本的方式。</li> <li><strong>随机存取 (Random Access)</strong>: 可以从文件中的任意位置开始读写。这需要操作系统提供<code>seek</code>之类的操作来移动读写指针。</li> </ul> <h3>1.3 文件属性与文件控制块 (FCB)</h3> <p>操作系统为了管理文件，需要记录每个文件的相关信息。这些信息被称为<strong>文件属性 (File Attributes)</strong> 或 <strong>元数据 (Metadata)</strong>。它们存放在一个称为<strong>文件控制块 (File Control Block, FCB)</strong> 的数据结构中。</p> <p>一个FCB通常包含以下属性：</p> <ul> <li><strong>标识信息</strong>: 文件名，文件系统内部唯一的文件号。</li> <li><strong>类型信息</strong>: 文件类型（普通、目录、特殊等）。</li> <li><strong>物理位置信息</strong>: 文件在磁盘上的存放地址。</li> <li><strong>大小信息</strong>: 文件当前的大小。</li> <li><strong>权限保护信息</strong>: 谁可以读、写、执行该文件（创建者、拥有者、访问控制列表）。</li> <li><strong>管理信息</strong>: 创建时间、最后修改时间、最后访问时间。</li> <li><strong>其他</strong>: 共享计数、只读/隐藏/系统等标志位。</li> </ul> <h3>1.4 文件操作</h3> <p>操作系统提供了一系列系统调用来支持对文件的操作：</p> <ul> <li><code>create</code>: 创建一个新文件。</li> <li><code>delete</code>: 删除一个文件。</li> <li><code>open</code>: 打开一个已存在的文件，为后续的读写操作做准备。</li> <li><code>close</code>: 关闭一个已打开的文件，释放相关资源。</li> <li><code>read</code>: 从文件中读取数据。</li> <li><code>write</code>: 向文件中写入数据。</li> <li><code>append</code>: 在文件末尾追加数据。</li> <li><code>seek</code>: 移动文件读写指针到指定位置（用于随机存取）。</li> <li><code>get attributes</code> / <code>set attributes</code>: 获取或设置文件属性。</li> <li><code>rename</code>: 重命名文件。</li> </ul> <p>一个典型的文件访问模式是：先 <code>open</code>，然后进行若干次 <code>read</code>/<code>write</code>，最后 <code>close</code>。 <code>f = open(name, flag);</code> <code>...</code> <code>read(f, ...);</code> <code>...</code> <code>close(f);</code></p> <h3>1.5 文件目录 (Directory)</h3> <h4>1.5.1 基本概念</h4> <ul> <li><strong>文件目录 (File Directory)</strong>: 为了统一管理所有文件的FCB，我们将它们组织起来，形成的这个集合就是文件目录。所以，<strong>文件目录是文件控制块的有序集合</strong>。</li> <li><strong>目录项 (Directory Entry)</strong>: 构成文件目录的基本单元，每个目录项对应一个文件或子目录。在简单系统中，目录项就是FCB。在复杂系统中（如UNIX），目录项可能只包含文件名和指向一个更完整数据结构（如i-node）的指针。</li> <li><strong>目录文件 (Directory File)</strong>: 为了持久化存储，文件目录通常会以一种特殊文件的形式存放在磁盘上，这个文件就叫目录文件。其内容由一系列目录项组成。为保证文件系统的一致性，目录文件通常只允许内核进行修改，应用程序通过系统调用来访问。</li> </ul> <h4>1.5.2 目录结构</h4> <p>最常用的是<strong>树形目录结构 (Tree-structured Directory)</strong>。</p> <ul> <li><strong>根目录 (Root Directory)</strong>: 整个文件系统的起点。</li> <li><strong>子目录 (Subdirectory)</strong>: 允许用户将文件分组，形成层次化结构。</li> <li><strong>路径名 (Pathname)</strong>: 唯一标识一个文件或目录在树中的位置。 <ul> <li><strong>绝对路径名</strong>: 从根目录开始的路径，例如 <code>/User_B/Draw/ABC</code>。</li> <li><strong>相对路径名</strong>: 从当前目录开始的路径。</li> </ul> </li> <li><strong>当前目录 (Current/Working Directory)</strong>: 每个进程都有一个当前目录。这使得用户可以使用更短的相对路径名来访问文件。</li> </ul> <pre><code class="language-mermaid">graph TD Root(Root directory) --> A(User A) Root --> B(User B) Root --> C(User C) A --> A_file(File A) B --> B_subdir1(Dir B) B --> B_subdir2(Dir B) B_subdir1 --> B_file(File B) C --> C_subdir1(Dir C) C --> C_file1(File C) C_subdir1 --> C_subdir2(Dir C) C_subdir1 --> C_file2(File C) C_subdir2 --> C_file3(File C) C_subdir2 --> C_file4(File C) </code></pre> <h4>1.5.3 目录操作</h4> <ul> <li><code>create</code> / <code>delete</code>: 创建或删除一个目录。</li> <li><code>opendir</code> / <code>closedir</code>: 打开和关闭目录以读取其内容。</li> <li><code>readdir</code>: 读取目录中的下一个目录项。</li> <li><code>rename</code>: 重命名目录。</li> <li><code>link</code> / <code>unlink</code>: 创建或删除文件的链接（别名）。</li> </ul> <h4>1.5.4 思考题：文件名解析</h4> <p><strong>问题</strong>: 观察下图，试画出对应的树形目录结构，并给出解析文件名 <code>/User_B/Draw/ABC</code> 的步骤。 <strong>图示</strong>: (根据幻灯片 Page 25 的图)</p> <ul> <li>Master Directory (Root) <ul> <li>User_A (Dir) -> ...</li> <li>User_B (Dir) <ul> <li>Word (Dir) -> ...</li> <li>Draw (Dir) -> ABC (File)</li> </ul> </li> <li>User_C (Dir) -> ...</li> </ul> </li> </ul> <p><strong>回答</strong>:</p> <ol> <li> <p><strong>树形结构</strong>:</p> <pre><code class="language-mermaid">graph TD Root("Master Directory") --> UserA("User_A") Root --> UserB("User_B") Root --> UserC("User_C") UserB --> Word("Word") UserB --> Draw("Draw") Draw --> ABC("File ABC") </code></pre> </li> <li> <p><strong>文件名解析步骤 (/User_B/Draw/ABC)</strong>:</p> <ol> <li>从根目录（Master Directory）开始查找。</li> <li>在根目录中，查找名为 <code>User_B</code> 的目录项。找到后，获取该目录文件的位置信息。</li> <li>读取 <code>User_B</code> 目录文件的内容，在其中查找名为 <code>Draw</code> 的目录项。找到后，获取该目录文件的位置信息。</li> <li>读取 <code>Draw</code> 目录文件的内容，在其中查找名为 <code>ABC</code> 的目录项。</li> <li>找到 <code>ABC</code> 的目录项，从中获取文件的FCB信息（如物理地址、大小、权限等），解析完成。此时，文件就可以被打开和访问了。</li> </ol> </li> </ol> <h3>1.6 文件系统 (File System)</h3> <p>文件系统是操作系统中负责<strong>管理持久性数据</strong>的部分。它不仅管理文件，还负责它们底层的存储。</p> <p>其主要功能可以总结为：</p> <ul> <li><strong>实现文件的按名存取</strong>: 用户通过文件名来访问数据，而无需关心物理地址。文件系统负责完成“名字空间”到“磁盘空间”的映射。</li> <li><strong>统一管理磁盘空间</strong>: 实施磁盘空间的分配与回收，跟踪哪些块是空闲的，哪些块已被占用。</li> <li><strong>文件信息的共享与保护</strong>: 提供数据可靠性和安全保障机制，如访问控制。</li> <li><strong>提供便捷的接口</strong>: 向用户提供一套方便使用的文件和目录操作命令。</li> <li><strong>提高性能</strong>: 通过各种技术（如缓存、优化的布局策略）来提高文件系统的访问速度。</li> <li><strong>与I/O系统的统一接口</strong>: 为上层应用提供与具体设备无关的I/O操作。</li> </ul> <h2>2. 文件系统的实现</h2> <p>现在我们从系统内部视角，看看文件系统是如何被设计和实现的。</p> <h3>2.1 存储介质与物理块</h3> <ul> <li><strong>存储介质</strong>: 文件通常存储在持久性存储介质上，如磁盘（HDD）、固态硬盘（SSD）、U盘等。</li> <li><strong>抽象</strong>: 操作系统将磁盘抽象为一维的逻辑块（Block）数组，从 <code>0</code> 到 <code>n-1</code>。</li> <li><strong>数据块 (Block)</strong>: 存储设备被划分为大小相等的块，块是信息存储、传输和分配的基本单位。Windows中称为<strong>簇 (Cluster)</strong>。一个块通常由若干个连续的扇区组成。扇区是物理存储单元，而块是逻辑存储单元。</li> </ul> <p><strong>HDD vs SSD 寻址</strong>:</p> <ul> <li><strong>LBA (Logical Block Addressing)</strong>: 操作系统使用的是逻辑块地址。</li> <li><strong>PBA (Physical Block Address)</strong>: 存储设备内部的实际物理地址。</li> <li><strong>映射</strong>: <ul> <li>在HDD中，LBA到PBA的映射相对固定，由硬盘固件管理。物理地址通常由柱面号、磁头号、扇区号组成。</li> <li>在SSD中，由于闪存的写入限制（磨损均衡），LBA到PBA的映射是动态的，由FTL（Flash Translation Layer）管理。</li> </ul> </li> </ul> <p>一次典型的HDD访盘请求包括三个主要时间开销：</p> <ol> <li><strong>寻道时间</strong>: 移动磁臂到指定磁道。</li> <li><strong>旋转延迟时间</strong>: 等待目标扇区旋转到磁头下方。</li> <li><strong>数据传输时间</strong>: 实际读写数据的时间。</li> </ol> <h3>2.2 文件系统布局</h3> <p>在实现文件系统时，首先要考虑的是它在磁盘上和内存中的内容布局。</p> <h4>2.2.1 相关术语</h4> <ul> <li><strong>磁盘分区 (Partition)</strong>: 把一个物理磁盘的存储空间划分为几个相互独立的部分。</li> <li><strong>文件卷 (Volume)</strong>: 一个逻辑分区，可以是一个分区，也可以跨越多个磁盘（如RAID）。同一个文件卷使用同一份管理数据（元数据）来进行文件分配和空间管理。</li> <li><strong>格式化 (Format)</strong>: 在一个文件卷上建立文件系统的过程。这包括创建和初始化用于文件分配和磁盘空间管理的元数据。</li> </ul> <h4>2.2.2 磁盘上的内容</h4> <p>一个格式化好的文件卷通常包含以下几个部分：</p> <ol> <li><strong>引导区 (Boot Block / Boot Sector)</strong>: 包含从该卷引导操作系统所需的信息。通常是分区的第一个扇区。</li> <li><strong>卷管理信息 (Superblock)</strong>: 描述整个文件卷的信息，如块大小、块总数、空闲块数量、i-node数量等。这是文件系统的“元数据中的元数据”。</li> <li><strong>空闲空间管理区</strong>: 用于记录哪些磁盘块是空闲的数据结构（如位图或空闲块链表）。</li> <li><strong>文件元数据区</strong>: 存放文件控制块（如UNIX中的i-node区）的区域。</li> <li><strong>数据区</strong>: 存放实际的用户文件和目录文件内容的区域。</li> </ol> <p><strong>UNIX文件系统布局 (分区内)</strong>:</p> <pre><code>| 引导记录 | 超级块 | 空闲区管理 | i-node区 | 根目录及数据区 | </code></pre> <p><strong>FAT文件系统布局</strong>:</p> <pre><code>| 引导区 | 文件分配表1 (FAT1) | 文件分配表2 (FAT2) | 根目录 | 其他目录和文件 | </code></pre> <h3>2.3 文件的物理结构</h3> <p>这是文件系统实现的核心之一，决定了文件在物理介质上的存放方式。</p> <h4>2.3.1 连续结构 (Contiguous Allocation)</h4> <p>文件的信息存放在若干<strong>连续</strong>的物理块中。</p> <ul> <li><strong>FCB中如何记录?</strong> 只需记录起始块号和文件长度（总块数）。</li> <li><strong>优点</strong>: <ul> <li>实现简单，读写效率高，因为磁头移动最少。</li> <li>支持顺序存取和随机存取。</li> </ul> </li> <li><strong>缺点</strong>: <ul> <li><strong>文件不能动态增长</strong>: 如果创建时分配的空间不够，后续增长会很困难。</li> <li><strong>外部碎片问题</strong>: 随着文件的创建和删除，磁盘空间会产生很多不连续的小空闲区，无法存放大文件。需要定期进行“磁盘碎片整理”来解决。</li> <li>不利于文件内容的插入和删除。</li> </ul> </li> </ul> <h4>2.3.2 链接结构 (Linked Allocation)</h4> <p>文件的信息存放在若干<strong>不连续</strong>的物理块中，各块之间通过指针连接。每个块中都包含指向下一个块的指针。</p> <ul> <li><strong>FCB中如何记录?</strong> 只需记录起始块号。</li> <li><strong>优点</strong>: <ul> <li>有效利用磁盘空间，没有外部碎片问题。</li> <li>文件可以动态增长。</li> <li>有利于文件内容的插入删除。</li> </ul> </li> <li><strong>缺点</strong>: <ul> <li><strong>不支持高效的随机存取</strong>: 要访问第 N 块，必须从头开始沿着指针链顺序访问前 N-1 块。</li> <li><strong>可靠性问题</strong>: 指针丢失或损坏会导致文件数据丢失。</li> <li><strong>指针占用空间</strong>: 每个块都需要一部分空间来存储指针。</li> <li>寻道次数多，存取速度慢。</li> </ul> </li> </ul> <p><strong>变形：文件分配表 (File Allocation Table, FAT)</strong> 为了解决链接结构的缺点，FAT文件系统将所有块的链接指针集中存放在磁盘开头的一个特殊区域——<strong>文件分配表 (FAT)</strong> 中。FAT本身是一个大数组，数组的下标对应磁盘块号，数组元素的值表示下一个块的块号。</p> <ul> <li><strong>FCB/目录项中如何记录?</strong> 仍然是记录起始块号。</li> <li><strong>优点</strong>: 整个FAT可以被读入内存，使得随机访问变得高效。要找第 N 块，只需在内存的FAT数组中查找 N 次即可，无需访问磁盘数据区。</li> </ul> <h4>2.3.3 索引结构 (Indexed Allocation)</h4> <p>为每个文件建立一个专用的<strong>索引表 (Index Block)</strong>，这个表中存放了文件所有数据块的块号。索引表本身也需要一个磁盘块来存储。</p> <ul> <li><strong>FCB中如何记录?</strong> 记录该文件的索引表的地址。</li> <li><strong>优点</strong>: <ul> <li>保留了链接结构的优点（无外部碎片，动态增长）。</li> <li><strong>支持高效的随机存取</strong>: 要访问第 N 块，只需先读入索引表，然后在索引表中直接找到第 N 项，就能得到目标块的地址。</li> </ul> </li> <li><strong>缺点</strong>: <ul> <li>索引表本身带来了系统开销（占用磁盘空间和内存）。</li> <li>对于小文件，索引表的开销可能显得过大。</li> </ul> </li> </ul> <p><strong>问题：索引表很大，一个块放不下怎么办？</strong></p> <ol> <li><strong>链接方式</strong>: 将多个索引表块链接起来。</li> <li><strong>多级索引</strong>: 用一个顶级索引表来索引次级索引表，形成层次结构。</li> <li><strong>综合模式</strong>: 将直接地址和间接（多级）索引结合起来。</li> </ol> <p><strong>UNIX 多级索引结构 (综合模式)</strong> UNIX的i-node中通常包含一个包含15个地址项的数组：</p> <ul> <li><strong>前12项 (直接寻址)</strong>: 直接指向文件的前12个数据块。</li> <li><strong>第13项 (一级间接)</strong>: 指向一个索引块，该索引块里存放了更多数据块的地址。</li> <li><strong>第14项 (二级间接)</strong>: 指向一个二级索引块，该块中的每一项都指向一个一级索引块。</li> <li><strong>第15项 (三级间接)</strong>: 指向一个三级索引块。</li> </ul> <pre><code class="language-mermaid">graph TD Inode["i-node"] --> D1(Direct Block 1) Inode --> D2(Direct Block 2) Inode --> D_etc(...) Inode --> D12(Direct Block 12) Inode -- "Single Indirect" --> S_Indirect(一级索引块) S_Indirect --> DataBlock1 S_Indirect --> DataBlock2 S_Indirect --> DataBlock_etc(...) Inode -- "Double Indirect" --> D_Indirect(二级索引块) D_Indirect --> S_Indirect_1(一级索引块) D_Indirect --> S_Indirect_2(一级索引块) S_Indirect_1 --> DataBlock_A S_Indirect_2 --> DataBlock_B Inode -- "Triple Indirect" --> T_Indirect(三级索引块) T_Indirect --> D_Indirect_A(二级索引块) T_Indirect --> D_Indirect_B(二级索引块) </code></pre> <p><strong>思考题</strong>: UNIX中采用了三级索引结构后, 文件最大可达到多少个物理块? 假设扇区大小为512字节, 物理块等于扇区块大小, 一级索引表可以存放256个物理块号(一个块号占2字节)。 <strong>回答</strong>:</p> <ul> <li>直接块: 12 块</li> <li>一级间接: 256 块</li> <li>二级间接: $256 \times 256 = 65,536$ 块</li> <li>三级间接: $256 \times 256 \times 256 = 16,777,216$ 块</li> <li><strong>总计</strong>: $12 + 256 + 65,536 + 16,777,216 = 16,843,020$ 个物理块。</li> <li><strong>最大文件大小</strong>: $16,843,020 \times 512$ 字节 $\approx$ 8 GB。</li> </ul> <h3>2.4 目录文件的实现</h3> <h4>2.4.1 目录项组织方式</h4> <ul> <li><strong>顺序表</strong>: 最简单的方式，将目录项一个接一个地存放。查找文件时需要线性扫描，效率低。</li> <li><strong>散列表 (Hash Table)</strong>: 根据文件名计算散列值，快速定位到目录项。解决了查找速度问题，但需要处理冲突。</li> <li><strong>B+树</strong>: 很多现代文件系统（如NTFS）使用B+树来组织目录项。B+树是一种平衡树，能保证目录的增、删、查操作都有稳定且高效的性能。</li> </ul> <h4>2.4.2 目录检索的加速</h4> <p><strong>问题</strong>: 如何加快目录检索？一个很大的目录文件，如果线性查找所有FCB会很慢。</p> <p><strong>解决方案：目录项分解法 (UNIX i-node)</strong> 将FCB拆分为两部分：</p> <ol> <li><strong>目录项</strong>: 只包含<strong>文件名</strong>和指向文件元数据的<strong>文件号 (i-node number)</strong>。</li> <li><strong>i-node (索引节点)</strong>: 包含文件名之外的所有其他元数据（权限、大小、物理地址等）。</li> </ol> <p>所有i-node集中存放在磁盘的<strong>i-node区</strong>。目录文件变得更小，因为每个条目只占几个字节。</p> <p><strong>思考题</strong>: 假设一个FCB有48字节，物理块大小512字节。一个目录文件有128个目录项。分解前，符号目录项占8字节（文件名6B，文件号2B），基本目录项占42字节。计算查找一个文件的平均访盘次数。 <strong>回答</strong>:</p> <ul> <li><strong>分解前</strong>: <ul> <li>一个块能放 $\frac{512}{48} \approx 10$ 个FCB。</li> <li>128个目录项需要 $\frac{128}{10} \approx 13$ 个块。</li> <li>假设目录文件是连续存放的，平均查找的期望为，$\sum_{i=1}^{13} \frac{i}{13} = \frac{13 \times (13 + 1)}{2 \times 13} = 7$ 次访盘。</li> </ul> </li> <li><strong>分解后</strong>: <ul> <li>目录文件只存符号目录项。一个块能放 $\frac{512}{8} = 64$ 个符号目录项。</li> <li>128个目录项需要 $\frac{128}{64} = 2$ 个块。</li> <li>i-node区存放基本目录项。一个块能放 $\frac{512}{42} \approx 12$ 个i-node。</li> <li>128个i-node需要 $\frac{128}{12} \approx 11$ 个块。</li> <li>查找过程： <ol> <li>读目录文件，找到文件名对应的i-node号。平均需要 $\frac{1}{2}+\frac{2}{2}=1.5$ 次访盘。</li> <li>根据i-node号去i-node区读取i-node信息。需要1次访盘。</li> </ol> </li> <li>总平均访盘次数：$1.5 + 1 = 2.5$ 次。</li> </ul> </li> <li><strong>结论</strong>: 改进后，通过先在小型的目录文件中快速定位，再精确访问i-node，显著减少了磁盘访问次数，提高了检索速度。</li> </ul> <h3>2.5 磁盘空间管理</h3> <p>文件系统需要跟踪所有空闲的磁盘块。</p> <ul> <li><strong>位图法 (Bitmap)</strong>: 用一个二进制位串来表示所有磁盘块。<code>1</code>代表空闲，<code>0</code>代表已分配（或反之）。 <ul> <li>优点: 简单直观，很容易找到连续的空闲块。</li> <li>缺点: 对于大磁盘，位图本身可能很大。</li> <li><strong>计算公式</strong>: <ul> <li>已知块号<code>b</code>，字长<code>w</code>：位图中的字号 $i = b / w$，位号 $j = b \pmod w$。</li> </ul> </li> </ul> </li> <li><strong>空闲块链表</strong>: 把所有空闲块用指针链接起来。 <ul> <li>优点: 实现简单。</li> <li>缺点: 申请/归还多个块时效率低，因为要多次读写链表。</li> </ul> </li> <li><strong>成组链接法 (UNIX)</strong>: 空闲链表的改进版。将空闲块分组，每组的第一个块记录了该组其他块的块号以及下一组的地址。 <ul> <li>分配时，从当前组取出一个块。如果当前组用完，则从下一组中读入新的空闲块信息。</li> <li>回收时，将块加入当前组。如果当前组满了，就将当前组的信息写入回收的块中，使其成为新的“信息块”，并链接到空闲链表的头部。</li> <li>这种方法在分配和回收大量块时效率很高。</li> </ul> </li> </ul> <h3>2.6 内存中的数据结构 (UNIX)</h3> <p>为了提高效率，操作系统会在内存中维护一些与文件系统相关的数据结构。</p> <ol> <li><strong>系统级打开文件表 (System-wide Open File Table)</strong>: <ul> <li>整个系统只有一张。</li> <li>当任何进程第一次打开一个文件时，该文件的i-node被从磁盘读入内存，并在此表中创建一个条目。</li> <li>条目内容包括i-node的拷贝、引用计数（记录有多少个进程打开了此文件）等。</li> </ul> </li> <li><strong>进程级打开文件表 (Per-process Open File Table)</strong>: <ul> <li>每个进程都有一张。</li> <li>当进程打开一个文件时，会在自己的这张表中创建一个条目。这个条目被称为<strong>文件描述符 (File Descriptor)</strong>。</li> <li>条目内容包括打开方式（读/写）、当前的读写指针（<strong>重要：读写指针是每个打开实例私有的</strong>）、以及一个指向系统级打开文件表对应条目的指针。</li> </ul> </li> </ol> <p><strong>文件共享与fork</strong>:</p> <ul> <li>当一个进程<code>fork</code>一个子进程时，子进程会继承父进程的打开文件表。</li> <li>父子进程的文件描述符将指向<strong>同一个</strong>系统级打开文件表条目。</li> <li>这意味着它们共享同一个读写指针。如果一个进程移动了指针，另一个进程也会看到变化。</li> </ul> <p><strong>I/O重定向 (<code>dup2</code>)</strong>:</p> <ul> <li><code>dup2(oldfd, newfd)</code>系统调用可以使<code>newfd</code>指向<code>oldfd</code>所指向的同一个系统级文件表条目。</li> <li>这使得我们可以将标准输出（<code>fd=1</code>）重定向到一个文件，从而实现命令输出到文件的功能。</li> </ul> <pre><code class="language-mermaid">graph TD direction LR subgraph "进程A" A_Tbl["描述符表"] A_Tbl -- "fd 0 (stdin)" --> OF_Term A_Tbl -- "fd 1 (stdout)" --> OF_Term A_Tbl -- "fd 4" --> OF_FileB end subgraph "内核" OF_Term["系统打开文件表项 (终端) \n pos, refcnt=2"] OF_FileB["系统打开文件表项 (文件B) \n pos, refcnt=1"] OF_Term --> V_Term["v-node表项 (终端信息)"] OF_FileB --> V_FileB["v-node表项 (文件B信息)"] end </code></pre> <h3>2.7 文件操作的实现</h3> <ul> <li><strong><code>create(文件名, ...)</code></strong>: <ol> <li>在目录中查找，确保没有重名文件。</li> <li>申请一个新的i-node。</li> <li>在目录文件中增加一个新条目（文件名, i-node号）。</li> </ol> </li> <li><strong><code>open(文件名, ...)</code></strong>: <ol> <li>解析路径名，找到文件的i-node号。</li> <li>检查系统打开文件表，看文件是否已被其他进程打开。 <ul> <li>是：引用计数加1。</li> <li>否：从磁盘读入i-node到系统打开文件表的新条目中，引用计数置为1。</li> </ul> </li> <li>在当前进程的打开文件表中创建一个新条目（文件描述符）。</li> <li>将该文件描述符指向系统打开文件表的对应条目。</li> <li>返回文件描述符给用户。</li> </ol> </li> <li><strong><code>read(fd, ...)</code></strong>: <ol> <li>通过<code>fd</code>在进程和系统打开文件表中找到文件的i-node。</li> <li>根据文件描述符中的读写指针和i-node中的物理地址信息，计算出要读取的物理块号。</li> <li>启动磁盘I/O操作，将数据从磁盘读入内核缓冲区，再从内核缓冲区复制到用户指定的内存地址。</li> <li>更新读写指针。</li> </ol> </li> <li><strong><code>seek(fd, ...)</code></strong>: <ol> <li>通过<code>fd</code>找到进程打开文件表中的条目。</li> <li>修改其中的读写指针值。</li> </ol> </li> </ul> <h3>2.8 文件共享</h3> <ul> <li><strong>硬链接 (Hard Link)</strong>: <ul> <li>多个目录项（可以在不同目录，有不同文件名）指向<strong>同一个i-node</strong>。</li> <li>i-node中有一个<strong>链接计数 (link count)</strong>，记录有多少个目录项指向它。</li> <li>创建链接时，计数加1。</li> <li>删除文件（即删除一个目录项）时，计数减1。</li> <li>只有当链接计数减为0时，操作系统才会真正删除i-node并回收数据块。</li> <li>所有硬链接是平等的，没有主次之分。</li> </ul> </li> <li><strong>软链接/符号链接 (Soft/Symbolic Link)</strong>: <ul> <li>创建一个特殊类型的文件，其内容是<strong>另一个文件的路径名</strong>。</li> <li>访问软链接时，系统会读取其内容（路径名），然后去访问真正的文件。</li> <li>优点: 可以跨文件系统、可以链接到目录。</li> <li>缺点: 如果原文件被删除，软链接会失效（悬空指针）；解析需要额外的开销。</li> </ul> </li> </ul> <h2>3. 文件系统实例</h2> <h3>3.1 UNIX 文件系统</h3> <ul> <li><strong>核心</strong>: i-node。</li> <li><strong>结构</strong>: 目录项（文件名+i-node号）和i-node（元数据）分离。</li> <li><strong>查找示例 <code>/usr/ast/mbox</code></strong>: <ol> <li>内核从根目录（i-node号已知，通常是2）开始。</li> <li>读取根目录的数据块，查找名为 <code>usr</code> 的条目，得到其i-node号（例如 7）。</li> <li>读取i-node 7，找到 <code>usr</code> 目录的数据块地址。</li> <li>读取 <code>usr</code> 目录的数据块，查找名为 <code>ast</code> 的条目，得到其i-node号（例如 62）。</li> <li>读取i-node 62，找到 <code>ast</code> 目录的数据块地址。</li> <li>读取 <code>ast</code> 目录的数据块，查找名为 <code>mbox</code> 的条目，得到其i-node号（例如 80）。</li> <li>现在内核有了 <code>mbox</code> 文件的i-node 80，就可以进行读写等操作了。</li> </ol> </li> </ul> <h3>3.2 FAT (File Allocation Table) 文件系统</h3> <ul> <li><strong>核心</strong>: 文件分配表 (FAT)。</li> <li><strong>磁盘布局</strong>: <ul> <li><strong>DBR (DOS Boot Record)</strong>: 引导扇区，包含BPB（BIOS参数块），描述了文件系统的各种参数（每扇区字节数、每簇扇区数等）。</li> <li><strong>FAT表</strong>: 紧跟在DBR之后。通常有两份作为备份。它是一个大数组，记录了簇（块）的链接关系和状态（未使用、坏簇、文件结束标志等）。</li> <li><strong>根目录区</strong>: 在FAT12/16中，根目录大小和位置是固定的。在FAT32中，根目录是可扩展的，像普通文件一样存储。</li> <li><strong>数据区</strong>: 存放文件和子目录。</li> </ul> </li> <li><strong>目录项</strong>: <ul> <li>32字节定长结构。</li> <li>包含文件名（8.3格式）、属性、创建/修改时间、文件大小和<strong>起始簇号</strong>。</li> </ul> </li> <li><strong>文件读取</strong>: <ol> <li><strong>定位目录项</strong>: <ul> <li>如果文件在根目录，直接在根目录区中查找对应的目录项。</li> <li>如果文件在子目录中，需要先通过路径逐级查找：从根目录开始，找到第一级子目录的目录项，获取其起始簇号；读取该子目录的数据簇，在其中查找下一级目录或文件的目录项；重复此过程直到找到目标文件的目录项。</li> </ul> </li> <li><strong>获取起始簇号</strong>: 从目录项中获取文件的起始簇号。目录项是32字节的定长结构，其中第26-27字节（低16位）和第20-21字节（高16位，仅FAT32）存储了文件的起始簇号。对于FAT12/16，只使用低16位；对于FAT32，需要组合高低16位得到完整的32位簇号。</li> <li>以该簇号为索引，在内存中的FAT表副本中查找，得到下一簇的簇号。</li> <li>重复此过程，直到遇到文件结束标志。</li> </ol> </li> <li><strong>长文件名 (FAT32)</strong>: <ul> <li>采用了一种巧妙的兼容方案。对于长文件名，会创建多个特殊的<strong>长文件名目录项 (LFN entry)</strong>。</li> <li>每个LFN项存储长文件名的一部分（Unicode编码）。</li> <li>这些LFN项紧挨在真正的8.3格式短文件名目录项之前。</li> <li>不识别长文件名的旧系统会忽略这些LFEN项（因为它们的属性被设为卷标、系统、隐藏、只读的组合，旧系统不认识），只看到短文件名项。</li> </ul> </li> </ul> <h3>3.3 NTFS (New Technology File System)</h3> <p>Windows NT/XP及之后版本使用的文件系统。</p> <ul> <li><strong>设计目标</strong>: 可靠性、高效性、安全性。</li> <li><strong>核心</strong>: <strong>主控文件表 (Master File Table, MFT)</strong>。</li> <li><strong>MFT</strong>: MFT本身也是一个文件。它是一个由<strong>文件记录 (File Record)</strong> 组成的数组。卷上的每一个文件或目录都至少对应MFT中的一个记录。</li> <li><strong>万物皆属性</strong>: 在NTFS中，所有数据都被看作是文件的<strong>属性 (Attribute)</strong>。我们通常所说的文件内容，只是一个未命名的“数据属性流”。文件名、时间戳、权限等都是属性。</li> <li><strong>文件记录</strong>: <ul> <li><strong>常驻属性 (Resident Attribute)</strong>: 对于小文件或小属性，其内容直接存储在MFT记录中。</li> <li><strong>非常驻属性 (Non-resident Attribute)</strong>: 对于大文件或大属性，其内容存储在MFT之外的数据区。MFT记录中只存放指向这些数据块的指针，称为<strong>run</strong>或<strong>extent</strong>。</li> </ul> </li> <li><strong>目录</strong>: 目录也是一个文件，其“数据属性”是一个文件名索引。为了提高效率，这个索引通常用<strong>B+树</strong>来组织。</li> <li><strong>可靠性</strong>: 通过<strong>日志记录 (Logging)</strong> 实现。对文件系统的所有修改操作，在实际写入磁盘前，会先在日志文件（<code>$LogFile</code>）中记录。如果系统崩溃，重启后可以通过重做或撤销日志中的事务来恢复文件系统的一致性。</li> <li><strong>元数据文件</strong>: MFT的前16个记录被保留给系统元数据文件使用，如<code>$Mft</code>(MFT自身)、<code>$MftMirr</code>(MFT镜像)、<code>$LogFile</code>(日志文件)、<code>$Volume</code>(卷信息)、<code>$.</code>(根目录)等。</li> </ul> <h2>4. 其他文件系统和技术</h2> <ul> <li><strong>ext4</strong>: Linux默认的文件系统，是ext3的改进。使用<strong>extents</strong>（连续块区段）代替传统的块映射，减少大文件碎片；支持<strong>延迟分配</strong>，优化写入性能。</li> <li><strong>VFS (Virtual File System)</strong>: 一个内核抽象层，为用户程序提供统一的文件系统接口（如<code>open</code>, <code>read</code>）。VFS可以将这些通用请求转换为底层具体文件系统（如ext4, FAT, NTFS）的特定操作。这使得Linux可以同时支持多种不同的文件系统。</li> <li><strong>NFS (Network File System)</strong>: 一种分布式文件系统协议，允许客户端计算机像访问本地文件一样通过网络访问远程服务器上的文件。</li> </ul>https://www.lyt0112.com/blog/operating_systems_note_06-zhhttps://www.lyt0112.com/blog/operating_systems_note_06-zhOperating Systems Notes 06: 虚拟内存技术Fri, 11 Apr 2025 01:36:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gemini-2.5-pro-preview-03-25</code></p> <p>This article uses LLM to improve efficiency, which can make mistakes. I have tried my best to check and proofread, but still cannot guarantee complete accuracy.</p> <p>For personal use, may be nagging for you.</p> <h2>1. 虚拟内存基础概念</h2> <h3>1.1 虚拟地址空间 (Virtual Address Space)</h3> <ul> <li> <p><strong>定义:</strong> 操作系统为每个进程提供的、看起来连续的、私有的内存空间。它是对物理内存和磁盘空间的抽象。</p> </li> <li> <p><strong>作用:</strong></p> <ul> <li>隔离进程，提供保护。</li> <li>简化内存管理，允许程序使用比物理内存更大的地址空间。</li> <li>实现内存共享。</li> </ul> </li> <li> <p><strong>提问：CPU取到的地址是什么地址？物理地址还是虚拟地址？</strong></p> <ul> <li><strong>解答:</strong> CPU发出的地址通常是 <strong>虚拟地址</strong> (Virtual Address)。这个虚拟地址随后会被 <strong>内存管理单元 (MMU)</strong> 转换为物理地址 (Physical Address)。</li> </ul> <pre><code class="language-mermaid">graph LR CPU -- Virtual Address --> MMU; MMU -- Physical Address --> PhysicalMemory[物理内存]; MMU -- Page Fault --> OS[操作系统]; OS -- Data from Disk --> PhysicalMemory; PhysicalMemory &#x3C;--> Disk[磁盘]; </code></pre> </li> </ul> <h3>1.2 虚拟内存管理的目标</h3> <ol> <li><strong>透明性 (Transparency):</strong> 运行的程序不应感知到虚拟内存机制的存在。程序员可以像操作一个巨大的连续内存一样编程。</li> <li><strong>效率 (Efficiency):</strong> 地址转换和页面调度应尽可能快，减少性能开销。需要 <strong>硬件支持</strong> (如MMU, TLB)。</li> <li><strong>保护 (Protection):</strong> 确保进程之间、进程与操作系统之间相互隔离，互不干扰。</li> </ol> <h3>1.3 存储体系 (Memory Hierarchy)</h3> <ul> <li><strong>结构:</strong> 寄存器 -> Cache -> 内存 (RAM) -> 磁盘 (Disk)</li> <li><strong>操作系统角色:</strong> 协调各级存储器的使用。</li> <li><strong>目标:</strong> 结合速度快但容量小的存储 (如Cache, RAM) 和速度慢但容量大的存储 (如磁盘) ，为用户提供一个既“快”又“大”的逻辑内存 (虚存) 。</li> </ul> <h3>1.4 相关术语辨识</h3> <ul> <li><strong>虚拟内存 (Virtual Memory):</strong> <ul> <li><strong>解释:</strong> 将物理内存与磁盘结合使用，为程序提供一个容量远大于物理内存的逻辑存储空间。</li> <li><strong>关键:</strong> 程序引用的地址 (虚拟地址) 与物理内存地址不同，由系统自动转换。虚存大小受限于计算机寻址能力和可用磁盘空间。</li> </ul> </li> <li><strong>虚拟地址空间 (Virtual Address Space):</strong> <ul> <li><strong>解释:</strong> 分配给一个进程的逻辑地址范围。</li> </ul> </li> <li><strong>虚拟地址 (Virtual Address):</strong> <ul> <li><strong>解释:</strong> 虚拟地址空间中的某个地址。进程通过虚拟地址访问数据，仿佛它就在内存中。</li> </ul> </li> <li><strong>虚拟存储技术 (Virtual Memory Technology):</strong> <ul> <li><strong>解释:</strong> 一种内存管理技术。程序运行时，只将其一部分装入内存，其余部分留在磁盘。当需要访问不在内存中的部分时，操作系统自动将其从磁盘调入内存。</li> </ul> </li> </ul> <hr> <h2>2. 虚拟页式存储管理 (Paged Virtual Memory)</h2> <h3>2.1 基本思想</h3> <ul> <li><strong>按需加载:</strong> 装载程序时，只装入部分 (甚至零个) 页面到物理内存。</li> <li><strong>动态调页:</strong> 当进程执行需要访问不在内存中的页面时，产生 <strong>页错误 (Page Fault)</strong>，操作系统负责将所需页面从磁盘动态调入内存。</li> <li><strong>页面换出:</strong> 当内存不足时，将内存中暂时不用的页面交换 (写回) 到磁盘，以腾出空间。</li> <li><strong>实现方式:</strong> <ul> <li><strong>请求调页 (Demand Paging):</strong> 只有当页面被访问时才调入。 (最常用)</li> <li><strong>预先调页 (Prepaging):</strong> 预测进程可能需要的页面并提前调入。</li> </ul> </li> <li><strong>本质:</strong> 资源转换技术，用CPU时间和磁盘空间换取 (看似无限的) 物理内存空间。</li> </ul> <h3>2.2 核心策略 (Coffman &#x26; Denning)</h3> <ol> <li><strong>取页策略 (Fetch Policy):</strong> 决定何时将页面从磁盘调入内存。 <ul> <li><strong>请求调页:</strong> 发生缺页时才调入。</li> <li><strong>预调页:</strong> 预测并提前调入。</li> </ul> </li> <li><strong>放置策略 (Placement Policy):</strong> 决定将调入的页面放置在物理内存的哪个 <strong>页框 (Page Frame)</strong> 中。 <ul> <li><strong>解释:</strong> 在分页系统中，任何空闲页框都可以存放任何页面，所以此策略相对简单。</li> </ul> </li> <li><strong>置换策略 (Replacement Policy):</strong> 当内存没有空闲页框时，决定选择哪个页框中的页面换出到磁盘。</li> </ol> <h3>2.3 设计与实现问题</h3> <ul> <li>页表表项 (PTE) 的设计。</li> <li>如何处理页表过大的问题 (如多级页表) 。</li> <li>地址重定位与快表 (TLB)。</li> <li>缺页异常 (Page Fault) 的处理机制。</li> <li>驻留集 (Resident Set) 管理。</li> <li>置换策略 (Replacement Algorithms)。</li> <li>清除策略 (Cleaning Policy)。</li> <li>加载控制 (Load Control)。</li> </ul> <hr> <h2>3. 硬件支持与核心机制</h2> <h3>3.1 页表表项 (Page Table Entry - PTE) 设计</h3> <ul> <li><strong>关键字段:</strong> <ul> <li><strong>页框号 (Page Frame Number - PFN):</strong> 该虚拟页对应的物理内存块号。</li> <li><strong>有效位/驻留位 (Valid/Present Bit - P):</strong> 标记该页是否在物理内存中 (1=在内存, 0=不在内存/在磁盘)。</li> <li><strong>访问位/引用位 (Accessed/Referenced Bit - A/R):</strong> 标记该页近期是否被访问过 (硬件在访问时设置，OS定期清零)。用于置换算法。</li> <li><strong>修改位/脏位 (Dirty/Modified Bit - D/M):</strong> 标记该页在内存中是否被修改过 (硬件在写入时设置)。如果为1，换出时必须写回磁盘。</li> <li><strong>保护位 (Protection Bits - R/W/X):</strong> 控制对该页的访问权限 (读/写/执行) 。</li> </ul> </li> <li><strong>i386 PDE/PTE 示例:</strong> (展示了具体位域) <ul> <li><code>P</code> (Present), <code>A</code> (Accessed), <code>D</code> (Dirty), <code>R/W</code> (Read/Write), <code>U/S</code> (User/Supervisor), <code>PWT</code> (Page Write Through), <code>PCD</code> (Page Cache Disable), <code>PS</code> (Page Size - for large pages).</li> </ul> </li> </ul> <h3>3.2 处理页表过大的问题</h3> <ul> <li><strong>问题:</strong> <ul> <li>32位地址空间 (4KB页面, 4B PTE): 页表本身占用内存 <code>2^20 个 PTE * 4B = 4MB = 2^22 = 1024 个 4KB 页面</code> 的空间。</li> <li>若用户拥有 <code>2G = 2^31 = 2^19 个 4KB 页面</code> 的物理空间，索引这块内存的**有效 (有效位 P=1)**的页表就占 512 页 (<code>2^19 * 4B / 4KB = 512</code>)。</li> <li>64位地址空间: 页表大小会变得极其巨大 (理论上 <code>2^52 * 8B</code>，不可行)。</li> </ul> </li> <li><strong>解决方案:</strong> <ol> <li><strong>多级页表 (Multi-Level Page Tables):</strong> <ul> <li><strong>思想:</strong> 将巨大的线性页表变成树形结构。外层页表 (页目录) 的条目指向内层页表。只有被用到的内层页表才需要分配内存。</li> <li><strong>二级页表示例:</strong> 虚拟地址分为 <code>页目录偏移 | 页表偏移 | 页内偏移</code>。CR3寄存器指向页目录基址 -> 查页目录得页表基址 -> 查页表得页框号 -> 拼接页内偏移得物理地址。</li> <li><strong>Core i7 示例 (四级页表):</strong> 48位虚拟地址，分为 <code>9 | 9 | 9 | 9 | 12</code> 位，对应四级页表的索引和页内偏移。</li> <li><strong>优点:</strong> 节省空间，只有实际使用的页表部分才需载入内存。虽然理论上总页表项数量不变，但实际上大多数进程只使用地址空间的一小部分。</li> <li><strong>空间节省示例:</strong> <ul> <li>在32位系统中 (4GB地址空间) ，使用4KB页面，线性页表需要1M个页表项 (32位虚拟地址空间都需要对应的页表项) 。</li> <li>假设一个进程只使用了4MB的连续内存 (位于0x80000000-0x80400000) ，在二级页表中： <ul> <li>需要1个完整的页目录 (1024项，4KB)</li> <li>只需要1个二级页表 (1024项，4KB，对应使用的4MB区域)</li> <li>其余1023个二级页表 (对应未使用的地址空间) 根本不需要创建</li> </ul> </li> <li>总计只需8KB内存，而不是线性页表的4MB，节省了约99.8%的空间</li> </ul> </li> <li><strong>缺点:</strong> 每次地址翻译需要多次内存访问 (可通过TLB缓解) 。</li> </ul> </li> <li><strong>反转页表 (Inverted Page Table):</strong> <ul> <li><strong>思想:</strong> 不再为每个进程维护一个页表，而是为整个物理内存建立一个全局页表。页表项 <code>i</code> 对应物理页框 <code>i</code>。</li> <li><strong>内容:</strong> 每个页表项记录 <code>(进程ID, 虚拟页号)</code>，表示哪个进程的哪个虚拟页映射到了这个物理页框。</li> <li><strong>地址转换:</strong> 给定 <code>(进程ID, 虚拟页号)</code>，需要搜索整个反转页表找到匹配项，得到其索引 (即物理页框号) 。</li> <li><strong>优化:</strong> 使用哈希表 (Hash Table) 加速查找。将 <code>(进程ID, 虚拟页号)</code> 哈希到一个索引，指向反转页表中的一个桶 (可能需要链表解决冲突) 。</li> <li><strong>优点:</strong> 页表大小与物理内存大小成正比，与虚拟地址空间大小和进程数量无关。</li> <li><strong>缺点:</strong> 查找可能较慢 (即使有哈希) ，实现共享比较困难。</li> <li><strong>应用:</strong> PowerPC, UltraSPARC, IA-64 等。</li> </ul> </li> </ol> </li> </ul> <h3>3.3 内存管理单元 (MMU)</h3> <ul> <li><strong>定义:</strong> CPU中的硬件单元，负责将虚拟地址转换为物理地址。</li> <li><strong>过程:</strong> 接收CPU发出的虚拟地址，查询页表 (优先查TLB) ，生成物理地址或触发缺页异常。</li> </ul> <h3>3.4 地址转换 (Address Translation)</h3> <ul> <li><strong>硬件机制:</strong> <ol> <li>CPU发出虚拟地址。</li> <li>MMU 从虚拟地址中提取 <strong>虚拟页号 (VPN)</strong> 和 <strong>页内偏移 (Offset)</strong>。</li> <li>MMU 使用 VPN (可能结合多级页表结构) 查找页表 (先查TLB) 。</li> <li><strong>检查 PTE:</strong> <ul> <li><strong>Case 1: PTE 有效 (Valid/Present bit = 1) 且权限允许:</strong> <ul> <li>从 PTE 中获取 <strong>页框号 (PFN)</strong>。</li> <li>将 PFN 与页内偏移拼接，形成 <strong>物理地址</strong>。</li> <li>访问内存。</li> <li>硬件根据访问类型 (读/写) 可能设置 <strong>访问位 (A)</strong> 或 <strong>修改位 (D)</strong>。</li> </ul> </li> <li><strong>Case 2: PTE 无效 (Valid/Present bit = 0) 或权限不足:</strong> <ul> <li>MMU 产生 <strong>页错误 (Page Fault)</strong> 异常，将控制权交给操作系统。</li> </ul> </li> </ul> </li> </ol> </li> <li><strong>页错误处理 (OS):</strong> (详见 3.6)</li> </ul> <h3>3.5 快表 (Translation Look-aside Buffer - TLB)</h3> <ul> <li><strong>问题:</strong> 多级页表导致每次地址翻译需要多次内存访问，显著降低性能。</li> <li><strong>原理:</strong> 利用 <strong>程序访问的局部性原理</strong> (Locality of Reference)。最近访问过的页面很可能再次被访问。</li> <li><strong>什么是TLB:</strong> <ul> <li>一种高速的、容量小的 <strong>相联存储器 (Associative Memory)</strong>。</li> <li>特点：按 <strong>内容</strong> 并行查找，速度极快。</li> <li>存储内容：缓存近期使用过的 <strong>虚拟页号 (VPN) 到 页框号 (PFN) 的映射</strong> (即部分活跃的页表项)。</li> </ul> </li> <li><strong>工作流程:</strong> <ol> <li>MMU 收到虚拟地址后，<strong>首先并行查找 TLB</strong>。</li> <li><strong>TLB Hit (命中):</strong> 如果在 TLB 中找到匹配的 VPN，直接获取 PFN，快速完成地址转换。跳过页表查找。</li> <li><strong>TLB Miss (未命中):</strong> <ul> <li>MMU 需要访问内存中的页表进行查找。</li> <li>找到 PFN 后，<strong>将 (VPN -> PFN) 的映射关系装入 TLB</strong> (可能需要替换掉 TLB 中的一个旧条目，使用LRU等策略)。</li> <li>完成地址转换。</li> </ul> </li> </ol> </li> <li><strong>TLB 刷新问题:</strong> <ul> <li><strong>问题:</strong> 进程切换时，原进程的 TLB 条目对新进程无效，需要刷新 TLB，导致新进程初期 TLB Miss 增多，性能下降。</li> <li><strong>解决:</strong> <ul> <li><strong>PCID (Process Context Identifier) / ASID (Address Space Identifier):</strong> 给 TLB 条目打上进程标识符。切换进程时，只需加载新进程的 PCID/ASID，TLB 中带有不同 ID 的条目不会被匹配，无需完全刷新。</li> </ul> </li> </ul> </li> <li><strong>关键参数:</strong> TLB 的大小、位置 (通常集成在MMU或CPU核心内) 、替换策略。</li> </ul> <h3>3.6 缺页异常 (Page Fault) 处理</h3> <ul> <li><strong>触发:</strong> 地址转换过程中，MMU 发现所需页面的 PTE 无效 (P=0) 或访问权限不足。</li> <li><strong>本质:</strong> 一种硬件中断/异常，将控制权交给操作系统内核的 <strong>缺页异常处理程序 (Page Fault Handler)</strong>。</li> <li><strong>处理流程 (典型情况 - 页面不在内存):</strong> <ol> <li><strong>保存现场:</strong> 保存用户进程的状态 (PC, 寄存器等) 。</li> <li><strong>确定原因:</strong> 操作系统分析是真缺页 (P=0) ，还是保护性错误 (权限不足) 。如果是后者，可能终止进程。</li> <li><strong>定位磁盘地址:</strong> 如果是真缺页，查找该虚拟页在磁盘 (交换空间或文件) 上的位置。</li> <li><strong>查找空闲页框:</strong> 在物理内存中寻找一个空闲的页框。</li> <li><strong>处理无空闲页框:</strong> <ul> <li><strong>若无空闲页框:</strong> 执行 <strong>页面置换算法</strong>，选择一个牺牲页框 (Victim Frame)。</li> <li><strong>写回脏页:</strong> 如果牺牲页框中的页面是 "脏" 的 (D=1)，则需要将其内容 <strong>写回磁盘</strong>。</li> </ul> </li> <li><strong>调入页面:</strong> 启动磁盘 I/O 操作，将所需的页面从磁盘读入选定的 (空闲或牺牲) 页框。</li> <li><strong>更新页表:</strong> 页面调入完成后，修改该虚拟页对应的 PTE (Page Table Entry，页表项)：设置 P=1，填入 PFN，清除 D 位，可能设置 A 位。</li> <li><strong>恢复现场:</strong> 恢复用户进程的状态。</li> <li><strong>重新执行指令:</strong> 重新执行导致缺页异常的指令。此时地址转换可以成功。</li> </ol> </li> </ul> <h3>3.7 驻留集管理 (Resident Set Management)</h3> <ul> <li><strong>驻留集 (Resident Set):</strong> 进程当前在物理内存中的页面集合。</li> <li><strong>驻留集大小管理:</strong> 决定给每个进程分配多少页框。 <ul> <li><strong>固定分配策略 (Fixed Allocation):</strong> <ul> <li>在进程创建时确定分配的页框数量。</li> <li>分配依据可以是: <ul> <li>进程类型 (交互式、批处理、应用类型) 。</li> <li>程序员指定的需求。</li> <li>系统管理员设置的策略。</li> </ul> </li> <li><strong>特点:</strong> 简单但缺乏灵活性，无法适应进程工作集大小的动态变化。</li> </ul> </li> <li><strong>可变分配策略 (Variable Allocation):</strong> <ul> <li>根据进程的 <strong>缺页率</strong> 动态评估其局部性表现。</li> <li><strong>调整机制:</strong> <ul> <li>缺页率高 → 增加页框数 (扩大驻留集) 。</li> <li>缺页率低 → 减少页框数 (缩小驻留集) 。</li> </ul> </li> <li><strong>优点:</strong> 能够适应程序局部性的变化，提高内存利用率。</li> <li><strong>缺点:</strong> 实现复杂，需要监控缺页率，调整策略可能引入系统开销。</li> </ul> </li> </ul> </li> <li><strong>系统开销考量:</strong> <ul> <li>驻留集管理本身会消耗CPU时间和内存资源。</li> <li>过于频繁的调整可能导致系统开销超过收益。</li> <li>需要在响应性和开销之间找到平衡点。</li> </ul> </li> </ul> <hr> <h2>4. 页面置换算法 (Page Replacement Algorithms)</h2> <h3>4.1 置换问题</h3> <ul> <li><strong>背景:</strong> 当发生缺页异常且没有空闲物理页框时，需要选择一个当前在内存中的页面换出，为新页面腾出空间。</li> <li><strong>目标:</strong> 选择一个 <strong>最近最不可能被访问</strong> 的页面进行置换，以最小化未来的缺页次数。</li> <li><strong>约束:</strong> 不能置换被 <strong>锁定 (Locked/Pinned)</strong> 的页框 (如内核代码、I/O 缓冲区等) 。 <ul> <li><strong>页框锁定:</strong> 通过 PTE 中的锁定位或特殊机制，防止 OS 将某些关键页面换出内存，避免 I/O 操作期间页面被换出导致错误，或保证实时任务的响应时间。</li> </ul> </li> </ul> <h3>4.2 置换范围</h3> <ul> <li> <p><strong>局部置换策略 (Local Replacement):</strong> 仅在引发缺页的那个进程自己的 <strong>驻留集 (Resident Set)</strong> 中选择牺牲页。</p> <ul> <li><strong>优点:</strong> 进程间的隔离性好。</li> <li><strong>缺点:</strong> 可能无法利用系统中其他进程不活跃的页框。</li> </ul> </li> <li> <p><strong>全局置换策略 (Global Replacement):</strong> 可以在内存中所有未锁定的页框中选择牺牲页，无论它属于哪个进程。</p> <ul> <li><strong>优点:</strong> 更灵活，可能提高系统整体吞吐率。</li> <li><strong>缺点:</strong> 一个行为不良的进程可能挤占其他进程的页框；进程的缺页率受其他进程影响，难以控制。</li> </ul> </li> <li> <p><strong>与分配策略的关系:</strong></p> <ul> <li>固定分配通常配合局部置换。</li> <li>可变分配可以配合局部或全局置换。</li> </ul> </li> </ul> <h3>4.3 典型置换算法</h3> <ol> <li> <p><strong>最优置换算法 (Optimal - OPT / MIN):</strong></p> <ul> <li><strong>思想:</strong> 置换 <strong>未来最长时间内不会被访问</strong> 的页面。</li> <li><strong>实现:</strong> 无法实现，因为需要预知未来。</li> <li><strong>作用:</strong> 作为性能比较的 <strong>基准 (Benchmark)</strong>。</li> </ul> </li> <li> <p><strong>先进先出算法 (First-In, First-Out - FIFO):</strong></p> <ul> <li><strong>思想:</strong> 置换 <strong>在内存中驻留时间最长</strong> 的页面。</li> <li><strong>实现:</strong> 维护一个页面进入内存的队列，替换队首页面。</li> <li><strong>优点:</strong> 实现简单。</li> <li><strong>缺点:</strong> 性能较差，可能换出常用页面。存在 <strong>Belady 异常</strong>。</li> </ul> </li> <li> <p><strong>第二次机会算法 (Second Chance - SCR):</strong></p> <ul> <li><strong>思想:</strong> FIFO 的改进。检查队首页面的 <strong>访问位 (A/R)</strong>。</li> <li><strong>流程:</strong> <ul> <li>检查队首页面 PTE 的 A 位。</li> <li>如果 A=0，置换该页。</li> <li>如果 A=1，给它 "第二次机会"：将 A 位清零，并将该页移到队尾，然后检查下一个队首页面。</li> </ul> </li> <li><strong>优点:</strong> 比 FIFO 好，避免了立即换出刚被访问过的页面。</li> </ul> </li> <li> <p><strong>时钟算法 (Clock):</strong></p> <ul> <li><strong>思想:</strong> Second Chance Replacement (SCR，第二次机会算法) 的高效实现，避免了频繁移动页面。</li> <li><strong>实现:</strong> 将所有物理页框组织成一个 <strong>循环链表 (缓冲区)</strong>，用一个指针指向下一个要检查的候选页框。</li> <li><strong>流程:</strong> <ul> <li>发生缺页时，从指针当前位置开始扫描。</li> <li>检查当前页框 PTE 的 A 位。</li> <li>如果 A=0，选择该页框进行置换，将新页面放入，指针前移。</li> <li>如果 A=1，将 A 位清零，指针前移，继续检查下一个页框。</li> </ul> </li> <li><strong>优点:</strong> 实现相对简单，性能优于 FIFO，接近 LRU。</li> </ul> </li> <li> <p><strong>最近未使用算法 (Not Recently Used - NRU):</strong></p> <ul> <li><strong>思想:</strong> 优先淘汰近期 <strong>既未被访问 (A=0) 也未被修改 (D=0)</strong> 的页面。</li> <li><strong>实现:</strong> 利用 PTE 中的 <strong>访问位 (A)</strong> 和 <strong>修改位 (D)</strong> 将页面分为四类： <ul> <li>第 0 类: (A=0, D=0) - 未访问，未修改</li> <li>第 1 类: (A=0, D=1) - 未访问，已修改</li> <li>第 2 类: (A=1, D=0) - 已访问，未修改</li> <li>第 3 类: (A=1, D=1) - 已访问，已修改</li> </ul> </li> <li><strong>流程:</strong> OS 定期将所有页面的 A 位清零。发生缺页时，<strong>随机</strong> 从编号最小的非空类别中选择一个页面进行置换。</li> <li><strong>优点:</strong> 实现简单，性能尚可。</li> </ul> </li> <li> <p><strong>NRU 的时钟实现:</strong> (一种变体)</p> <ul> <li><strong>扫描 1:</strong> 找第一个 (A=0, D=0) 的页框，找到即置换。此过程不清 A 位。</li> <li><strong>扫描 2 (若扫描 1 失败):</strong> 重新扫描，找第一个 (A=0, D=1) 的页框。此过程中，<strong>跳过的页框 (A=1) 的 A 位被清零</strong>。找到即置换。</li> <li><strong>扫描 3 (若扫描 2 失败):</strong> 此时所有页框 A 位都为 0。重复扫描 1 (必然能找到 A=0, D=0 或 A=0, D=1) ，然后如有必要重复扫描 2。</li> <li><strong>特点:</strong> 优先换出干净页 (D=0)，节省写回磁盘的时间。</li> </ul> </li> <li> <p><strong>最近最少使用算法 (Least Recently Used - LRU):</strong></p> <ul> <li><strong>思想:</strong> 置换 <strong>过去最长时间未被访问</strong> 的页面。基于局部性原理，认为最久未用的页面，近期也最不可能被使用。</li> <li><strong>实现:</strong> <ul> <li><strong>时间戳法:</strong> 每个 PTE 记录上次访问时间，置换时间戳最小的。 (硬件开销大)</li> <li><strong>栈/链表法:</strong> 维护一个按访问时间排序的页面栈/链表，每次访问将页面移到栈顶/链表头，置换栈底/链表尾的页面。 (软件开销大)</li> </ul> </li> <li><strong>优点:</strong> 性能非常好，接近 OPT。</li> <li><strong>缺点:</strong> 实现开销大，纯硬件或纯软件实现都困难。</li> </ul> </li> <li> <p><strong>最不经常使用算法 (Not Frequently Used - NFU):</strong></p> <ul> <li><strong>思想:</strong> 置换 <strong>过去访问次数最少</strong> 的页面。LRU 的一种软件近似。</li> <li><strong>实现:</strong> 每个 PTE 关联一个软件计数器，初值为 0。每次时钟中断，检查 A 位，若 A=1，则对应计数器加 1，并将 A 位清零。缺页时置换计数值最小的页面。</li> <li><strong>缺点:</strong> 不能很好地区分早期频繁访问但近期不用的页面和近期才开始访问的页面。</li> </ul> </li> <li> <p><strong>老化算法 (Aging):</strong></p> <ul> <li><strong>思想:</strong> 模拟 LRU。改进 NFU，使计数器能反映访问的时间远近。</li> <li><strong>实现:</strong> 每个 PTE 关联一个多位计数器 (e.g., 8-bit)。每次时钟中断： <ol> <li>将每个计数器 <strong>右移 1 位</strong> (模拟时间流逝，旧的访问权重降低)。</li> <li>将当前 PTE 的 <strong>A 位</strong> 加到计数器的 <strong>最左边 (最高位)</strong>。</li> <li>将 A 位清零。</li> </ol> </li> <li>缺页时，置换计数值最小的页面。计数值小的页面表示近期访问较少或很久未访问。</li> <li><strong>优点:</strong> 较好地模拟了 LRU，实现开销适中。</li> <li><strong>与LRU的区别:</strong> <ul> <li><strong>精确度:</strong> LRU 精确记录每次访问的时间顺序，而 Aging 只能近似反映访问频率和时间远近。</li> <li><strong>实现开销:</strong> LRU 需要在每次内存访问时更新数据结构，开销大；Aging 只在时钟中断时更新计数器，开销小。</li> <li><strong>历史长度:</strong> LRU 可以无限追溯历史访问记录；Aging 受计数器位数限制 (如8位只能记录最近8个时间窗口的访问情况) 。</li> <li><strong>硬件支持:</strong> LRU 需要专门硬件支持才能高效实现；Aging 只需要访问位支持，更易于实现。</li> </ul> </li> </ul> </li> </ol> <h3>4.4 算法示例与现象</h3> <ul> <li> <p><strong>FIFO, LRU, OPT 缺页次数计算:</strong></p> <ul> <li> <p><strong>例子:</strong> 页面访问序列 <code>2 3 2 1 5 2 4 5 3 2 5 2</code>，分配 3 个页框。</p> </li> <li> <p><strong>FIFO 算法过程:</strong> | 访问页面 | 2 | 3 | 2 | 1 | 5 | 2 | 4 | 5 | 3 | 2 | 5 | 2 | | -------- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 页框1 | 2 | 2 | 2 | 2 | 5 | 5 | 5 | 5 | 3 | 3 | 3 | 3 | | 页框2 | - | 3 | 3 | 3 | 3 | 2 | 2 | 2 | 2 | 2 | 5 | 5 | | 页框3 | - | - | - | 1 | 1 | 1 | 4 | 4 | 4 | 4 | 4 | 2 | | 缺页 | √ | √ | × | √ | √ | √ | √ | × | √ | × | √ | √ |</p> <p>总计9次缺页</p> </li> <li> <p><strong>LRU 算法过程:</strong> | 访问页面 | 2 | 3 | 2 | 1 | 5 | 2 | 4 | 5 | 3 | 2 | 5 | 2 | | -------- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 页框1 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 3 | 3 | 3 | 3 | | 页框2 | - | 3 | 3 | 3 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | | 页框3 | - | - | - | 1 | 1 | 1 | 4 | 4 | 4 | 2 | 2 | 2 | | 缺页 | √ | √ | × | √ | √ | × | √ | × | √ | √ | × | × |</p> <p>总计7次缺页</p> </li> <li> <p><strong>OPT 算法过程:</strong> | 访问页面 | 2 | 3 | 2 | 1 | 5 | 2 | 4 | 5 | 3 | 2 | 5 | 2 | | -------- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 页框1 | 2 | 2 | 2 | 2 | 2 | 2 | 4 | 4 | 4 | 2 | 2 | 2 | | 页框2 | - | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | | 页框3 | - | - | - | 1 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | | 缺页 | √ | √ | × | √ | √ | × | √ | × | × | √ | × | × |</p> <p>总计6次缺页, 可以发现重点是第五次访问要把 1 换出去, 因为我们知道未来信息 1 不再被用到了</p> </li> </ul> </li> <li> <p><strong>Belady 异常 (Belady's Anomaly):</strong></p> <ul> <li><strong>现象:</strong> 对于某些置换算法 (如 FIFO) ，增加分配给进程的物理页框数，缺页次数 <strong>反而增加</strong> 的反常现象。</li> <li><strong>例子:</strong> 序列 <code>1 2 3 4 1 2 5 1 2 3 4 5</code>，FIFO算法。 <ul> <li> <p>m=3 时，缺页过程: | 访问页面 | 1 | 2 | 3 | 4 | 1 | 2 | 5 | 1 | 2 | 3 | 4 | 5 | | -------- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 页框1 | 1 | 1 | 1 | 4 | 4 | 4 | 5 | 5 | 5 | 5 | 5 | 5 | | 页框2 | - | 2 | 2 | 2 | 1 | 1 | 1 | 1 | 1 | 3 | 3 | 3 | | 页框3 | - | - | 3 | 3 | 3 | 2 | 2 | 2 | 2 | 2 | 4 | 4 | | 缺页 | √ | √ | √ | √ | √ | √ | √ | × | × | √ | √ | × |</p> <p>总计9次缺页</p> </li> <li> <p>m=4 时，缺页过程: | 访问页面 | 1 | 2 | 3 | 4 | 1 | 2 | 5 | 1 | 2 | 3 | 4 | 5 | | -------- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 页框1 | 1 | 1 | 1 | 1 | 1 | 1 | 5 | 5 | 5 | 5 | 4 | 4 | | 页框2 | - | 2 | 2 | 2 | 2 | 2 | 2 | 1 | 1 | 1 | 1 | 5 | | 页框3 | - | - | 3 | 3 | 3 | 3 | 3 | 3 | 2 | 2 | 2 | 2 | | 页框4 | - | - | - | 4 | 4 | 4 | 4 | 4 | 4 | 3 | 3 | 3 | | 缺页 | √ | √ | √ | √ | × | × | √ | √ | √ | √ | √ | √ |</p> <p>总计10次缺页</p> </li> </ul> </li> <li><strong>原因:</strong> FIFO 只考虑进来的时间，不考虑进来之后的访问情况。增加页框可能导致一个"坏"的页面 (未来会用到) 驻留更久，从而在后面挤掉了更有用的页面。</li> <li><strong>LRU 和 OPT 不存在 Belady 异常:</strong> 因为它们满足 <strong>栈属性 (Stack Property)</strong>：即 <code>m</code> 个页框时的内存内容总是 <code>m+1</code> 个页框时内存内容的子集。增加页框只会包含更多有用的页，不会导致缺页增加。</li> </ul> </li> </ul> <h3>4.5 影响缺页次数的因素</h3> <ul> <li><strong>页面置换算法:</strong> 好算法 ≈ 少缺页。</li> <li><strong>分配给进程的物理页框数:</strong> 太少会导致频繁缺页，过多则浪费内存。存在一个最佳范围。</li> <li><strong>页面尺寸问题:</strong> <ul> <li>确定页面大小对于分页的硬件设计非常重要，而对于操作系统是个可选的参数。</li> <li><strong>要考虑的因素:</strong> <ul> <li><strong>内部碎片:</strong> 页面越大，内部碎片越多；页面越小，内部碎片越少。</li> <li><strong>页表长度:</strong> 页面越大，页表越小；页面越小，页表越大。</li> <li><strong>辅存的物理特性:</strong> 磁盘传输特性影响最佳页面大小选择。</li> <li><strong>TLB 覆盖范围:</strong> 影响地址转换性能。</li> </ul> </li> <li><strong>小页面优缺点:</strong> <ul> <li><strong>优点:</strong> 减少内部碎片，更适合程序局部性。</li> <li><strong>缺点:</strong> 页表变大，TLB 效率可能降低，磁盘 I/O 效率低。</li> </ul> </li> <li><strong>大页面优缺点:</strong> <ul> <li><strong>优点:</strong> 页表小，TLB 覆盖范围大，磁盘 I/O 效率高。</li> <li><strong>缺点:</strong> 内部碎片增加，可能不适合小局部性。</li> </ul> </li> <li><strong>最优页面大小:</strong> 理论上可以用公式 P = √(2se) 来计算，其中 $s$ 是页表项的大小 (表示页表开销) ，$e$ 是平均程序段大小 (表示内部碎片开销) 。这个公式平衡了页表大小和内部碎片之间的权衡。</li> <li><strong>实际实现:</strong> <ul> <li><strong>Intel 80x86/Pentium:</strong> 支持 4KB 或 4MB 页面大小。</li> <li><strong>现代系统:</strong> 通常支持多种页面大小 (如 4KB, 2MB, 1GB) ，为有效使用TLB带来灵活性，但给操作系统带来复杂性。</li> <li>OS 和应用可根据需求灵活选择不同页面大小。</li> </ul> </li> </ul> </li> <li><strong>程序的编制方法:</strong> 访问模式影响局部性。 <ul> <li><strong>例子:</strong> 只分配了<strong>一个 4KB页框</strong>，访问按行存储的二维数组 <code>A[1024][1024]</code> (4KB页面)。 <ul> <li><strong>按行访问 (方法2):</strong> <code>for(i)... for(j)... A[i][j]</code>。空间局部性好，每次访问都在同一页或下一页，缺页少 ( 1024 次，每行开始时缺页) 。</li> <li><strong>按列访问 (方法1):</strong> <code>for(j)... for(i)... A[i][j]</code>。空间局部性差，每次访问 <code>A[i][j]</code> 和 <code>A[i+1][j]</code> 会跨越多个页面 (1024*4 bytes ≈ 1 page) ，导致大量缺页 (1024 * 1024 次) 。</li> </ul> </li> </ul> </li> <li><strong>颠簸/抖动 (Thrashing):</strong> <ul> <li><strong>定义:</strong> 当系统内存严重不足，分配给进程的页框远小于其活跃页面所需时，进程会不断地发生缺页，大部分时间都用于页面换入换出，而不是真正执行计算。导致系统效率急剧下降。</li> <li><strong>原因:</strong> 并发度过高，或进程所需工作集大于可用内存。</li> <li><strong>表现:</strong> CPU 利用率很低，但磁盘 I/O 非常繁忙。</li> </ul> </li> </ul> <hr> <h2>5. 高级内存管理策略</h2> <h3>5.1 工作集模型 (Working Set Model)</h3> <ul> <li><strong>提出者:</strong> Denning (1968)</li> <li><strong>基本思想:</strong> 基于 <strong>程序访问的局部性原理</strong>。一个进程在任何时刻都倾向于访问一个相对较小的页面集合，称为 <strong>活跃页面 (Active Pages)</strong>。如果能将这些活跃页面都保留在内存中，就能显著减少缺页。</li> <li><strong>工作集 (Working Set) W(t, Δ):</strong> 在当前时间 <code>t</code> 之前的 <strong>时间窗口 Δ</strong> 内，进程实际访问过的 <strong>虚拟页面</strong> 的集合。 <ul> <li>Δ: 工作集窗口大小，是一个关键参数。</li> <li>工作集大小 <code>|W(t, Δ)|</code> 随时间动态变化。</li> </ul> </li> <li><strong>与驻留集的关系:</strong> <ul> <li><strong>驻留集 (Resident Set):</strong> 当前时刻，进程 <strong>实际</strong> 驻留在物理内存中的页面集合。由 OS 分配策略和置换算法决定。</li> <li><strong>理想状态:</strong> 进程的驻留集应包含其当前的工作集 (<code>Resident Set >= Working Set</code>)。</li> </ul> </li> <li><strong>工作集策略应用:</strong> <ul> <li><strong>置换:</strong> 换出不在当前工作集中的页面。</li> <li><strong>加载控制:</strong> 只有当一个进程的工作集能够被完全调入内存时，才激活该进程运行，否则挂起。防止 Thrashing。</li> </ul> </li> </ul> <h3>5.2 工作集算法 (实现工作集置换)</h3> <ul> <li><strong>基本思路:</strong> 识别并换出不在当前工作集 (W(t, Δ)) 中的页面。</li> <li><strong>一种实现:</strong> <ul> <li><strong>PTE 增强:</strong> 每个 PTE 增加一个字段，记录该页面的 <strong>最后访问时间 (Last Use Time)</strong>。</li> <li><strong>参数:</strong> 设置一个时间阈值 <code>T</code> (近似 Δ)。</li> <li><strong>扫描过程 (类似时钟):</strong> <ol> <li>定期或缺页时扫描页框。</li> <li>检查 PTE 的 A 位： <ul> <li>若 A=1: 表示在当前时钟滴答内被访问。记录 <strong>当前虚拟时间</strong> 到 PTE 的 "最后访问时间" 字段，并将 A 位清零。</li> <li>若 A=0: 表示在当前滴答内未被访问。计算 <strong>页面年龄 (Age) = 当前虚拟时间 - 最后访问时间</strong>。</li> </ul> </li> <li><strong>判断与置换:</strong> <ul> <li>如果 Age > T (页面“老”，不在工作集内)： <ul> <li>如果页面是干净的 (D=0)，则该页面是 <strong>最佳</strong> 牺牲页，直接置换。</li> <li>如果页面是脏的 (D=1)，先记录下来，继续扫描，希望能找到一个干净的老页面。如果找不到干净的老页面，最后回来置换这个脏的老页面 (需要写回磁盘) 。</li> </ul> </li> <li>如果 Age ≤ T (页面“年轻”，在工作集内)：保留该页面，继续扫描。</li> </ul> </li> </ol> </li> </ul> </li> <li><strong>讨论:</strong> <ul> <li>精确实现工作集算法开销较大 (需要记录和比较时间) 。</li> <li><strong>缺页率算法 (Page Fault Frequency - PFF):</strong> 一种近似方法。通过监控进程的缺页率来动态调整其驻留集大小。 <ul> <li>设置缺页率上限和下限。</li> <li>缺页率 > 上限: 增加进程的页框数。</li> <li>缺页率 &#x3C; 下限: 减少进程的页框数。</li> </ul> </li> </ul> </li> </ul> <h3>5.3 清除策略 (Cleaning Policy)</h3> <ul> <li><strong>问题:</strong> 当需要空闲页框时，如果选中的牺牲页是 "脏" 的，需要先写回磁盘，增加了缺页处理时间。</li> <li><strong>目标:</strong> 保持一定数量的 <strong>干净 (Clean)</strong> 空闲页框可用。</li> <li><strong>实现:</strong> 使用 <strong>分页守护进程 (Paging Daemon)</strong> (如 <code>kswapd</code> in Linux)。 <ul> <li>该进程周期性 (或在内存不足时) 被唤醒。</li> <li>检查内存状态，如果空闲页框低于某个阈值。</li> <li>使用页面置换算法 (如 Clock 或 LRU 近似) 选择一些页面。</li> <li>如果选中的页面是脏页，则启动 I/O 将其 <strong>提前写回 (Write Back)</strong> 磁盘，并将其标记为干净。</li> <li>这样，未来需要空闲页框时，可以直接使用这些已变干净的页框，或者快速换出它们。</li> </ul> </li> <li><strong>双指针时钟 (Two-Handed Clock):</strong> <ul> <li><strong>前指针 (Cleaning Hand):</strong> 由分页守护进程控制。扫描页框，遇到脏页就启动写回，然后将其标记为干净；遇到干净页则跳过。前指针不断“清洁”页面。</li> <li><strong>后指针 (Eviction Hand):</strong> 由缺页处理程序控制。用于实际选择牺牲页。由于前指针的工作，后指针更有可能遇到干净页面，从而加速缺页处理。</li> </ul> </li> </ul> <h3>5.4 页缓冲技术 (Page Buffering)</h3> <ul> <li><strong>目的:</strong> 进一步提高性能，减少因页面换出又立即换回造成的开销。</li> <li><strong>思路:</strong> <ul> <li>被置换出的页面 <strong>不立即</strong> 丢弃或覆盖。</li> <li>维护两个链表： <ul> <li><strong>空闲页链表 (Free Page List):</strong> 存放被置换出的 <strong>干净</strong> 页面。</li> <li><strong>修改页链表 (Modified Page List):</strong> 存放被置换出的 <strong>脏</strong> 页面。</li> </ul> </li> <li>这些页面 <strong>暂时保留在内存中</strong>。</li> <li><strong>优点:</strong> <ul> <li><strong>快速回收 (Soft Fault):</strong> 如果进程很快又要访问刚被“置换”到这两个链表中的页面，可以直接将其重新链回进程的驻留集，无需磁盘 I/O。</li> <li><strong>簇写回 (Cluster Write):</strong> 修改页链表中的脏页可以累积起来，<strong>成簇地 (in clusters)</strong> 写回磁盘，而不是一次只写一页，提高了磁盘 I/O 效率。</li> </ul> </li> </ul> </li> <li><strong>Page Cache (如 OSTEP 23章 提及):</strong> 现代 OS 中广泛使用的技术，用于缓存文件数据和匿名页 (包括上述缓冲的页面) 。 <ul> <li><strong>基本概念:</strong> 操作系统在物理内存中维护的一个缓存区域，用于存储最近访问的文件数据和元数据。</li> <li><strong>工作原理:</strong> <ul> <li>当进程读取文件时，数据首先从磁盘加载到 page cache，然后再传递给进程。</li> <li>当进程写入文件时，数据先写入 page cache，标记为"脏"，稍后由后台进程 (如 pdflush/flush/kswapd) 异步写回磁盘。</li> <li>后续对相同文件数据的访问可直接从 page cache 获取，避免磁盘 I/O。</li> </ul> </li> <li><strong>管理策略:</strong> <ul> <li>使用类似 LRU 的替换算法 (如 Linux 的 2Q) 决定哪些页面保留在缓存中。</li> <li>通过 readahead 机制预读文件数据，提高顺序访问性能。</li> <li>支持 write-back (延迟写) 和 write-through (直接写) 两种写入策略。</li> </ul> </li> <li><strong>优势:</strong> <ul> <li><strong>减少磁盘 I/O:</strong> 大幅降低文件操作的延迟，提高系统整体性能。</li> <li><strong>统一缓存:</strong> 在现代系统中，page cache 通常与 buffer cache 统一，形成统一缓存管理。</li> <li><strong>内存利用:</strong> 未使用的物理内存自动用于缓存，提高内存利用率。</li> </ul> </li> <li><strong>2Q 算法:</strong> 一种近似 LRU 的页面缓存替换算法，但开销更低且能应对 LRU 不擅长的场景。 <ul> <li><strong>基本结构:</strong> 维护两个队列: <ul> <li><strong>非活跃队列 (A1):</strong> 存放首次访问的页面。</li> <li><strong>活跃队列 (Am):</strong> 存放多次访问的页面。</li> </ul> </li> <li><strong>工作流程:</strong> <ul> <li>当页面第一次被访问时，放入非活跃队列 A1 的头部。</li> <li>当页面在 A1 中再次被访问时，将其从 A1 移除并放入活跃队列 Am 的头部。</li> <li>当页面在 Am 中被访问时，将其移到 Am 的头部 (类似 LRU) 。</li> <li>需要置换页面时，总是从非活跃队列 A1 的尾部选择牺牲页。</li> <li>定期将活跃队列 Am 尾部的页面移回非活跃队列 A1，以保持整个缓存中约 2/3 的页面在活跃队列中。</li> </ul> </li> <li><strong>优势:</strong> 能有效应对扫描型工作负载 (如顺序读取大文件) 导致的频繁页面互换问题，这类场景下传统 LRU 表现不佳。</li> </ul> </li> </ul> </li> </ul> <h3>5.5 加载控制 (Load Control)</h3> <ul> <li><strong>问题:</strong> 系统中并发运行的进程过多，总内存需求超过物理内存容量，导致 Thrashing。</li> <li><strong>目标:</strong> 控制系统的 <strong>并发度 (Multiprogramming Level)</strong>，即同时驻留在内存中 (活跃) 的进程数量。</li> <li><strong>解决方案:</strong> <ul> <li><strong>进程挂起/交换 (Process Suspension/Swapping):</strong> 当系统负载过高 (如通过高缺页率或低 CPU 利用率检测到 Thrashing) 时，选择一个或多个进程，将其 <strong>所有页面</strong> 换出到磁盘 (交换区) ，并将其置于挂起状态。</li> <li><strong>选择标准:</strong> 选择哪些进程挂起？通常选择低优先级进程、长时间阻塞的进程，或者导致最多缺页的进程。</li> <li><strong>效果:</strong> 释放大量内存，降低活跃进程的内存竞争，使剩余进程能够获得足够的工作集空间，恢复系统效率。</li> </ul> </li> </ul> <hr> <h2>6. 内存映射文件 (Memory-Mapped Files)</h2> <h3>6.1 基本思想</h3> <ul> <li>允许进程将一个 <strong>文件</strong> 或文件的一部分直接 <strong>映射</strong> 到其 <strong>虚拟地址空间</strong> 的一个区域。</li> <li>映射后，进程可以像访问普通内存 (如数组) 一样 <strong>通过内存读写指令</strong> 来访问文件内容，而无需使用 <code>read()</code> / <code>write()</code> 等系统调用。</li> </ul> <h3>6.2 工作机制</h3> <ul> <li><strong>系统调用:</strong> 如 POSIX 的 <code>mmap()</code>。</li> <li><strong>映射建立:</strong> <code>mmap()</code> 调用并不立即读取文件内容。它只是在进程的虚拟地址空间中建立一个区域 (<code>vm_area_struct</code> in Linux)，并设置相应的页表项指向 <strong>文件</strong> 作为后备存储 (Backing Store)。PTE 初始标记为无效。</li> <li><strong>按需调页:</strong> 当进程 <strong>首次访问</strong> 映射区域中的某个地址时，会触发 <strong>缺页异常</strong>。</li> <li><strong>缺页处理:</strong> OS 识别出这是一个映射文件的缺页，计算出该虚拟地址对应文件中的偏移量，然后从 <strong>磁盘文件</strong> 读取相应的 <strong>数据块 (页)</strong> 到一个物理页框，并更新 PTE 使其有效。</li> <li><strong>写回:</strong> <ul> <li>如果映射是 <strong>共享的 (MAP_SHARED)</strong>，对内存区域的修改 <strong>最终会写回</strong> 磁盘上的原始文件 (通常在页面换出时、或调用 <code>msync()</code>、或解除映射 <code>munmap()</code> 时) 。其他映射同一文件的进程也能看到修改。</li> <li>如果映射是 <strong>私有的 (MAP_PRIVATE)</strong>，使用 <strong>写时复制 (Copy-on-Write)</strong>。首次写入时，会为该进程创建一个私有的页面副本，后续修改只影响此副本，不影响原始文件或其他进程。</li> </ul> </li> </ul> <p>一些问题:</p> <ul> <li><strong>内核空间共享:</strong> 在现代操作系统中，内核空间通常在所有进程间共享 <ul> <li><strong>实现方式:</strong> 每个进程的页表中，映射到内核空间的部分是相同的，指向同一组物理页框</li> <li><strong>优势:</strong> <ul> <li>减少内存占用：避免为每个进程复制一份内核代码和数据</li> <li>提高效率：进程切换时无需切换内核部分的地址映射</li> <li>简化内核访问：系统调用时可以直接访问内核数据结构</li> </ul> </li> <li><strong>Linux实现:</strong> 通过将所有进程的高地址部分映射到相同的内核物理页面实现</li> </ul> </li> <li><strong>减轻页表增长压力的方式:</strong> <ul> <li><strong>稀疏地址空间处理:</strong> <ul> <li><strong>多级页表 (Multi-level Page Tables):</strong> 将页表分为多级，只为实际使用的地址区域分配页表项，避免为整个虚拟地址空间分配连续页表</li> <li><strong>倒排页表 (Inverted Page Tables):</strong> 以物理页框为索引建立表项，每个表项记录映射到该物理页的虚拟页信息，页表大小与物理内存成正比而非虚拟地址空间</li> </ul> </li> </ul> </li> <li><strong>大页模式 (Huge Pages/Large Pages):</strong> <ul> <li><strong>解决的问题:</strong> <ul> <li><strong>减少TLB缺失:</strong> 使用大页可以增加TLB覆盖范围，单个TLB表项可以映射更大内存区域(如2MB或1GB而非4KB)</li> <li><strong>减少页表层级:</strong> 减少地址转换时的页表遍历层数，降低内存访问延迟</li> <li><strong>减少页表大小:</strong> 相同大小的内存区域需要更少的页表项，节省页表空间</li> <li><strong>提高内存密集型应用性能:</strong> 数据库、科学计算等应用可显著受益</li> </ul> </li> <li><strong>代价:</strong> <ul> <li><strong>内部碎片增加:</strong> 如果应用只使用大页的一小部分，会造成内存浪费</li> <li><strong>内存分配挑战:</strong> 需要连续的物理内存块，在系统运行一段时间后可能难以满足</li> <li><strong>页面换出复杂化:</strong> 换出一个大页需要更多I/O操作，可能增加延迟</li> <li><strong>细粒度保护受限:</strong> 无法为大页内的不同区域设置不同的访问权限</li> <li><strong>内存管理复杂性增加:</strong> 系统需要同时管理标准页和大页，增加内存管理复杂度</li> </ul> </li> </ul> </li> </ul> <h3>6.3 <code>mmap()</code> 函数 (POSIX 示例)</h3> <p><code>void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);</code></p> <ul> <li><code>start</code>: 建议的映射起始虚拟地址 (通常设为 NULL，由内核选择)。</li> <li><code>length</code>: 映射的字节数。</li> <li><code>prot</code>: 内存保护标志 (指定映射区域的访问权限)。 <ul> <li><code>PROT_READ</code>: 可读。</li> <li><code>PROT_WRITE</code>: 可写。</li> <li><code>PROT_EXEC</code>: 可执行。</li> <li><code>PROT_NONE</code>: 不可访问。</li> </ul> </li> <li><code>flags</code>: 映射类型和选项。 <ul> <li><code>MAP_SHARED</code>: 共享映射，修改会写回文件。</li> <li><code>MAP_PRIVATE</code>: 私有写时复制映射。</li> <li><code>MAP_ANONYMOUS</code> (或 <code>MAP_ANON</code>): 匿名映射，不关联任何文件，用于分配内存 (类似 <code>malloc</code>) 。常与 <code>MAP_PRIVATE</code> 结合用于进程的堆、栈、BSS段。</li> </ul> </li> <li><code>fd</code>: 要映射的文件描述符。对于匿名映射，此参数忽略 (通常设为 -1) 。</li> <li><code>offset</code>: 文件内的映射起始偏移量 (必须是页面大小的倍数) 。</li> </ul> <h3>6.4 <code>mmap</code> 与 <code>shm</code> (共享内存) 对比</h3> <ul> <li><strong><code>mmap</code> (基于文件):</strong> <ul> <li><strong>通信方式:</strong> 通过映射 <strong>同一个磁盘文件</strong> 到不同进程的地址空间实现共享。</li> <li><strong>持久性:</strong> 共享内容与磁盘文件关联，可以是持久的。</li> <li><strong>使用场景:</strong> 共享大文件，IPC，加载动态库，程序加载器。</li> </ul> </li> <li><strong><code>shm</code> (System V Shared Memory):</strong> <ul> <li><strong>通信方式:</strong> 使用 <code>shmget()</code> 创建一个内核管理的 <strong>纯内存</strong> 共享区域，然后用 <code>shmat()</code> 将其附加到进程地址空间。</li> <li><strong>持久性:</strong> 通常是临时的，与进程生命周期或显式删除 (<code>shmctl</code> with <code>IPC_RMID</code>) 相关，不直接关联磁盘文件。</li> <li><strong>性能:</strong> 可能比基于文件的 <code>mmap</code> 更快，因为它不涉及文件系统开销 (除非发生交换) 。</li> <li><strong>大小限制:</strong> 受可用物理内存/交换空间限制。</li> </ul> </li> </ul> <h3>6.5 <code>mmap</code> 相关思考</h3> <ul> <li><strong><code>mmap</code> 比物理内存+Swap空间大，是否有问题?</strong> <ul> <li><strong>解答:</strong> <code>mmap</code> 本身 <strong>可以</strong> 映射比物理内存+Swap 大得多的文件。<code>mmap</code> 只是建立了虚拟地址到文件内容的 <strong>潜在</strong> 映射。只有当进程 <strong>实际访问</strong> 映射区域的页面时，才需要将其调入物理内存。这里需要区分两种情况： <ul> <li><strong>文件映射:</strong> 对于映射到文件的页面，文件本身就是这些页面的"后备存储"。当内存不足时，如果这些页面没有被修改过(非脏页)，可以直接丢弃，需要时再从文件重新读取；如果被修改过(脏页)，则需要先写回文件再释放。</li> <li><strong>匿名映射:</strong> 没有关联文件的映射区域(如堆)，必须使用Swap空间作为后备存储。Swap是专门用于存储从内存中换出的页面的磁盘区域。</li> </ul> 因此，文件映射可以超过物理内存+Swap的总大小，因为它使用原始文件作为后备存储。但如果工作集(实际访问的页面总数)超过了物理内存+Swap，系统会发生<strong>颠簸(Thrashing)</strong>，性能急剧下降，尽管映射本身是合法的。</li> </ul> </li> <li><strong>使用 <code>mmap</code> 代替 <code>read/write</code> 进行文件读写的优势?</strong> <ul> <li><strong>解答:</strong> <ol> <li><strong>减少数据拷贝:</strong> <code>read/write</code> 通常涉及数据在内核缓冲区和用户缓冲区之间的拷贝。<code>mmap</code> 允许进程直接访问内核的页缓存 (或直接从磁盘调页) ，<strong>避免了这次拷贝</strong>，提高效率，尤其对于大文件或频繁读写。</li> <li><strong>简化随机访问:</strong> 对于需要频繁在文件中随机定位读写的场景，<code>mmap</code> 将文件视为内存数组，可以通过指针运算直接访问任意位置，代码更简洁，无需管理文件指针和复杂的 <code>lseek</code> 调用。</li> <li><strong>内核优化:</strong> 内核可以更有效地管理 <code>mmap</code> 区域的页面缓存和预读。</li> </ol> </li> </ul> </li> </ul> <h3>6.6 内存映射文件应用示例</h3> <ul> <li><strong>程序加载:</strong> 加载可执行文件和动态链接库 (DLLs/SOs) 时，代码段和只读数据段通常通过私有映射 (<code>MAP_PRIVATE</code>) 加载，数据段通过写时复制加载。</li> <li><strong>进程间通信 (IPC):</strong> 通过共享映射 (<code>MAP_SHARED</code>) 同一个文件 (或匿名映射) ，实现高效的数据共享。</li> <li><strong>数据库:</strong> 像 LMDB (Lightning Memory-Mapped Database) 这样的内存映射数据库，将整个数据库文件映射到内存，利用 OS 的虚拟内存管理进行数据缓存和访问，简化了缓冲管理，提高了 I/O 性能。</li> </ul> <hr> <h2>7. 虚拟内存管理全貌 (结合进程结构)</h2> <ul> <li><strong>进程控制块 (PCB / <code>task_struct</code> in Linux):</strong> 包含指向内存描述符 (<code>mm_struct</code>) 的指针。</li> <li><strong>内存描述符 (<code>mm_struct</code>):</strong> 描述进程的整个虚拟地址空间，包含指向页表的指针 (如 CR3 指向的页目录物理地址) 和指向虚拟内存区域链表/树 (<code>vm_area_struct</code> list/tree) 的指针。</li> <li><strong>虚拟内存区域 (<code>vm_area_struct</code> - VMA):</strong> 描述进程地址空间中一段 <strong>连续</strong> 的、具有 <strong>相同属性</strong> (如权限、映射文件) 的虚拟内存区域。例如，代码段、数据段、堆、栈、每个内存映射文件、每个共享库都对应一个或多个 VMA。 <ul> <li><strong>关键字段:</strong> 起始地址 (<code>vm_start</code>), 结束地址 (<code>vm_end</code>), 访问权限 (<code>vm_prot</code>), 标志 (<code>vm_flags</code>, 如 <code>VM_READ</code>, <code>VM_WRITE</code>, <code>VM_EXEC</code>, <code>VM_SHARED</code>), 指向映射文件信息的指针 (<code>vm_file</code>) 等。</li> </ul> </li> <li><strong>页表 (Page Tables):</strong> 将 VMA 内的虚拟页号映射到物理页框号或标记为不在内存。</li> <li><strong>物理内存 (Page Frames):</strong> 实际存储数据的内存块。</li> <li><strong>后备存储 (Backing Store):</strong> 磁盘上的文件 (可执行文件、库、数据文件) 或交换空间 (Swap Area)，用于存放不在物理内存中的页面。</li> </ul> <p><strong>交互过程:</strong> 访问虚拟地址 -> 查找 VMA -> 查找页表 (TLB first) -> 访问物理内存 / Page Fault -> (缺页处理) -> 访问后备存储。</p> <hr> <h2>8. 写时复制 (Copy-on-Write - COW)</h2> <ul> <li><strong>目的:</strong> 优化资源 (特别是内存) 的复制过程，推迟实际的物理复制，直到真正需要时才进行。</li> <li><strong>应用场景:</strong> <ul> <li><code>fork()</code> 系统调用创建子进程。</li> <li>私有内存映射 (<code>MAP_PRIVATE</code>)。</li> </ul> </li> <li><strong>机制:</strong> <ol> <li><strong>共享初始副本:</strong> 当创建副本时 (如 <code>fork()</code> 创建子进程) ，并不立即复制父进程的物理内存页面。而是让子进程的页表项指向与父进程 <strong>相同</strong> 的物理页框。</li> <li><strong>标记为只读:</strong> 同时，将这些共享页框在 <strong>父子进程的页表项中都标记为只读 (Read-Only)</strong>，即使它们原本是可写的。</li> <li><strong>写操作触发异常:</strong> 如果任何一个进程 (父或子) 尝试 <strong>写入</strong> 这些共享的页面，会触发一个 <strong>保护性页错误 (Protection Fault)</strong>。</li> <li><strong>真正复制:</strong> 操作系统捕获此异常，识别出是 COW 机制。此时，内核会： <ul> <li>分配一个新的物理页框。</li> <li>将原始页框的内容 <strong>复制</strong> 到新页框。</li> <li>修改 <strong>触发写入操作的那个进程</strong> 的页表项，使其指向 <strong>新复制的页框</strong>，并将该页表项的权限 <strong>恢复为可写 (Read-Write)</strong>。</li> </ul> </li> <li><strong>恢复执行:</strong> 进程继续执行写操作，现在写入的是它自己的私有副本。</li> </ol> </li> <li><strong>优点:</strong> <ul> <li><strong><code>fork()</code> 效率高:</strong> 如果子进程立刻调用 <code>exec()</code> 加载新程序，那么之前的大部分复制就白费了。COW 避免了这种不必要的开销。</li> <li><strong>节省内存:</strong> 只要页面不被修改，父子进程可以一直共享同一物理副本。</li> </ul> </li> </ul> <hr> <h2>9. Windows 虚拟内存管理 (概述)</h2> <p><em>(注: 以下内容可能为对 Windows (可能较早版本如 NT/XP/7) 的描述) , 不重要</em></p> <h3>9.1 Intel x86 虚拟内存机制回顾</h3> <ul> <li><strong>保护模式寻址:</strong> 使用 <strong>段选择符 (Segment Selector)</strong> + <strong>偏移量 (Offset)</strong> 形成逻辑地址。段选择符指向 <strong>段描述符 (Segment Descriptor)</strong> (在 GDT/LDT 中)，包含段基址、限长、权限等。逻辑地址 -> <strong>线性地址 (Linear Address)</strong>。</li> <li><strong>分页机制:</strong> 如果 CR0 寄存器的 PG 位开启，线性地址会被页式机制进一步转换为 <strong>物理地址 (Physical Address)</strong>。</li> <li><strong>绕过分段:</strong> 可以设置段描述符使段基址为 0，限长为 4GB，从而让线性地址等于逻辑地址的偏移量部分，达到“平坦内存模型”的效果。</li> <li><strong>页表结构:</strong> x86 支持多级页表 (早期 2 级，x86-64 支持 4 级)。CR3 寄存器指向最高级页表的物理基地址。PTE/PDE 结构包含 PFN, P, A, D, R/W, U/S, PCD, PWT 等位。</li> </ul> <h3>9.2 Windows 内存管理器 (Memory Manager)</h3> <ul> <li><strong>位置:</strong> 位于内核执行体 (<code>Ntoskrnl.exe</code>) 中。</li> <li><strong>主要组成:</strong> <ul> <li><strong>执行体系统服务:</strong> 提供 API (<code>VirtualAlloc</code>, <code>MapViewOfFile</code>, <code>HeapAlloc</code> 等) 用于虚存分配、回收和管理。</li> <li><strong>页面错误陷阱处理程序 (<code>MmAccessFault</code>):</strong> 处理 MMU 检测到的内存管理异常 (缺页、权限错误)。</li> <li><strong>后台线程 (关键组件):</strong> <ul> <li><strong>工作集管理器 (<code>MmWorkingSetManager</code>):</strong> 负责调整进程工作集大小 (修整) 、老化页面、启动脏页写出等。</li> <li><strong>进程/栈交换器 (<code>KeSwapProcessOrStack</code>):</strong> 负责整个进程或内核线程栈的换入换出 (用于挂起/恢复进程)。</li> <li><strong>修改页面写出器 (<code>MiModifiedPageWriter</code>):</strong> 将“脏”的匿名页面 (来自页文件) 写回到页文件。</li> <li><strong>映射页面写出器 (<code>MiMappedPageWriter</code>):</strong> 将内存映射文件中的“脏”页写回磁盘文件。</li> <li><strong>零页线程 (<code>MmZeroPageThread</code>):</strong> 将空闲页框清零，为按需零页 (Demand-Zero) 提供准备好的页面。</li> </ul> </li> </ul> </li> </ul> <h3>9.3 Windows 地址空间布局 (32-bit 示例)</h3> <ul> <li><strong>总览:</strong> 4GB 虚拟地址空间。</li> <li><strong>用户空间 (通常 0x00000000 - 0x7FFFFFFF, 2GB):</strong> <ul> <li>应用程序代码 (EXE)</li> <li>动态链接库 (DLL) 代码和数据</li> <li>进程堆 (Heap)</li> <li>线程栈 (Stack)</li> <li>进程环境块 (PEB), 线程环境块 (TEB)</li> <li>内存映射文件区域</li> </ul> </li> <li><strong>系统空间 (通常 0x80000000 - 0xFFFFFFFF, 2GB):</strong> <ul> <li>内核代码 (<code>Ntoskrnl.exe</code>), HAL (<code>hal.dll</code>), 内核驱动</li> <li>页表本身 (自映射区域)</li> <li>系统缓存 (File Cache)</li> <li>分页缓冲池 (Paged Pool): 可被换出的内核内存</li> <li>非分页缓冲池 (Non-Paged Pool): 不能被换出的内核内存 (用于中断处理等)</li> <li>超空间 (Hyperspace): 临时映射进程页表等</li> </ul> </li> <li><strong>/3GB 启动选项:</strong> 可以修改用户/系统空间划分为 3GB/1GB，让用户进程获得更大地址空间。</li> <li><strong>自映射机制:</strong> Windows 将当前进程的 <strong>页目录</strong> 和 <strong>所有页表</strong> 映射到系统空间的一个固定虚拟地址范围 (如 0xC0000000 开始)，使得内核可以通过虚拟地址方便地访问任何进程的 PTE/PDE，而无需切换 CR3 寄存器。 <ul> <li><code>MiGetPdeAddress(va)</code> 和 <code>MiGetPteAddress(va)</code> 宏利用此机制快速计算给定虚拟地址 <code>va</code> 对应的 PDE 和 PTE 的 <strong>虚拟地址</strong>。</li> </ul> </li> </ul> <h3>9.4 Windows 缺页处理</h3> <ul> <li><strong>流程:</strong> <ol> <li>CPU 访问无效 PTE 地址，触发 0xE 号中断 (Page Fault)。</li> <li>CPU 将出错的虚拟地址存入 CR2 寄存器。</li> <li>CPU 跳转到内核的缺页中断处理例程 <code>KiTrap0E</code>。</li> <li><code>KiTrap0E</code> 调用核心处理函数 <code>MmAccessFault</code>。</li> <li><code>MmAccessFault</code> 读取 CR2，找到对应的 PTE。</li> <li><strong>分析 PTE 内容 (即使 P=0，其他位仍有 OS 定义的含义):</strong> <ul> <li>页面从未被提交 (Committed): 可能是非法访问。</li> <li>访问违反权限 (Protection Violation): 如写入只读页。</li> <li>写时复制 (Copy-on-Write): 执行 COW 操作。</li> <li>栈扩展 (Stack Expansion): 自动分配并映射新的栈页面。</li> <li>页面在转换状态 (Transition): 页面正在被 I/O (读入/写出) ，需等待 I/O 完成。</li> <li>页面在页文件/映射文件中 (Paged Out): 需要从磁盘调入。</li> <li>请求零页面 (Demand Zero): 分配一个已清零的物理页框。</li> </ul> </li> <li><strong>执行相应操作:</strong> 分配页框、启动磁盘 I/O、修改 PTE、完成 COW 等。</li> <li>返回用户模式，重新执行指令。</li> </ol> </li> </ul> <h3>9.5 Windows 工作集 (Working Set)</h3> <ul> <li><strong>定义:</strong> 进程当前驻留在物理内存中的虚拟页面集合 (即驻留集)。</li> <li><strong>类型:</strong> <ul> <li><strong>进程工作集:</strong> 每个进程私有的。</li> <li><strong>系统工作集:</strong> 内核自身代码和数据 (可分页部分) 所占用的。</li> </ul> </li> <li><strong>管理:</strong> <ul> <li><strong>动态调整:</strong> 工作集大小是动态变化的，有最小值和最大值限制。</li> <li><strong>工作集修整 (Trimming):</strong> 当系统物理内存紧张时，<strong>工作集管理器</strong> 会减少某些进程的工作集大小 (通常使用 Clock 类似算法移除“最老”的页面) ，将移除的页面放入 Standby 或 Modified 链表。</li> <li><strong>自动增长:</strong> 进程发生缺页时，如果其工作集大小未达到最大值，且系统有空闲内存，则调入页面会使其工作集增长。</li> </ul> </li> </ul> <h3>9.6 用户空间内存分配方式</h3> <ol> <li><strong>以页为单位的虚拟内存分配 (<code>VirtualAlloc</code>, <code>VirtualFree</code>):</strong> <ul> <li><strong>两阶段:</strong> <ul> <li><strong>保留 (Reserve):</strong> 在进程虚拟地址空间预留一段范围，不分配物理内存或页文件空间。只是标记地址范围不可用。</li> <li><strong>提交 (Commit):</strong> 为保留的地址空间实际分配物理内存 (或页文件支持) 。页面首次访问时才会真正调入物理内存 (Demand Zero 或从页文件加载) 。</li> </ul> </li> <li><strong>虚拟地址描述符 (VAD - Virtual Address Descriptor):</strong> 内核为每个进程维护一棵 <strong>自平衡二叉树 (VAD Tree)</strong>，每个节点描述一段连续的、属性相同的虚拟地址空间 (已保留或已提交) 。用于快速查找、分配、释放虚拟地址范围。<code>EPROCESS</code> 结构包含指向 VAD 树根的指针。</li> </ul> </li> <li><strong>内存映射文件 (<code>CreateFileMapping</code>, <code>MapViewOfFile</code>):</strong> <ul> <li>使用 <strong>区域对象 (Section Object)</strong> (Win32 API 称之为 File Mapping Object) 实现。</li> <li><code>CreateFileMapping</code> 创建一个区域对象，可以基于磁盘文件或页文件 (用于匿名共享内存) 。</li> <li><code>MapViewOfFile</code> 将区域对象的一部分或全部映射到进程的虚拟地址空间，得到一个 <strong>视图 (View)</strong>。</li> <li>通过映射同一区域对象，实现进程间共享内存或文件访问。</li> </ul> </li> <li><strong>内存堆 (Heap) (<code>HeapCreate</code>, <code>HeapAlloc</code>, <code>HeapFree</code>):</strong> <ul> <li><strong>用途:</strong> 管理 <strong>大量、小块</strong> 的内存分配。</li> <li><strong>机制:</strong> 进程首先用 <code>VirtualAlloc</code> (通常在进程启动时由系统自动完成，创建默认堆) 分配一大块虚拟内存作为堆区域。然后，<strong>堆管理器</strong> (用户模式库或内核函数集) 在这个区域内进一步细分和管理小块内存的分配与释放。</li> <li><strong>类型:</strong> 每个进程有一个 <strong>默认进程堆</strong> (<code>GetProcessHeap</code>)。也可以创建额外的 <strong>私有堆</strong> (<code>HeapCreate</code>)。</li> </ul> </li> </ol> <h3>9.7 Windows 物理内存管理</h3> <ul> <li><strong>页框号数据库 (PFN Database):</strong> 一个 <strong>全局数组</strong> (<code>MmPfnDatabase</code>)，数组的每个元素是一个 <code>MMPFN</code> 结构，对应一个物理内存页框。</li> <li><strong><code>MMPFN</code> 结构:</strong> 包含该物理页框的所有状态信息，如： <ul> <li><strong>状态 (State):</strong> Active, Standby, Modified, Transition, Free, Zeroed, Bad。</li> <li><strong>链接指针:</strong> 用于将处于相同状态的页框链接起来 (形成链表) 。</li> <li>指向 PTE 的指针 (如果页面是 Active/Standby/Modified)。</li> <li>引用计数。</li> <li>等等。</li> </ul> </li> <li><strong>页框状态与链表:</strong> <ul> <li><strong>Active/Valid:</strong> 页面在某个工作集中，PTE有效。</li> <li><strong>Transition:</strong> 页面正在进行 I/O。</li> <li><strong>Standby:</strong> 页面刚被从工作集移除，内容 <strong>干净</strong>，PTE 无效但指向此 PFN。可被快速重用 (Soft Fault)。</li> <li><strong>Modified:</strong> 页面刚被从工作集移除，内容 <strong>脏</strong>，PTE 无效但指向此 PFN。重用前需写回磁盘。</li> <li><strong>Free:</strong> 页框空闲，内容无效。</li> <li><strong>Zeroed:</strong> 页框空闲，且已清零。可立即用于 Demand Zero 页。</li> <li><strong>Bad:</strong> 页框硬件损坏，不可用。</li> <li><strong>链表:</strong> 内核维护 <code>FreePageList</code>, <code>ZeroedPageList</code>, <code>StandbyPageList</code>, <code>ModifiedPageList</code> 等链表，通过 <code>MMPFN</code> 中的指针将对应状态的页框链接起来，方便快速查找和管理。</li> </ul> </li> <li><strong>状态转换图 (示意):</strong> 页面在不同链表和工作集之间根据缺页、写回、清零、置换等操作进行转换。</li> </ul> <hr> <h2>10. 重点小结</h2> <ul> <li><strong>核心概念:</strong> 虚拟内存是对物理内存的抽象，提供更大、受保护的地址空间。通过页表和 MMU 实现虚拟到物理地址的转换。</li> <li><strong>关键机制:</strong> <ul> <li><strong>分页 (Paging):</strong> 将地址空间划分为固定大小的页/页框。</li> <li><strong>页表 (Page Table):</strong> 存储 VPN 到 PFN 的映射及状态位 (P, A, D, Protection)。</li> <li><strong>多级页表/反转页表:</strong> 解决页表过大问题。</li> <li><strong>TLB (快表):</strong> 加速地址转换。</li> <li><strong>缺页异常 (Page Fault):</strong> 处理页面不在内存的情况，实现按需调页。</li> </ul> </li> <li><strong>重要策略:</strong> <ul> <li><strong>置换策略 (Replacement):</strong> FIFO, LRU, Clock, Working Set 等，决定牺牲哪个页面。</li> <li><strong>驻留集管理:</strong> 控制进程占用多少物理内存 (Fixed vs. Variable, Working Set)。</li> <li><strong>清除策略 (Cleaning):</strong> 提前写回脏页，保持空闲页框干净。</li> <li><strong>加载控制:</strong> 防止 Thrashing。</li> </ul> </li> <li><strong>高级特性:</strong> <ul> <li><strong>内存映射文件 (mmap):</strong> 高效文件 I/O 和 IPC 机制。</li> <li><strong>写时复制 (COW):</strong> 优化 <code>fork()</code> 和私有映射。</li> </ul> </li> <li><strong>Windows 特点:</strong> VAD 树管理虚拟地址空间，PFN 数据库管理物理页框，多种页面状态链表，工作集模型，多种内存分配 API。</li> </ul>https://www.lyt0112.com/blog/operating_systems_note_05-zhhttps://www.lyt0112.com/blog/operating_systems_note_05-zhOperating Systems Notes 05: 内存管理概述Fri, 28 Mar 2025 16:14:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gemini-2.5-pro-preview-03-25</code></p> <p>This article uses LLM to improve efficiency, which can make mistakes. I have tried my best to check and proofread, but still cannot guarantee complete accuracy.</p> <p>For personal use, may be nagging for you.</p> <h2>1. 重要概念</h2> <h3>1.1 存储体系 (Memory Hierarchy)</h3> <p>计算机存储器按照速度、容量和成本排列成层次结构。</p> <ul> <li><strong>寄存器 (Registers):</strong> 最快，容量最小，成本最高，直接由 CPU 访问。</li> <li><strong>高速缓存 (Cache - L1, L2, L3):</strong> 速度快，容量较小，成本高，用于缓解 CPU 和主存之间的速度差异。</li> <li><strong>内存 (Main Memory / RAM):</strong> 速度、容量和成本居中，是程序运行时代码和数据的主要存储区域。</li> <li><strong>本地磁盘 (Local Disk / Secondary Storage):</strong> 速度慢，容量大，成本低，用于持久化存储，如硬盘 (HDD)、固态硬盘 (SSD)。</li> <li><strong>远程磁盘 (Remote Storage):</strong> 通过网络访问，速度最慢，容量可以很大。</li> </ul> <p><strong>内存管理主要关注的是主存 (内存) 的管理。</strong></p> <h3>1.2 地址空间 (Address Space)</h3> <ul> <li><strong>定义:</strong> 操作系统为每个进程分配的一个独立的逻辑地址范围。进程所能“看到”和访问的地址集合。</li> <li><strong>独立性:</strong> 每个进程拥有自己独立的地址空间，一个进程默认不能访问另一个进程的地址空间，这是实现<strong>存储保护</strong>的基础。</li> <li><strong>管理:</strong> 操作系统需要管理地址空间的分配 (放置 placement) 、回收、分割与合并。</li> </ul> <h3>1.3 逻辑地址 vs 物理地址</h3> <ul> <li><strong>逻辑地址 (Logical Address):</strong> <ul> <li>也称为<strong>相对地址 (Relative Address)</strong> 或 <strong>虚拟地址 (Virtual Address)</strong>。</li> <li>是用户程序 (或 CPU 发出) 使用的地址。</li> <li>通常从 0 开始编址，地址是相对于进程自身的地址空间。</li> <li>编译、汇编后生成的目标代码通常使用逻辑地址。</li> <li><strong>不能</strong>直接用于在物理内存中寻址。</li> </ul> </li> <li><strong>物理地址 (Physical Address):</strong> <ul> <li>也称为<strong>绝对地址 (Absolute Address)</strong> 或 <strong>实地址 (Real Address)</strong>。</li> <li>是内存存储单元的实际地址，硬件内存总线可以直接访问。</li> </ul> </li> </ul> <h3>1.4 地址重定位 (Address Relocation)</h3> <ul> <li><strong>定义:</strong> 将用户程序中的<strong>逻辑地址</strong>转换为运行时可由机器直接寻址的<strong>物理地址</strong>的过程。</li> <li><strong>别名:</strong> 也常被称为<strong>地址转换 (Address Translation)</strong>、<strong>地址变换 (Address Transformation)</strong> 或 <strong>地址映射 (Address Mapping)</strong>。这些术语基本同义，都指代从逻辑地址到物理地址的转换过程。</li> <li><strong>目的:</strong> 保证 CPU 执行指令时能够正确访问到物理内存单元。</li> <li><strong>为什么需要?</strong> <ul> <li>多道程序环境下，内存中有多个进程。</li> <li>程序加载到内存的位置通常在运行时才能确定，无法在编译时预知其物理地址。</li> </ul> </li> <li><strong>地址绑定时机 (Binding Time):</strong> 指令和数据绑定到内存地址的时间点： <ul> <li><strong>编译时 (Compile Time):</strong> 如果编译时就知道程序将驻留在内存的哪个位置，编译器可以直接生成绝对代码。但如果加载位置改变，程序就必须重新编译。很少用。</li> <li><strong>加载时 (Load Time):</strong> 如果编译时不知道加载位置，编译器生成<strong>可重定位代码 (Relocatable Code)</strong>。加载器 (Loader) 在将程序加载到内存时，根据实际加载的起始地址，一次性地将所有逻辑地址转换为物理地址。这称为<strong>静态地址重定位</strong>。</li> <li><strong>运行时 (Run Time):</strong> 地址转换延迟到程序运行时才进行。CPU 每次访问内存 (取指或访存) 时，都会将逻辑地址转换为物理地址。这需要硬件支持 (如 MMU) ，称为<strong>动态地址重定位</strong>。现代操作系统普遍采用此方式，因为它提供了最大的灵活性 (如进程可以在内存中移动) 。</li> </ul> </li> </ul> <h4>静态地址重定位 (Static Relocation)</h4> <ul> <li><strong>过程:</strong> 在程序被加载进内存时，由加载器一次性完成逻辑地址到物理地址的转换。</li> <li><strong>实现:</strong> 通常由软件 (加载器) 完成。</li> <li><strong>示例:</strong> <pre><code>// 源代码 // 目标代码 (逻辑地址) // 装载模块 (磁盘, 逻辑) // 装载模块 (内存, 物理 @ 1000) i = ...; store 20; store 120; store 1120; f(); branch f; branch 100; branch 1100; // 假设 f 在 100 ... ... ... ... f: ... f: ... f: ... (在 100) f: ... (在 1100) </code></pre> </li> <li><strong>缺点:</strong> 程序加载后不能在内存中移动；不灵活。</li> </ul> <h4>动态地址重定位 (Dynamic Relocation)</h4> <ul> <li><strong>过程:</strong> 在进程执行过程中，每次访问内存地址时进行转换。</li> <li><strong>实现:</strong> 需要硬件支持，通常是 <strong>内存管理单元 (MMU - Memory Management Unit)</strong>。 <ul> <li><strong>MMU:</strong> 一个硬件设备，负责将 CPU 发出的逻辑地址实时转换为物理地址。</li> <li><strong>实现方式 (简单示例):</strong> 使用<strong>基址寄存器 (Base Register)</strong> 和<strong>重定位寄存器 (Relocation Register)</strong>。逻辑地址加上重定位寄存器的值得到物理地址。</li> </ul> </li> <li><strong>优点:</strong> 进程可以在内存中移动 (例如，为了内存紧凑) ；支持更高级的内存管理技术 (如虚拟内存) 。</li> </ul> <h3>1.5 存储保护 (Memory Protection)</h3> <ul> <li><strong>目的:</strong> <ul> <li>确保每个进程有自己独立的地址空间，防止一个进程访问或修改另一个进程的数据。</li> <li>防止进程访问其不应访问的内存区域 (如操作系统的核心代码) 。</li> <li>防止进程执行不适当的操作 (如写入只读代码段) 。</li> </ul> </li> <li><strong>实现 (基于基址/界限寄存器):</strong> <ul> <li><strong>基地址寄存器 (Base Register):</strong> 存放进程在物理内存中的起始地址。</li> <li><strong>界限寄存器 (Limit Register):</strong> 存放进程的逻辑地址空间的大小 (或最大合法逻辑地址) 。</li> <li><strong>检查过程:</strong> CPU 产生的每个逻辑地址 <code>addr</code> 必须满足 <code>0 &#x3C;= addr &#x3C; Limit Register</code>。转换后的物理地址 <code>Base Register + addr</code> 也必须在分配给该进程的物理内存范围内 (有时 limit check 可以直接在物理地址上做，<code>Base &#x3C;= Physical Address &#x3C; Base + Limit</code>)。</li> <li><strong>加载:</strong> 基址和界限寄存器的值由操作系统通过<strong>特权指令 (Privileged Instructions)</strong> 加载，用户程序无法修改。</li> </ul> </li> <li><strong>其他机制:</strong> 页表/段表中的保护位 (读/写/执行权限) 。</li> </ul> <h3>1.6 存储共享 (Memory Sharing)</h3> <p>允许多个进程安全地共享同一段物理内存区域。例如，共享库 (如 C 库) 的代码段通常可以在多个进程间共享，只需在物理内存中保留一份副本，节省内存。实现通常依赖于分页或分段机制。</p> <h3>1.7 局部性原理 (Principle of Locality)</h3> <p>程序在执行过程中的一个普遍倾向：</p> <ul> <li><strong>时间局部性 (Temporal Locality):</strong> 如果一个内存位置被访问，那么它在不久的将来很可能再次被访问 (如循环中的指令、变量) 。</li> <li><strong>空间局部性 (Spatial Locality):</strong> 如果一个内存位置被访问，那么它附近的内存位置也很可能在不久的将来被访问 (如顺序执行的代码、数组元素) 。</li> </ul> <p><strong>意义:</strong> 存储体系 (特别是 Cache) 和虚拟内存管理 (如页面置换算法) 都依赖局部性原理来提高性能。</p> <hr> <h2>2. 内存管理的目标与功能</h2> <ul> <li><strong>目标:</strong> 有效、安全地管理计算机主存资源，提升系统性能和易用性。主要追求： <ul> <li><strong>透明性 (Transparency):</strong> 内存管理对用户程序应该是透明的，程序员不需要关心物理内存的细节。</li> <li><strong>效率 (Efficiency):</strong> 最小化内存访问时间，高效利用内存资源 (减少浪费) ，降低管理开销。</li> <li><strong>保护 (Protection):</strong> 确保进程间地址空间隔离，保护操作系统自身。</li> </ul> </li> <li><strong>基本功能:</strong> <ul> <li><strong>内存分配与回收:</strong> 为进程按需分配内存空间，并在进程结束或不再需要时回收。管理空闲内存。</li> <li><strong>地址映射/转换:</strong> 实现逻辑地址到物理地址的转换。</li> <li><strong>内存保护:</strong> 提供机制防止非法内存访问。</li> <li><strong>内存共享:</strong> 支持多个进程共享部分内存区域。</li> <li><strong>内存扩充:</strong> 通过覆盖、交换、虚拟内存等技术，在有限的物理内存上运行更大的程序或更多的进程。</li> </ul> </li> </ul> <p><strong>多道程序设计对内存管理提出的挑战:</strong></p> <ul> <li>多个进程同时在内存中，需要管理它们各自的空间。</li> <li>需要支持地址重定位 (程序加载位置不确定) 。</li> <li>需要支持地址保护 (进程间隔离) 。</li> </ul> <hr> <h2>3. 进程地址空间</h2> <h3>3.1 地址空间布局 (典型 Linux 布局)</h3> <p>进程的逻辑地址空间通常划分为几个标准段：</p> <pre><code> 高地址 0xFFFFFFFF +-----------------------+ | 内核地址空间 (Kernel) | --> 供操作系统使用，用户模式不可访问 0xC0000000 +-----------------------+ | 用户栈 (Stack) | --> 函数调用、局部变量 (向下增长) | | ----------------------- | | | | 内存映射区域 | --> 共享库、内存映射文件 | | (Memory Mapped Region) | | | | ----------------------- | | 堆 (Heap) | --> 动态内存分配 (malloc, new) (向上增长) | | ----------------------- | | BSS 段 (Uninit. Data) | --> 未初始化全局/静态变量 | | ----------------------- | | 数据段 (Data Segment) | --> 已初始化全局/静态变量 | | 0x08048000 | ----------------------- | | 代码段 (Text Segment) | --> 程序指令 (只读) | 低地址 0x00000000 +-----------------------+ </code></pre> <ul> <li><strong>加载来源:</strong> 代码段、数据段、BSS 段通常从可执行文件中加载。栈和堆是在运行时动态创建和增长的。共享库在运行时动态链接和映射。</li> <li><strong>PC (Program Counter):</strong> 指向当前执行的指令 (在代码段内) 。</li> <li><strong>SP (Stack Pointer):</strong> 指向栈顶。</li> </ul> <h3>3.2 XV6 示例 (地址空间)</h3> <p>XV6 是一个教学用的简单操作系统，其地址空间布局相对简单：</p> <ul> <li>地址从低到高依次为： <ul> <li><strong>代码 (text):</strong> 程序指令。</li> <li><strong>数据 (data) &#x26; BSS:</strong> 初始化和未初始化的全局/静态变量。</li> <li><strong>栈 (stack):</strong> 函数调用栈。</li> <li><strong>堆 (heap):</strong> 动态分配区域。</li> </ul> </li> <li>高地址处有 <strong>Trampoline</strong> 和 <strong>Trapframe</strong> 区域，用于用户态和内核态之间的切换，并且在两种模式下都映射。(<code>kernel/memlayout.h</code> 中定义)。</li> </ul> <h3>3.3 相关概念解释 (常用于虚拟内存)</h3> <ul> <li><strong>活跃页面 (Active Page):</strong> 指当前正在被进程频繁访问的页面。</li> <li><strong>工作集 (Working Set):</strong> 一个进程在最近一段时间 <code>Δ</code> 内所访问到的页面集合。这是衡量进程当前运行所需内存大小的一个动态指标，反映了程序的局部性。如果一个进程的工作集能完全驻留在内存中，那么它就能高效运行，很少发生缺页中断。</li> <li><strong>常驻集 (Resident Set):</strong> 指一个进程当前时刻实际驻留在物理内存中的页面集合。常驻集的大小受操作系统分配策略的影响。理想情况下，常驻集应该包含进程的工作集。</li> </ul> <hr> <h2>4. 物理内存管理 (空闲空间管理)</h2> <p>操作系统需要跟踪哪些物理内存是空闲的，哪些已被分配。</p> <h3>4.1 管理数据结构</h3> <ul> <li> <p><strong>位图 (Bitmap / Bit Vector):</strong></p> <ul> <li>将物理内存划分为固定大小的<strong>分配单元</strong> (通常大小等于页框或几倍页框大小) 。</li> <li>位图中的每一位对应一个分配单元。</li> <li>位的值表示单元状态：<code>0</code> 表示空闲，<code>1</code> 表示已分配 (或相反) 。</li> <li><strong>优点:</strong> 简单，易于快速找到连续的空闲块。</li> <li><strong>缺点:</strong> 位图本身需要占用内存空间 (空间开销与内存总量成正比) 。查找指定大小的空闲块可能需要扫描整个位图。</li> </ul> </li> <li> <p><strong>空闲区表/链表 (Free List):</strong></p> <ul> <li>维护一个包含所有空闲内存块 (区) 信息的数据结构。</li> <li>每个节点/表项记录一个空闲区的<strong>起始地址 (Start Address)</strong> 和 <strong>长度 (Length)</strong>。</li> <li>可以组织成<strong>表 (Array)</strong> 或<strong>链表 (Linked List)</strong>。</li> <li><strong>链表类型:</strong> <ul> <li><strong>隐式空闲链表 (Implicit Free List):</strong> 空闲块和已分配块都存储在内存中，通过块头部信息 (大小、是否空闲) 来遍历。分配和回收时需要查找。</li> <li><strong>显式空闲链表 (Explicit Free List):</strong> 只将<strong>空闲块</strong>链接起来。头部包含指向下一个 (有时还有上一个) 空闲块的指针。查找空闲块更快，但维护链表指针有开销。</li> <li><strong>分离空闲链表 (Segregated Free List):</strong> 维护多个空闲链表，每个链表负责特定大小范围的空闲块。分配时，根据请求大小直接去对应链表查找。可以加快分配速度，减少碎片。伙伴系统和 SLAB 分配器属于此类。</li> </ul> </li> <li><strong>优点:</strong> 空间开销只与空闲块数量有关，不一定与内存总量成正比 (对于大块空闲区更有效) 。</li> <li><strong>缺点:</strong> 分配和回收时可能需要遍历链表/表，查找合适空闲块。可能会产生外部碎片。</li> </ul> </li> </ul> <h3>4.2 衡量指标</h3> <ul> <li><strong>内存资源利用率:</strong> 目标是减少浪费。 <ul> <li><strong>内碎片 (Internal Fragmentation):</strong> 分配给进程的内存块<strong>大于</strong>进程实际请求的大小，块<strong>内部</strong>未被使用的部分。常见于固定分区、页式管理和固定大小分配策略 (如伙伴系统分配的块可能大于请求) 。</li> <li><strong>外碎片 (External Fragmentation):</strong> 内存中存在<strong>足够多</strong>的空闲空间总和来满足一个请求，但这些空间<strong>不连续</strong>，而是散布在已分配块之间的小块。导致无法分配较大的连续内存块。常见于可变分区、段式管理。</li> </ul> </li> <li><strong>性能:</strong> 分配和回收内存操作的速度，以及这些操作占用的 CPU 时间。</li> </ul> <h3>4.3 内存分配算法 (针对空闲区表/链表)</h3> <p>当需要为进程分配长度为 <code>s</code> 的内存时，如何在空闲区列表中选择一个合适的空闲块？</p> <ul> <li><strong>首次适配 (First Fit):</strong> 从链表/表的开头开始查找，选择<strong>第一个</strong>找到的大小 <code>>= s</code> 的空闲块。 <ul> <li><strong>优点:</strong> 算法简单，速度较快。倾向于在低地址区域留下碎片。</li> <li><strong>缺点:</strong> 可能产生较多的小碎片，且每次查找都从头开始。</li> </ul> </li> <li><strong>下次适配 (Next Fit):</strong> 从<strong>上次</strong>分配操作结束的位置开始查找，选择第一个找到的大小 <code>>= s</code> 的空闲块。 <ul> <li><strong>优点:</strong> 避免了每次都从头查找，空闲块的使用更均匀分布。</li> <li><strong>缺点:</strong> 可能导致大的空闲块很快被分割完。</li> </ul> </li> <li><strong>最佳适配 (Best Fit):</strong> 遍历<strong>整个</strong>空闲链表/表，找到大小 <code>>= s</code> 且<strong>最小</strong>的那个空闲块 (即差值 <code>size - s</code> 最小) 。 <ul> <li><strong>优点:</strong> 试图留下最大的可用空闲块，减少大碎片的产生。</li> <li><strong>缺点:</strong> 速度最慢 (需要全表扫描) ，容易产生大量非常小而难以利用的碎片。</li> </ul> </li> <li><strong>最差适配 (Worst Fit):</strong> 遍历<strong>整个</strong>空闲链表/表，找到大小 <code>>= s</code> 且<strong>最大</strong>的那个空闲块。 <ul> <li><strong>优点:</strong> 试图将剩余部分保持为较大的可用块，避免产生过多小碎片。</li> <li><strong>缺点:</strong> 速度慢 (需要全表扫描) ，可能导致大的空闲块很快被消耗掉，无法满足后续对大内存的需求。</li> </ul> </li> </ul> <p><strong>分配过程:</strong> 选定一个空闲块后，如果其大小 <code>Size</code> 远大于请求大小 <code>s</code>，通常会将其<strong>分割</strong>为两部分：一部分 (大小为 <code>s</code>) 分配给进程，另一部分 (大小为 <code>Size - s</code>) 变回一个新的、更小的空闲块。</p> <p><strong>示例:</strong> 假设空闲区为 [15K, 23K], [48K, 20K], [80K, 30K]。进程 P5 请求 5K，进程 P6 请求 13K。</p> <ul> <li><strong>First Fit:</strong> P5 分配到 [15K, 5K]，剩余 [20K, 18K]。P6 分配到 [20K, 13K]，剩余 [33K, 5K]。空闲区变为 [33K, 5K], [48K, 20K], [80K, 30K]。</li> <li><strong>Best Fit:</strong> P5 分配到 [48K, 5K]，剩余 [53K, 15K]。P6 分配到 [53K, 13K]，剩余 [66K, 2K]。空闲区变为 [15K, 23K], [66K, 2K], [80K, 30K]。</li> <li><strong>Worst Fit:</strong> P5 分配到 [80K, 5K]，剩余 [85K, 25K]。P6 分配到 [85K, 13K]，剩余 [98K, 12K]。空闲区变为 [15K, 23K], [48K, 20K], [98K, 12K]。</li> </ul> <h3>4.4 内存回收 (针对空闲区表/链表)</h3> <p>当一个进程释放内存块时，需要将其归还给空闲列表。</p> <ul> <li><strong>合并 (Coalescing):</strong> 为了减少碎片，回收时需要检查该块是否与物理上相邻的空闲块接壤。 <ul> <li><strong>上相邻:</strong> 与前面的空闲块合并。</li> <li><strong>下相邻:</strong> 与后面的空闲块合并。</li> <li><strong>上下都相邻:</strong> 与前后两个空闲块合并成一个大空闲块。</li> <li><strong>上下都不相邻:</strong> 直接将回收块作为一个新的独立空闲块添加到链表/表中。</li> </ul> </li> <li><strong>更新数据结构:</strong> 相应地修改空闲区表/链表。</li> </ul> <h3>4.5 特定分配策略</h3> <h4>伙伴系统 (Buddy System)</h4> <ul> <li><strong>思想:</strong> 一种<strong>特殊的“分离适配”算法</strong>，用于管理大小为 2 的幂次的内存块。Linux 内核底层内存管理曾采用 (现在也部分采用) 。</li> <li><strong>结构:</strong> 将整个可用内存 (假设大小为 2U) 看作一个块。维护 <code>U+1</code> 个空闲链表，分别管理大小为 20, 21, ..., 2U 的空闲块。</li> <li><strong>分配过程 (请求大小为 <code>s</code>):</strong> <ol> <li>计算满足需求的最小 2 的幂次 <code>k</code>，使得 2k-1 &#x3C; <code>s</code> ≤ 2k。</li> <li>查找大小为 2k 的空闲链表。</li> <li>如果找到，分配该块。</li> <li>如果没找到，则查找更大的块 (2k+1)。找到后，将其<strong>分裂 (Split)</strong> 成两个大小相等的<strong>伙伴 (Buddies)</strong> (均为 2k)。一个用于分配，另一个放入 2k 的空闲链表。</li> <li>如果 2k+1 也没有，继续向上查找并递归分裂，直到找到可分配的块。</li> </ol> </li> <li><strong>回收过程 (释放大小为 2k 的块 <code>B</code>):</strong> <ol> <li>查找块 <code>B</code> 的<strong>伙伴</strong> <code>B'</code> (地址可以通过异或运算计算得到)。</li> <li>检查伙伴 <code>B'</code> 是否也空闲且大小相同 (2k)。</li> <li>如果<strong>是</strong>，则将 <code>B</code> 和 <code>B'</code> <strong>合并 (Merge)</strong> 成一个更大的块 (2k+1)，并递归尝试与新块的伙伴合并。</li> <li>如果<strong>否</strong>，则将 <code>B</code> 加入 2k 的空闲链表。</li> </ol> </li> <li><strong>优点:</strong> 分裂和合并相对高效 (伙伴地址计算快) ，能较好地控制外部碎片 (合并机制) 。</li> <li><strong>缺点:</strong> 存在<strong>内碎片</strong> (分配的块大小必须是 2 的幂，可能大于实际需求) 。</li> </ul> <p><strong>伙伴系统示例 (1MB 内存):</strong></p> <ol> <li><strong>初始:</strong> Free list for 1M: [Block 1M]</li> <li><strong>A 申请 100K:</strong> 需要 128K (27)。分裂 1M -> 512K + 512K; 分裂 512K -> 256K + 256K; 分裂 256K -> 128K + 128K。分配一个 128K 给 A。 <ul> <li>Memory: [A=128K][Free 128K][Free 256K][Free 512K]</li> <li>Free lists: 128K:[1 block], 256K:[1 block], 512K:[1 block]</li> </ul> </li> <li><strong>B 申请 240K:</strong> 需要 256K (28)。分配链表中的 256K 给 B。 <ul> <li>Memory: [A=128K][Free 128K][B=256K][Free 512K]</li> <li>Free lists: 128K:[1 block], 512K:[1 block]</li> </ul> </li> <li><strong>C 申请 64K:</strong> 需要 64K (26)。分裂 128K -> 64K + 64K。分配一个 64K 给 C。 <ul> <li>Memory: [A=128K][C=64K][Free 64K][B=256K][Free 512K]</li> <li>Free lists: 64K:[1 block], 512K:[1 block]</li> </ul> </li> <li><strong>D 申请 256K:</strong> 需要 256K (28)。分裂 512K -> 256K + 256K。分配一个 256K 给 D。 <ul> <li>Memory: [A=128K][C=64K][Free 64K][B=256K][D=256K][Free 256K]</li> <li>Free lists: 64K:[1 block], 256K:[1 block]</li> </ul> </li> <li><strong>释放 B (256K):</strong> 它的伙伴 D=256K 未释放。将 B 加入 256K 链表。 <ul> <li>Memory: [A=128K][C=64K][Free 64K][Free 256K][D=256K][Free 256K]</li> <li>Free lists: 64K:[1 block], 256K:[2 blocks]</li> </ul> </li> <li><strong>释放 A (128K):</strong> 它的伙伴 C=64K+Free 64K 中的 Free 64K 是否是伙伴？需要看具体地址。假设 A 的伙伴是 [C=64K][Free 64K] 中的 Free 64K 之前的那个 128K 块，则 A 不能立即合并。将 A 加入 128K 链表。 (<em>原始图示似乎假设 A 的伙伴是 Free 128K，那释放 A 时应该合并成 256K</em>。我们按原始图示逻辑继续) <ul> <li>按图示：释放 A(128K) -> 与其伙伴(Free 128K)合并 -> 256K。</li> <li>Memory: [Free 256K][C=64K][Free 64K][B=256K][D=256K][Free 256K] (B 已经释放) -> [Free 256K][C=64K][Free 64K][Free 256K][D=256K][Free 256K]</li> <li>Free lists: 64K:[1 block], 256K:[3 blocks]</li> </ul> </li> <li><strong>E 申请 75K:</strong> 需要 128K。从 Free 256K 中分裂 -> 128K+128K。分配一个 128K 给 E。 <ul> <li>Memory: [E=128K][Free 128K][C=64K][Free 64K][Free 256K][D=256K][Free 256K]</li> <li>Free lists: 64K:[1 block], 128K:[1 block], 256K:[2 blocks]</li> </ul> </li> <li><strong>释放 C (64K):</strong> 伙伴是 Free 64K。合并 -> 128K。这个 128K 的伙伴是 E=128K (未释放)。将这个新 128K 加入链表。 <ul> <li>Memory: [E=128K][Free 128K][Free 128K][Free 256K][D=256K][Free 256K]</li> <li>Free lists: 128K:[2 blocks], 256K:[2 blocks]</li> </ul> </li> <li><strong>释放 E (128K):</strong> 伙伴是 Free 128K (来自 C 的合并)。合并 -> 256K。这个 256K 的伙伴是另一个 Free 128K (原始 A 分裂剩下的) ？地址决定。按图示，它与另一个 128K 合并成 256K，再与相邻的 Free 256K 合并成 512K。 <ul> <li>Memory: [Free 512K][Free 256K][D=256K][Free 256K]</li> <li>Free lists: 256K:[2 blocks], 512K:[1 block]</li> </ul> </li> <li><strong>释放 D (256K):</strong> 伙伴是 Free 256K。合并 -> 512K。这个 512K 的伙伴是 Free 512K。合并 -> 1M。 <ul> <li>Memory: [Free 1M]</li> <li>Free lists: 1M:[1 block]</li> </ul> </li> </ol> <h4>SLAB/SLUB/SLOB 分配器</h4> <ul> <li> <p><strong>目的:</strong> 高效管理内核中<strong>频繁分配和释放的小内存对象</strong> (如 inode、task_struct 等) 。伙伴系统分配的最小块可能仍太大，导致内碎片。</p> </li> <li> <p><strong>基本思想:</strong></p> <ul> <li>将伙伴系统分配的大块内存 (称为 "slab") 进一步细分成多个<strong>固定大小的小对象 (object)</strong>。</li> <li>为<strong>每种类型</strong>的对象维护一个或多个 slab 缓存 (cache)。</li> <li>分配对象时，从对应的 cache 中快速获取一个空闲对象。</li> <li>释放对象时，将其放回原 cache，通常无需立即归还给伙伴系统。</li> </ul> </li> <li> <p><strong>优点:</strong></p> <ul> <li>减少内碎片 (对象大小精确匹配) 。</li> <li>分配和释放速度快 (对象通常已初始化，且无需查找) 。</li> <li>利用缓存局部性 (对象在 L1/L2 cache 中可能仍然有效) 。</li> </ul> </li> <li> <p><strong>SLAB 分配器 (原始, Jeff Bonwick, Solaris -> Linux):</strong></p> <ul> <li>为每种对象类型维护一个 <code>kmem_cache</code>。</li> <li>每个 cache 包含多个 slab (通常是 1 或多个物理页)。</li> <li>Slab 内包含对象和元数据。</li> <li>Slab 分为：全满 (full)、部分空闲 (partial)、全空 (empty) 三种链表。分配优先从 partial slab 获取。</li> <li><strong>问题:</strong> 实现相对复杂，元数据管理开销较大，多核环境下锁竞争可能成为瓶颈。</li> </ul> </li> <li> <p><strong>SLUB 分配器 (改进, Pekka Enberg, Linux 2.6.22+):</strong></p> <ul> <li><strong>目标:</strong> 简化设计，提高性能和可伸缩性。是当前 Linux <strong>默认</strong>的分配器。</li> <li><strong>简化:</strong> 去除了复杂的 slab 链表管理，主要将 page (物理页) 作为 slab 进行管理。元数据存储开销更小。</li> <li><strong>性能:</strong> 减少锁竞争，对 NUMA (Non-Uniform Memory Access) 架构和多核系统优化更好 (利用 per-CPU 缓存) 。</li> </ul> </li> <li> <p><strong>SLOB 分配器 (简单):</strong></p> <ul> <li><strong>目标:</strong> 极简、紧凑，适用于代码大小和内存开销受限的<strong>嵌入式系统</strong>。</li> <li><strong>实现:</strong> 使用简单的首次适配算法在小的内存块 (slab) 内分配。不适合高性能、大内存系统。</li> </ul> </li> <li> <p><strong>查看 Slab 信息 (Linux):</strong></p> <pre><code class="language-bash">cat /proc/slabinfo # 或者使用 slabtop 工具 slabtop </code></pre> <p>(<code>slabinfo</code> 提供详细的 cache 列表，包括对象大小、活动对象数、总对象数、slab 数等信息。)</p> </li> </ul> <hr> <h2>5. 基本内存管理方案</h2> <p>不同的策略将进程的逻辑地址空间映射到物理内存。</p> <p>| 方案 | 加载单位 | 内存划分 | 碎片类型 | 地址转换 | 特点 | | ----------------------- | -------- | ------------------ | ------------------------- | -------------------------- | ---------------------------------------------- | | <strong>单一连续区</strong> | 进程 | 不划分 (除 OS 外) | 无 (低利用率) | 简单基址 (或固定地址) | 最简单，同一时间只有一个用户进程，内存利用率低 | | <strong>固定分区</strong> | 进程 | 预先固定大小的分区 | <strong>内碎片</strong> | 基址+界限寄存器 (每个分区) | 简单，允许多道程序，但分区大小固定不灵活 | | <strong>可变分区</strong> | 进程 | 动态按需划分 | <strong>外碎片</strong> | 基址+界限寄存器 (每个进程) | 按需分配，灵活，但产生外碎片，需要压缩技术 | | <strong>页式 (Paging)</strong> | 页 | 固定大小的页框 | <strong>内碎片</strong> (最后一页) | 页表 (MMU硬件查表) | 消除外碎片，分配管理简单，不要求连续，<strong>常用</strong> | | <strong>段式 (Segmentation)</strong> | 段 | 动态按需划分的段 | <strong>外碎片</strong> | 段表 (MMU硬件查表) | 符合程序逻辑，易于共享和保护，但产生外碎片 | | <strong>段页式</strong> | 页 | 固定大小的页框 | <strong>内碎片</strong> (段内最后一页) | 段表 + 页表 (MMU硬件查表) | 结合二者优点，管理复杂，开销大 |</p> <hr> <h3>5.1 单一连续区 (Single Contiguous Allocation)</h3> <ul> <li><strong>特点:</strong> 内存除操作系统区域外，全部由当前运行的<strong>一个</strong>用户程序独占。</li> <li><strong>实现:</strong> 程序总是加载到同一个内存地址 (或通过一个简单的基址寄存器) 。</li> <li><strong>优点:</strong> 非常简单。</li> <li><strong>缺点:</strong> 内存利用率极低，无法支持多道程序设计。适用于非常早期的或简单的嵌入式系统。</li> </ul> <h3>5.2 固定分区 (Fixed Partitioning)</h3> <ul> <li><strong>特点:</strong> 内存被预先划分成若干个<strong>大小固定</strong>的分区。分区大小可以相同也可以不同。</li> <li><strong>分配:</strong> 每个分区装入一个进程。当进程需要内存时，操作系统寻找一个足够大且空闲的分区分配给它。</li> <li><strong>优点:</strong> 实现简单，支持了多道程序。</li> <li><strong>缺点:</strong> <ul> <li><strong>内碎片:</strong> 分配给进程的分区可能大于进程实际需要的大小。</li> <li><strong>不灵活:</strong> 分区大小固定，大进程可能无处容身，小进程占用大分区造成浪费。</li> </ul> </li> </ul> <h3>5.3 可变分区 (Variable Partitioning / Dynamic Partitioning)</h3> <ul> <li> <p><strong>特点:</strong> 内存不预先划分。根据进程的实际需求，从**空闲内存 (洞 Hole) ** 中动态地分割出一个分区分配给它。</p> </li> <li> <p><strong>分配:</strong> 使用 First Fit, Best Fit, Worst Fit 等算法在空闲区列表中查找并分配。</p> </li> <li> <p><strong>优点:</strong> 按需分配，没有内碎片，比固定分区灵活。</p> </li> <li> <p><strong>缺点:</strong></p> <ul> <li><strong>外碎片:</strong> 随着进程的分配和回收，内存中会产生许多不连续的小空闲区，即使总空闲量足够，也可能无法满足新的较大内存请求。</li> <li><strong>管理复杂:</strong> 需要维护空闲区列表，分配和回收时涉及查找、分割和合并。</li> </ul> </li> <li> <p><strong>外碎片解决方案:</strong></p> <ul> <li><strong>紧缩技术 (Compaction / Memory Compaction):</strong> <ul> <li><strong>思想:</strong> 通过移动内存中的进程，将所有小的空闲区合并成一个或几个大的连续空闲区。</li> <li><strong>实现:</strong> 需要<strong>动态重定位</strong>支持 (因为进程物理地址改变了) 。</li> <li><strong>问题:</strong> <ul> <li><strong>开销大:</strong> 移动内存内容非常耗时，期间系统性能会下降。</li> <li><strong>移动时机:</strong> 何时进行紧缩？ (例如，当分配失败且有足够总空闲空间时，或定时进行) 。</li> </ul> </li> </ul> </li> </ul> </li> </ul> <h3>5.4 页式管理 (Paging)</h3> <ul> <li><strong>核心思想:</strong> <ul> <li><strong>逻辑地址空间:</strong> 划分为固定大小的块，称为 <strong>页 (Page)</strong>。</li> <li><strong>物理内存空间:</strong> 划分为与页大小相同的块，称为 <strong>页框 (Page Frame)</strong> 或物理页面、内存块。</li> <li><strong>分配:</strong> 以<strong>页</strong>为单位进行。进程需要的页可以加载到<strong>任意</strong>空闲的页框中。逻辑上相邻的页在物理上<strong>不必</strong>相邻。</li> </ul> </li> <li><strong>逻辑地址结构:</strong> <code>逻辑地址 = 页号 (Page Number) + 页内偏移 (Offset)</code> <ul> <li>例如，32位地址，页面大小 4KB (212 B): <ul> <li>高 20位 (31-12) 是页号。</li> <li>低 12位 (11-0) 是页内偏移。</li> </ul> </li> </ul> </li> <li><strong>数据结构:</strong> <ul> <li><strong>页表 (Page Table):</strong> 每个进程都有一个页表。 <ul> <li><strong>功能:</strong> 记录逻辑页号到物理页框号的映射关系。</li> <li><strong>页表项 (Page Table Entry - PTE):</strong> 至少包含 <code>页框号 (Frame Number)</code>。通常还包含其他控制位： <ul> <li><strong>有效位/驻留位 (Valid/Present Bit):</strong> 标记该页是否在物理内存中。</li> <li><strong>保护位 (Protection Bits):</strong> 控制读/写/执行权限。</li> <li><strong>修改位 (Modified/Dirty Bit):</strong> 标记该页加载到内存后是否被修改过。</li> <li><strong>访问位 (Accessed/Referenced Bit):</strong> 标记该页是否被访问过。</li> </ul> </li> <li><strong>存储:</strong> 页表本身也存储在内存中。操作系统通过<strong>页表基址寄存器 (Page Table Base Register - PTBR)</strong> (如 x86 的 CR3 寄存器) 指向当前进程的页表起始地址。</li> </ul> </li> <li><strong>空闲页框列表:</strong> 操作系统需要维护一个数据结构 (如位图或链表) 来跟踪哪些物理页框是空闲的。</li> </ul> </li> <li><strong>地址转换过程 (硬件 MMU):</strong> <ol> <li>CPU 发出逻辑地址。</li> <li>MMU 将逻辑地址分解为<strong>页号 <code>p</code></strong> 和<strong>页内偏移 <code>d</code></strong>。</li> <li>使用<strong>页号 <code>p</code></strong> 作为索引，访问当前进程的<strong>页表</strong> (基址在 PTBR)。</li> <li>找到对应的<strong>页表项 (PTE)</strong>。</li> <li>检查 PTE 中的<strong>有效位</strong>和<strong>保护位</strong>。如果无效或权限不足，则产生<strong>缺页异常 (Page Fault)</strong> 或<strong>保护异常</strong>，陷入操作系统处理。</li> <li>如果有效且权限允许，从 PTE 中取出<strong>页框号 <code>f</code></strong>。</li> <li>将<strong>页框号 <code>f</code></strong> 与<strong>页内偏移 <code>d</code></strong> 拼接 (或 <code>f * PageSize + d</code>) 得到最终的<strong>物理地址</strong>。</li> <li>访问物理内存。</li> </ol> </li> <li><strong>优点:</strong> <ul> <li><strong>无外碎片:</strong> 以固定大小的页框为单位分配，总能利用空闲页框。</li> <li><strong>内存利用率高:</strong> 物理内存不必连续。</li> <li><strong>易于实现共享:</strong> 让多个进程的页表项指向同一个物理页框即可共享页面 (如共享库代码) 。</li> <li><strong>支持虚拟内存的基础。</strong></li> </ul> </li> <li><strong>缺点:</strong> <ul> <li><strong>内碎片:</strong> 进程的最后一页通常不会完全占满，导致该页框内产生少量内碎片。</li> <li><strong>页表开销:</strong> 页表本身需要占用内存空间。对于大地址空间和小编页面，页表可能非常大 (需要多级页表等技术解决) 。</li> <li><strong>地址转换开销:</strong> 每次访存理论上需要两次内存访问 (一次查页表，一次访问数据) 。实际使用 <strong>TLB (Translation Lookaside Buffer)</strong>，一种页表项的高速缓存，来加速转换。</li> </ul> </li> </ul> <h3>5.5 段式管理 (Segmentation)</h3> <ul> <li><strong>核心思想:</strong> <ul> <li><strong>逻辑地址空间:</strong> 按照程序的<strong>逻辑结构</strong>划分为多个<strong>段 (Segment)</strong>，如代码段、数据段、栈段等。每个段有自己的名字 (通常用段号代替) 和长度。<strong>段的长度可以不同</strong>。</li> <li><strong>物理内存空间:</strong> 仍然是线性地址空间，但分配时按<strong>整个段</strong>分配。</li> <li><strong>分配:</strong> 以<strong>段</strong>为单位。每个段需要分配一块<strong>连续</strong>的物理内存空间，但不同段之间可以不相邻。</li> </ul> </li> <li><strong>逻辑地址结构:</strong> <code>逻辑地址 = 段号 (Segment Number) + 段内偏移 (Offset within Segment)</code></li> <li><strong>数据结构:</strong> <ul> <li><strong>段表 (Segment Table):</strong> 每个进程一个段表。 <ul> <li><strong>功能:</strong> 记录逻辑段号到物理内存信息的映射。</li> <li><strong>段表项 (Segment Table Entry - STE):</strong> 通常包含： <ul> <li><strong>段基址 (Segment Base):</strong> 该段在物理内存中的起始地址。</li> <li><strong>段限长 (Segment Limit):</strong> 该段的长度。</li> <li><strong>保护位 (Protection Bits):</strong> 如读/写/执行权限。</li> </ul> </li> <li><strong>存储:</strong> 段表本身也存储在内存中。操作系统通过<strong>段表基址寄存器 (Segment Table Base Register - STBR)</strong> 指向当前进程的段表。</li> </ul> </li> <li><strong>物理内存管理:</strong> 类似于<strong>可变分区</strong>管理，需要维护空闲区列表，使用 First Fit 等算法分配连续空间。</li> </ul> </li> <li><strong>地址转换过程 (硬件 MMU):</strong> <ol> <li>CPU 发出逻辑地址。</li> <li>MMU 将逻辑地址分解为<strong>段号 <code>s</code></strong> 和<strong>段内偏移 <code>d</code></strong>。</li> <li>使用<strong>段号 <code>s</code></strong> 作为索引，访问当前进程的<strong>段表</strong> (基址在 STBR)。</li> <li>找到对应的<strong>段表项 (STE)</strong>。</li> <li><strong>检查:</strong> <ul> <li>段号 <code>s</code> 是否合法 (在段表范围内) 。</li> <li>段内偏移 <code>d</code> 是否小于段限长 <code>Limit</code> (<code>0 &#x3C;= d &#x3C; Limit</code>)。如果超出，则产生<strong>地址越界异常</strong>。</li> <li>访问权限是否允许。如果不允许，则产生<strong>保护异常</strong>。</li> </ul> </li> <li>如果检查通过，取出<strong>段基址 <code>Base</code></strong>。</li> <li>计算物理地址: <strong>物理地址 = 段基址 <code>Base</code> + 段内偏移 <code>d</code></strong>。</li> <li>访问物理内存。</li> </ol> </li> <li><strong>优点:</strong> <ul> <li><strong>符合程序逻辑:</strong> 分段是用户可见的，便于程序员组织代码和数据。</li> <li><strong>易于共享和保护:</strong> 可以方便地对整个逻辑段 (如代码段) 进行共享或设置保护属性。</li> </ul> </li> <li><strong>缺点:</strong> <ul> <li><strong>外碎片:</strong> 段的长度可变，分配和回收类似于可变分区，会产生外碎片。需要紧缩技术。</li> <li><strong>内存分配复杂:</strong> 需要找到足够大的连续空闲块。</li> </ul> </li> </ul> <h3>5.6 段页式管理 (Segmented Paging)</h3> <ul> <li><strong>核心思想:</strong> 结合<strong>段式</strong>和<strong>页式</strong>的优点。 <ul> <li><strong>用户视角 / 逻辑地址空间:</strong> 仍然按<strong>段</strong>划分 (用户可见)。</li> <li><strong>内存管理 / 物理内存:</strong> 按<strong>页框</strong>划分和分配 (系统底层)。</li> <li><strong>实现:</strong> 每个<strong>逻辑段</strong>内部再进一步划分为<strong>固定大小的页</strong>。</li> </ul> </li> <li><strong>逻辑地址结构:</strong> <code>逻辑地址 = 段号 s + 段内页号 p + 页内偏移 d</code> (或者看作 <code>段号 s + 段内偏移 offset</code>，其中 <code>offset</code> 再被解释为 <code>页号 p + 页内偏移 d</code>)</li> <li><strong>数据结构:</strong> <ul> <li><strong>段表 (Segment Table):</strong> 每个进程一个。 <ul> <li><strong>段表项:</strong> 不再直接指向物理基址，而是指向该<strong>段对应的页表</strong>的基址，并包含页表的长度 (或段的页数) 。</li> </ul> </li> <li><strong>页表 (Page Table):</strong> <strong>每个段</strong>拥有一个页表。 <ul> <li><strong>页表项:</strong> 记录段内的逻辑页号到物理页框号的映射。</li> </ul> </li> </ul> </li> <li><strong>地址转换过程 (硬件 MMU):</strong> <ol> <li>CPU 发出逻辑地址 <code>(s, offset)</code>。</li> <li>用<strong>段号 <code>s</code></strong> 查<strong>段表</strong>，找到对应段的<strong>页表基址</strong>和<strong>段限长</strong>。</li> <li>检查<strong>段内偏移 <code>offset</code></strong> 是否小于<strong>段限长</strong>。如果超出，则地址越界。</li> <li>将<strong>段内偏移 <code>offset</code></strong> 分解为<strong>段内页号 <code>p</code></strong> 和<strong>页内偏移 <code>d</code></strong>。</li> <li>使用<strong>段内页号 <code>p</code></strong> 作为索引，访问<strong>该段的页表</strong> (基址来自段表项) ，找到对应的<strong>页表项 (PTE)</strong>。</li> <li>检查 PTE 的有效位和保护位。</li> <li>从 PTE 中取出<strong>页框号 <code>f</code></strong>。</li> <li>计算物理地址: <strong>物理地址 = 页框号 <code>f</code> * PageSize + 页内偏移 <code>d</code></strong>。</li> <li>访问物理内存。</li> </ol> </li> <li><strong>优点:</strong> <ul> <li>结合了段式的逻辑清晰、易于共享保护和页式的内存利用率高、无外碎片的优点。</li> </ul> </li> <li><strong>缺点:</strong> <ul> <li><strong>系统开销大:</strong> 需要维护段表和多个页表，增加了内存占用。</li> <li><strong>地址转换更复杂:</strong> 需要多次内存访问 (查段表 -> 查页表 -> 访问数据) 。同样需要 TLB 来加速。</li> </ul> </li> </ul> <hr> <h2>6. 内存 "扩充" 技术</h2> <p>在物理内存不足时，让系统能运行更大程序或更多进程的技术。</p> <h3>6.1 覆盖技术 (Overlaying)</h3> <ul> <li><strong>目的:</strong> 在<strong>物理内存小于程序总大小</strong>的情况下运行程序。</li> <li><strong>思想:</strong> 程序的<strong>不同模块</strong> (覆盖段) 按照它们的<strong>调用关系</strong>在<strong>同一块内存区域</strong>中<strong>相互替换</strong>。只有当前需要的模块和常驻模块保留在内存中。</li> <li><strong>实现:</strong> <ul> <li><strong>程序员负责:</strong> 需要程序员手动划分程序模块，并指定它们之间的<strong>覆盖结构 (Overlay Structure)</strong>。</li> <li>操作系统提供加载覆盖模块的机制。</li> </ul> </li> <li><strong>示例:</strong> 程序 A 调用 B 或 C；B 调用 D 或 E；C 调用 F。 <ul> <li>常驻区: A (8K)</li> <li>覆盖区 0: B (8K) 或 C (10K) -> 需要 10K</li> <li>覆盖区 1: D (12K) 或 E (4K) (当B在内存时) 或 F (10K) (当C在内存时) -> 需要 12K</li> <li>总需内存 = 常驻区 + Max(覆盖区0) + Max(覆盖区1) = 8K + 10K + 12K = 30K (远小于原始总和 54K)。</li> </ul> </li> <li><strong>优点:</strong> 能够在小内存上运行大程序。</li> <li><strong>缺点:</strong> <ul> <li><strong>对用户不透明:</strong> 增加了程序员的负担，编程复杂。</li> <li><strong>执行时间增加:</strong> 需要从外存动态加载覆盖模块，属于“时间换空间”。</li> </ul> </li> <li><strong>应用:</strong> 主要用于<strong>早期</strong>内存极其有限的操作系统。</li> </ul> <h3>6.2 交换技术 (Swapping)</h3> <ul> <li><strong>目的:</strong> 提高内存利用率和系统吞吐量，允许运行的进程总大小超过物理内存。</li> <li><strong>思想:</strong> 将<strong>暂时不运行</strong>的进程<strong>完整地</strong>从<strong>内存</strong>移动到<strong>外存 (交换区 Swap Space) <strong>，称为</strong>换出 (Swap Out / Roll Out)</strong>。当需要再次运行时，再从外存将其<strong>换回 (Swap In / Roll In)</strong> 到内存中。</li> <li><strong>实现:</strong> <ul> <li><strong>Swapper (交换程序):</strong> 操作系统中负责执行交换操作的模块。</li> <li><strong>交换区 (Swap Space):</strong> 通常是磁盘上一块<strong>连续</strong>或特殊管理的区域，用于快速读写整个进程映像。</li> </ul> </li> <li><strong>关键问题与讨论:</strong> <ul> <li><strong>交换内容:</strong> 进程的哪些部分需要交换？通常是进程的整个用户地址空间 (代码、数据、堆、栈等运行时状态) 。</li> <li><strong>交换位置:</strong> 被换出的进程保存在磁盘的交换区。</li> <li><strong>交换时机:</strong> <ul> <li>内存空间不足时触发换出。</li> <li>进程长时间阻塞或优先级低时可能被换出。</li> <li>与<strong>调度器</strong>结合，选择合适的进程换入换出。</li> </ul> </li> <li><strong>换出进程选择:</strong> 考虑进程状态 (不应换出等待 I/O 的进程) 、优先级、在内存驻留时间等因素。</li> <li><strong>换入位置:</strong> 换回内存时不一定回到原来的物理地址。需要<strong>动态地址重定位</strong>支持。</li> <li><strong>进程空间增长:</strong> 如果进程在内存中时其地址空间增长 (如堆或栈扩展) ，分配可能需要更多内存。如果此时内存不足，可能需要换出其他进程。如果进程在交换区时需要增长，则处理更复杂，通常不允许或有预留机制。</li> </ul> </li> <li><strong>优点:</strong> 提高了内存利用率，支持运行比物理内存更大的进程集合。</li> <li><strong>缺点:</strong> <ul> <li><strong>开销大:</strong> 整个进程映像的磁盘 I/O 非常耗时。</li> <li><strong>可能导致抖动 (Thrashing):</strong> 如果内存严重不足，系统可能花费大量时间在换入换出进程上，而实际执行用户代码的时间很少。</li> </ul> </li> <li><strong>应用:</strong> 曾用于分时系统，现代系统中的<strong>虚拟内存</strong>可以看作是更精细化的交换技术 (以页为单位) 。</li> </ul> <h3>6.3 虚拟内存技术 (Virtual Memory)</h3> <p>(本讲义中提及，但未详细展开，通常是后续章节内容) 结合了<strong>请求调页 (Demand Paging)</strong> 或<strong>请求分段 (Demand Segmentation)</strong> 与<strong>交换技术</strong>的思想。允许程序只加载部分页面/段到内存即可运行，其余部分在需要时才从磁盘加载。这是现代操作系统普遍采用的核心内存管理技术。</p> <hr> <h2>7. 重点小结</h2> <ul> <li><strong>基本概念:</strong> 存储体系、逻辑地址/物理地址、地址重定位 (静态/动态) 、地址保护、共享、局部性。</li> <li><strong>物理内存管理:</strong> <ul> <li>数据结构：位示图、空闲区表/链表 (隐式/显式/分离) 。</li> <li>分配算法：首次/下次/最佳/最差适配。</li> <li>回收与合并。</li> <li>碎片问题：内碎片、外碎片。</li> <li>特定策略：伙伴系统、SLAB/SLUB/SLOB 分配器。</li> </ul> </li> <li><strong>内存管理方案:</strong> <ul> <li>单一连续区、固定分区、可变分区 (+紧缩) 、页式、段式、段页式。</li> <li>每种方案的特点、优缺点、地址转换机制、相关数据结构 (页表/段表) 。</li> </ul> </li> <li><strong>内存扩充技术:</strong> 覆盖技术、交换技术 (虚拟内存是更高级形式) 。</li> </ul>https://www.lyt0112.com/blog/operating_systems_note_04-zhhttps://www.lyt0112.com/blog/operating_systems_note_04-zhOperating Systems Notes 04: 进程线程调度Fri, 28 Mar 2025 04:15:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gemini-2.5-pro-preview-03-25</code></p> <p>This article uses LLM to improve efficiency, which can make mistakes. I have tried my best to check and proofread, but still cannot guarantee complete accuracy.</p> <p>For personal use, may be nagging for you.</p> <h2>1. 进程/线程调度问题分析</h2> <h3>1.1 When and How (调度时机与原因)</h3> <h4>调度这件事儿什么时候做？做的理由有哪些？</h4> <p><strong>调度时机 (When):</strong></p> <p>操作系统需要在特定事件发生时决定哪个进程接下来应该占用CPU。这些时机主要包括：</p> <ol> <li><strong>进程创建 (Process Creation):</strong> 当一个新进程被创建时 (例如，通过<code>fork()</code>系统调用) ，需要决定是运行父进程还是子进程，或者其他进程。</li> <li><strong>进程终止 (Process Termination):</strong> 当一个进程执行完毕或被终止时 (例如，调用<code>exit()</code>) ，它占用的CPU必须分配给其他就绪的进程。</li> <li><strong>进程阻塞 (Process Blocking):</strong> 当一个进程因等待某个事件 (如I/O操作完成、等待信号量、等待用户输入等) 而无法继续执行时，它会进入阻塞状态，此时调度器需要选择另一个进程来运行。</li> <li><strong>I/O中断发生 (I/O Interrupt):</strong> 当一个I/O操作完成，产生中断时，原先等待该I/O的进程可能会从阻塞态变为就绪态。这时，调度器可能需要重新评估，决定是继续运行当前进程，还是切换到刚刚变为就绪的、可能优先级更高的进程。</li> <li><strong>时钟中断发生 (Clock Interrupt):</strong> 在分时系统中，为了防止某个进程长时间独占CPU，操作系统会设置一个定时器。当定时器中断发生时，当前运行进程的时间片 (Time Slice/Quantum) 可能已用完，调度器会介入，决定是继续运行该进程 (如果时间片未用完或没有其他就绪进程) ，还是切换到另一个就绪进程 (抢占式调度) 。</li> </ol> <p><strong>调度的理由 (Why):</strong></p> <p>调度的根本目的是有效、公平地管理和分配有限的CPU资源给多个并发执行的进程。具体理由包括：</p> <ol> <li><strong>提高CPU利用率:</strong> 尽量让CPU保持忙碌状态，减少空闲时间。当一个进程等待I/O时，可以让其他就绪进程使用CPU。</li> <li><strong>提高系统吞吐量 (Throughput):</strong> 单位时间内完成的进程数量。好的调度算法可以在满足其他目标的同时，尽可能多地完成任务。</li> <li><strong>减少周转时间 (Turnaround Time):</strong> 指一个进程从提交到完成所花费的总时间 (等待进入内存、在就绪队列等待、CPU执行、I/O执行的总和) 。</li> <li><strong>减少等待时间 (Waiting Time):</strong> 指进程在就绪队列中等待CPU所花费的总时间。</li> <li><strong>减少响应时间 (Response Time):</strong> 对于交互式系统尤其重要，指从用户发出请求到系统首次产生响应 (而非完成任务) 所花费的时间。</li> <li><strong>确保公平性 (Fairness):</strong> 保证每个进程都能获得合理的CPU时间份额，防止某些进程被饿死 (Starvation) 。</li> <li><strong>满足实时性要求 (Real-time Constraints):</strong> 对于实时系统，调度必须保证关键任务在它们的截止时间 (Deadline) 之前完成。</li> </ol> <h4>如果没有可被调度的进程，系统做什么呢？</h4> <p>如果当前没有用户进程或系统核心任务进程处于就绪状态 (Ready State) ，CPU不能完全停止。操作系统通常会执行一个特殊的<strong>空闲进程 (Idle Process)</strong> 或称为<strong>系统空闲任务 (System Idle Task)</strong>。</p> <ul> <li><strong>作用:</strong> 这个进程拥有最低的优先级。当没有其他任何事情可做时，调度器就会选择它来运行。</li> <li><strong>行为:</strong> <ul> <li>它通常执行一个无限循环。</li> <li>在这个循环中，它可以执行一些低优先级的系统维护任务。</li> <li>更重要的是，在许多架构上 (如x86) ，它可以执行一个特殊的指令 (如<code>HLT</code> - Halt) ，使CPU进入低功耗状态，直到下一个中断 (如时钟中断、I/O中断) 唤醒CPU。这有助于节能和降低温度。</li> </ul> </li> <li><strong>目的:</strong> 确保CPU总是有事可做 (即使是“等待”) ，并提供一个合法的状态供调度器切换，同时优化能源使用。</li> </ul> <h4>上下文切换的过程？有哪些开销？</h4> <p><strong>上下文切换 (Context Switch)</strong> 是指操作系统保存当前正在运行进程的状态 (上下文) ，并加载另一个进程的状态，以便让后者开始或继续运行的过程。这是实现多任务处理的基础。</p> <p><strong>过程:</strong></p> <ol> <li><strong>中断/系统调用触发:</strong> 调度发生 (如时间片用完、进程阻塞等) 。</li> <li><strong>保存当前进程上下文:</strong> <ul> <li>保存程序计数器 (Program Counter, PC) 和其他CPU寄存器 (通用寄存器、状态寄存器等) 的值。这些值通常保存在该进程的<strong>进程控制块 (Process Control Block, PCB)</strong> 中。</li> <li>保存当前进程的栈指针。</li> <li>更新进程状态 (例如，从 "Running" 变为 "Ready" 或 "Blocked") 。</li> <li>可能需要保存内存管理相关信息 (如页表基址寄存器) 。</li> </ul> </li> <li><strong>执行调度算法:</strong> 操作系统调度器代码运行，根据调度策略选择下一个要运行的进程。</li> <li><strong>加载新进程上下文:</strong> <ul> <li>从选定进程的PCB中恢复其状态。</li> <li>加载新进程的程序计数器和CPU寄存器。</li> <li>恢复新进程的栈指针。</li> <li>更新新进程的状态 (通常是从 "Ready" 变为 "Running") 。</li> <li>恢复内存管理信息 (可能需要刷新TLB - Translation Lookaside Buffer) 。</li> </ul> </li> <li><strong>跳转执行:</strong> CPU跳转到新进程被中断时的下一条指令地址 (或其入口点，如果是首次运行) 开始执行。</li> </ol> <p><strong>开销:</strong></p> <p>上下文切换本身并不执行任何有用的用户工作，它是一种<strong>纯粹的开销 (Overhead)</strong>。开销主要包括：</p> <ol> <li> <p><strong>直接开销 (Direct Costs):</strong></p> <ul> <li><strong>保存和加载寄存器:</strong> CPU需要时间来读写寄存器和PCB。</li> <li><strong>执行调度器代码:</strong> 选择下一个进程也需要CPU时间。</li> <li><strong>更新PCB和其他数据结构:</strong> 维护进程队列等操作需要时间。</li> <li><strong>MMU操作:</strong> 可能需要加载新的页表基址，这可能导致TLB被刷新 (TLB flush) ，增加后续内存访问的延迟。</li> </ul> </li> <li> <p><strong>间接开销 (Indirect Costs):</strong></p> <ul> <li><strong>缓存污染 (Cache Pollution):</strong> 当新进程开始运行时，CPU缓存 (L1, L2, L3 Cache) 中很可能包含的是前一个进程的数据和指令。新进程运行时会发生大量的缓存未命中 (Cache Miss) ，需要从内存中重新加载数据，这会显著降低执行速度，直到新进程的“工作集” (Working Set) 被加载到缓存中。这是上下文切换最主要的性能影响之一。</li> <li><strong>CPU流水线冲刷:</strong> 切换可能导致CPU的指令流水线被清空和重建。</li> </ul> </li> </ol> <p><strong>最佳实践:</strong> 频繁的上下文切换会显著降低系统整体性能。因此，调度算法和系统设计 (如时间片大小的选择) 需要在响应时间和系统吞吐量/效率之间找到平衡。</p> <h4>关于调度算法，我们都关心什么？</h4> <p>我们在评估和选择调度算法时，主要关心以下几个<strong>性能指标 (Performance Metrics)</strong> 或<strong>目标 (Goals)</strong>：</p> <ul> <li><strong>CPU 利用率 (CPU Utilization):</strong> CPU处于忙碌状态的时间百分比。越高越好，但100%可能意味着没有冗余，响应性可能变差。</li> <li><strong>系统吞吐量 (Throughput):</strong> 单位时间内完成的进程 (或作业) 数量。越高越好。</li> <li><strong>周转时间 (Turnaround Time):</strong> 从进程提交到完成的总时间。越短越好 (平均周转时间、最差周转时间) 。</li> <li><strong>等待时间 (Waiting Time):</strong> 进程在就绪队列中等待CPU的总时间。越短越好 (平均等待时间、最差等待时间) 。</li> <li><strong>响应时间 (Response Time):</strong> 从提交请求到产生第一个响应的时间 (交互式系统关键) 。越短且越稳定越好。</li> <li><strong>公平性 (Fairness):</strong> 每个进程获得合理的CPU份额，防止饿死。</li> <li><strong>可预测性 (Predictability):</strong> 对于实时系统，执行时间的可预测性比平均性能更重要。</li> <li><strong>满足截止时间 (Meeting Deadlines):</strong> 对于实时系统，这是硬性或软性要求。</li> <li><strong>优先级处理 (Priority Handling):</strong> 系统能否有效处理不同优先级的进程。</li> <li><strong>资源平衡 (Resource Balance):</strong> 尽量保持所有资源 (CPU, I/O设备) 都处于忙碌状态。</li> </ul> <h4>不同类型的操作系统都适用同一种调度算法吗？</h4> <p><strong>不适用。</strong> 不同类型的操作系统有着不同的设计目标和用户需求，因此需要采用不同的调度策略。</p> <ul> <li><strong>批处理系统 (Batch Systems):</strong> <ul> <li>目标：最大化吞吐量和CPU利用率，减少平均周转时间。用户通常不直接与系统交互。</li> <li>适用算法：先来先服务 (FCFS)、最短作业优先 (SJF)、最高响应比优先 (HRRN)。公平性和响应时间相对不重要。</li> </ul> </li> <li><strong>交互式系统 (Interactive Systems / Time-Sharing Systems):</strong> <ul> <li>目标：最小化响应时间，提供良好的用户体验，兼顾公平性。</li> <li>适用算法：轮转法 (Round Robin, RR)、优先级调度、多级队列调度 (Multi-level Queue)、多级反馈队列调度 (Multi-level Feedback Queue, MLFQ)。</li> </ul> </li> <li><strong>实时系统 (Real-Time Systems, RTOS):</strong> <ul> <li>目标：满足任务的截止时间要求，可预测性至关重要。分为硬实时 (必须满足) 和软实时 (尽量满足) 。</li> <li>适用算法：速率单调调度 (Rate Monotonic Scheduling, RMS - 用于静态优先级)、最早截止时间优先 (Earliest Deadline First, EDF - 用于动态优先级)、优先级调度 (配合精确的优先级分配) 。</li> </ul> </li> </ul> <h4>对于一个调度算法，应该追求什么样的目标？</h4> <p>一个调度算法应该追求的目标组合取决于具体的系统类型和应用场景。通常需要在多个 (有时是相互冲突的) 目标之间进行<strong>权衡 (Trade-off)</strong>。</p> <ul> <li><strong>通用目标 (All Systems):</strong> <ul> <li><strong>公平性:</strong> 防止饿死。</li> <li><strong>策略强制:</strong> 确保系统设定的策略 (如优先级) 得到执行。</li> <li><strong>平衡:</strong> 保持系统的各个部分都处于活动状态 (例如，CPU密集型和I/O密集型进程交替运行) 。</li> </ul> </li> <li><strong>批处理系统目标:</strong> <ul> <li>高吞吐量</li> <li>低周转时间</li> <li>高CPU利用率</li> </ul> </li> <li><strong>交互式系统目标:</strong> <ul> <li>快速响应时间</li> <li>低响应时间方差 (稳定性)</li> <li>满足用户期望 (感觉流畅)</li> </ul> </li> <li><strong>实时系统目标:</strong> <ul> <li>满足截止时间</li> <li>高可预测性</li> </ul> </li> </ul> <p><strong>最佳实践:</strong> 没有“万能”的调度算法。选择或设计算法时，必须明确系统的主要目标，并接受在其他方面可能存在的不足。例如，追求极低响应时间可能会牺牲一些吞吐量。</p> <h4>选进程时都考虑了哪些点？单一因素还是多因素？</h4> <p>选择下一个要运行的进程时，调度算法可能考虑<strong>单一因素</strong>或<strong>多个因素</strong>。</p> <ul> <li> <p><strong>单一因素:</strong></p> <ul> <li><strong>FCFS:</strong> 只考虑进程到达就绪队列的时间。</li> <li><strong>SJF (非抢占式):</strong> 只考虑预估的下一个CPU脉冲 (burst) 长度。</li> <li><strong>简单优先级调度:</strong> 只考虑静态分配的优先级。</li> </ul> </li> <li> <p><strong>多因素:</strong> 现代操作系统和更复杂的调度算法通常是多因素的。</p> <ul> <li><strong>优先级调度 (带老化):</strong> 考虑静态优先级，但也考虑进程等待时间 (老化机制，aging) ，提高等待过久进程的优先级以防饿死。</li> <li><strong>RR:</strong> 考虑到达时间和时间片轮转。</li> <li><strong>MLFQ:</strong> 考虑优先级、进程行为 (CPU密集型 vs I/O密集型) 、等待时间等，动态调整进程在不同队列间的移动。</li> <li><strong>HRRN:</strong> 考虑等待时间 (W) 和服务时间/脉冲长度 (S)，计算响应比 <code>(W+S)/S</code>。</li> <li><strong>Linux CFS:</strong> 考虑进程的虚拟运行时间 (virtual runtime)，旨在给每个进程公平的CPU时间比例。它间接考虑了进程的等待时间和已运行时间。</li> <li><strong>Windows调度:</strong> 考虑基础优先级、动态优先级提升 (如完成I/O、处于前台窗口) 、时间片消耗情况等。</li> </ul> </li> </ul> <p><strong>结论:</strong> 简单算法可能只关注单一因素，但为了在复杂环境中平衡多个目标 (如响应时间、公平性、吞吐量) ，现代通用操作系统广泛使用<strong>多因素调度算法</strong>。</p> <h3>1.2 How (调度算法详解)</h3> <h4>适用批处理系统的调度算法有哪些？</h4> <p>主要目标是效率 (吞吐量、CPU利用率) 和整体完成时间 (周转时间) 。</p> <ol> <li><strong>先来先服务 (First-Come, First-Served, FCFS):</strong> <ul> <li>实现：按进程到达就绪队列的顺序进行调度。使用FIFO队列。</li> <li>优点：简单，易于实现，公平 (按到达顺序) 。</li> <li>缺点：平均等待时间可能很长，尤其当短进程排在长进程之后时 (<strong>护航效应 Convoy Effect</strong>) 。不适合交互式系统。是非抢占式的。</li> </ul> </li> <li><strong>最短作业优先 (Shortest Job First, SJF):</strong> <ul> <li>实现：选择预计CPU执行时间 (下一个CPU burst) 最短的进程。可以是抢占式 (SRTF - Shortest Remaining Time First) 或非抢占式。</li> <li>优点：理论上具有最优的平均等待时间和平均周转时间。</li> <li>缺点： <ul> <li>需要预测下一个CPU burst长度，这很难精确做到 (通常基于历史数据估计) 。</li> <li>可能导致长作业<strong>饿死 (Starvation)</strong>，即长时间得不到CPU。</li> <li>非抢占式SJF不适合交互系统。抢占式SRTF开销较大。</li> </ul> </li> </ul> </li> <li><strong>最高响应比优先 (Highest Response Ratio Next, HRRN):</strong> <ul> <li>实现：非抢占式。计算每个进程的响应比 <code>R = (等待时间 W + 服务时间 S) / 服务时间 S</code>，选择R最高的进程。</li> <li>优点：结合了FCFS和SJF的优点。短作业容易被选中 (S小，R大) 。同时，等待时间长的进程其响应比也会增加，避免了饿死。</li> <li>缺点：仍需要预测服务时间S。计算响应比有额外开销。</li> </ul> </li> </ol> <h4>适用交互式系统的调度算法有哪些？</h4> <p>主要目标是提供快速响应和用户满意度。</p> <ol> <li> <p><strong>轮转法 (Round Robin, RR):</strong></p> <ul> <li>实现：类似于FCFS，但增加了时间片和抢占。每个进程被分配一个固定的时间片 (Quantum) ，运行时间超出时间片后会被强制切换 (抢占) ，放回就绪队列尾部。</li> <li>优点：公平，响应时间相对较短 (特别是对于短请求) ，简单。</li> <li>缺点： <ul> <li>性能对时间片大小非常敏感。太小则上下文切换频繁，开销大；太大则退化为FCFS，响应时间变长。</li> <li>平均周转时间通常比SJF长。</li> <li>没有考虑优先级。</li> </ul> </li> <li><strong>最佳实践:</strong> 时间片大小通常选择比平均交互响应所需时间稍长，但足够短以保证多个交互进程能快速轮换。</li> </ul> </li> <li> <p><strong>优先级调度 (Priority Scheduling):</strong></p> <ul> <li>实现：为每个进程分配一个优先级，调度器总是选择就绪队列中优先级最高的进程。可以是抢占式或非抢占式。</li> <li>优点：可以明确区分重要任务和次要任务。</li> <li>缺点： <ul> <li>可能导致低优先级进程<strong>饿死</strong>。</li> <li>优先级的确定可能是个问题 (静态 vs 动态) 。</li> </ul> </li> <li><strong>改进:</strong> <ul> <li><strong>老化 (Aging):</strong> 随时间增加等待进程的优先级。</li> <li><strong>动态优先级:</strong> 根据进程行为 (如I/O等待) 调整优先级。</li> </ul> </li> </ul> </li> <li> <p><strong>多级队列调度 (Multi-level Queue Scheduling):</strong></p> <ul> <li>实现：将就绪队列划分为多个独立的队列，每个队列有自己的优先级和调度算法 (如：前台交互队列用RR，后台批处理队列用FCFS) 。进程被永久分配到一个队列。</li> <li>优点：可以为不同类型的进程应用不同的调度策略。开销较低。</li> <li>缺点：缺乏灵活性，进程无法在队列间移动。低优先级队列可能饿死。</li> </ul> </li> <li> <p><strong>多级反馈队列调度 (Multi-level Feedback Queue, MLFQ):</strong></p> <ul> <li>实现：允许多个队列，并且进程可以在队列之间移动。这是目前通用操作系统中最常用的调度方法之一。</li> <li>规则示例： <ul> <li>新进程进入最高优先级队列。</li> <li>如果在时间片内完成，离开系统；如果用完时间片，则降级到下一个较低优先级队列。</li> <li>在较低优先级队列中等待时间过长的进程可以被提升到较高优先级队列 (防止饿死，即老化) 。</li> <li>I/O密集型进程 (经常阻塞放弃CPU) 通常会停留在较高优先级队列，保证响应性。CPU密集型进程会逐渐下降到较低优先级队列。</li> </ul> </li> <li>优点：非常灵活，自适应。能同时照顾到交互式和批处理式需求，兼顾响应时间、周转时间和公平性。</li> <li>缺点：设计和调优复杂 (队列数量、各队列调度算法、时间片大小、升级降级策略) 。</li> </ul> </li> </ol> <h4>适用实时系统的调度算法有哪些？</h4> <p>主要目标是满足时间约束 (截止时间) 。</p> <ol> <li><strong>速率单调调度 (Rate Monotonic Scheduling, RMS):</strong> <ul> <li>类型：静态优先级，抢占式。</li> <li>原理：周期性任务的优先级与其执行频率 (速率) 成正比。周期越短 (频率越高) ，优先级越高。</li> <li>优点：简单，易于实现，是最佳的静态优先级调度算法 (如果任务集可调度，RMS就能找到调度方案) 。可进行理论上的可调度性分析 (例如，利用率测试) 。</li> <li>缺点：只适用于周期性任务；对任务特性有较强假设；CPU利用率上限不如动态优先级算法高。</li> </ul> </li> <li><strong>最早截止时间优先 (Earliest Deadline First, EDF):</strong> <ul> <li>类型：动态优先级，抢占式。</li> <li>原理：当前就绪任务中，绝对截止时间最早的任务拥有最高优先级。</li> <li>优点：理论上是最优的动态优先级调度算法。只要任务集的总CPU利用率不超过100%，EDF就能找到调度方案 (对于可抢占、独立任务等理想情况) 。可以处理周期性和非周期性任务。</li> <li>缺点：实现比RMS复杂；可能出现多米诺骨牌效应 (一个任务错过截止时间可能导致后续任务也错过) ；动态优先级变化导致上下文切换可能更频繁。</li> </ul> </li> <li><strong>基于优先级的抢占式调度:</strong> <ul> <li>通用方法：给实时任务分配高优先级，使用标准优先级调度器。可以通过精心设置优先级来模拟RMS或EDF的行为。常用于软实时系统或硬实时系统中与其他任务共存的情况。</li> <li>需要确保高优先级任务能抢占低优先级任务，并且优先级反转 (Priority Inversion) 问题得到处理 (如使用优先级继承 Priority Inheritance 或优先级天花板 Priority Ceiling Protocol) 。</li> </ul> </li> </ol> <h4>怎样理解抢占式和非抢占式？</h4> <p>这是调度器决定何时进行调度的两种基本模式。</p> <ul> <li> <p><strong>非抢占式调度 (Non-preemptive / Cooperative Scheduling):</strong></p> <ul> <li><strong>定义:</strong> 一旦CPU分配给某个进程，该进程将一直运行，直到它主动放弃CPU (完成任务、阻塞等待I/O、或显式调用yield) 。调度器不能在进程运行中途强制剥夺其CPU使用权。</li> <li><strong>优点:</strong> 实现简单；上下文切换只在进程自愿放弃CPU时发生，开销相对较小；不会有并发访问内核数据结构的竞争问题 (在单处理器上) 。</li> <li><strong>缺点:</strong> 一个长时间运行或行为不当的进程可以独占CPU，导致其他进程 (特别是需要快速响应的交互式进程) 长时间等待，响应性差；不适合分时和实时系统。</li> <li><strong>例子:</strong> 早期的Windows (如Windows 3.1), 早期的Mac OS, 某些简单的嵌入式系统。</li> </ul> </li> <li> <p><strong>抢占式调度 (Preemptive Scheduling):</strong></p> <ul> <li><strong>定义:</strong> 操作系统可以强制暂停当前正在运行的进程 (即使它并未主动放弃CPU) ，并将CPU分配给另一个进程。这种抢占通常发生在时钟中断 (时间片用完) 或更高优先级进程变为就绪时。</li> <li><strong>优点:</strong> 能够保证CPU在进程间公平分配；提供更好的响应时间；可以有效处理优先级，防止低优先级任务阻塞高优先级任务 (前提是优先级设置合理) ；是现代多任务操作系统的标准做法。</li> <li><strong>缺点:</strong> 实现更复杂；上下文切换更频繁，开销更大；需要处理内核数据结构的并发访问问题 (需要锁或其他同步机制) 。</li> <li><strong>例子:</strong> Unix/Linux, Windows NT及后续版本, macOS, 大多数现代RTOS。</li> </ul> </li> </ul> <h4>从哪几方面对调度算法进行比较？</h4> <p>主要从前面提到的<strong>性能指标/目标</strong>来进行比较和评估：</p> <ol> <li><strong>CPU利用率:</strong> 哪个算法更能让CPU保持忙碌？</li> <li><strong>吞吐量:</strong> 哪个算法单位时间内能完成更多任务？</li> <li><strong>周转时间 (平均/最坏):</strong> 哪个算法下进程从提交到完成更快？</li> <li><strong>等待时间 (平均/最坏):</strong> 哪个算法下进程在就绪队列中等待的时间更短？</li> <li><strong>响应时间 (平均/方差):</strong> 哪个算法对交互式请求的响应更快、更稳定？</li> <li><strong>公平性:</strong> 哪个算法更能保证所有进程获得合理的CPU时间，避免饿死？</li> <li><strong>可预测性/满足截止时间:</strong> 对于实时系统，哪个算法更能保证任务按时完成？</li> <li><strong>算法开销:</strong> 算法本身的计算复杂度以及它导致的上下文切换频率和开销如何？</li> <li><strong>实现复杂度:</strong> 算法是否容易实现和调试？</li> <li><strong>对参数的敏感性:</strong> 算法性能是否严重依赖于某些参数 (如时间片大小、优先级设置) ？</li> </ol> <p><strong>比较方法:</strong></p> <ul> <li><strong>确定性建模 (Deterministic Modeling):</strong> 给定一组特定的进程及其属性 (到达时间、CPU burst) ，模拟运行不同算法，计算性能指标。简单但只反映特定场景。</li> <li><strong>排队论建模 (Queueing Models):</strong> 使用数学方法 (基于概率分布描述进程到达和CPU burst) 来分析平均性能。能提供理论洞察但模型可能简化现实。</li> <li><strong>模拟 (Simulation):</strong> 编写程序模拟操作系统调度行为，使用随机生成的进程或真实系统负载的轨迹 (trace) 作为输入。灵活且能反映动态行为，是常用的评估方法。</li> <li><strong>实际系统测量 (Implementation &#x26; Measurement):</strong> 在真实操作系统中实现算法，运行基准测试 (Benchmark) 或实际负载进行测量。最准确但成本最高。</li> </ul> <h4>机制和策略分离的原则在调度算法中的应用</h4> <p><strong>机制与策略分离 (Separation of Mechanism and Policy)</strong> 是一个重要的操作系统设计原则，也适用于调度。</p> <ul> <li> <p><strong>机制 (Mechanism):</strong> 提供<strong>如何做 (How)</strong> 的基础能力或工具。在调度中，机制包括：</p> <ul> <li>上下文切换的代码 (保存/加载寄存器、切换页表) 。</li> <li>维护进程状态 (就绪、运行、阻塞) 和PCB的数据结构。</li> <li>管理就绪队列 (如链表、优先级队列、红黑树) 。</li> <li>时钟中断处理程序。</li> <li>提供设置和读取进程优先级的接口。</li> <li>进程挂起和唤醒的原子操作。</li> </ul> </li> <li> <p><strong>策略 (Policy):</strong> 决定<strong>做什么 (What)</strong> 或<strong>何时做 (When)</strong>。在调度中，策略是指具体的调度算法逻辑：</p> <ul> <li>如何选择下一个运行的进程 (FCFS规则？SJF规则？RR规则？优先级规则？) 。</li> <li>时间片长度是多少？</li> <li>优先级如何确定？是静态还是动态调整？如何调整？</li> <li>何时进行抢占？</li> <li>如何处理不同类型的进程 (前台/后台，实时/普通) ？</li> </ul> </li> </ul> <p><strong>应用与好处:</strong></p> <ol> <li><strong>灵活性与可扩展性:</strong> 将调度算法 (策略) 与底层的上下文切换等 (机制) 分开，使得修改或更换调度策略更加容易，而无需改变底层的核心机制代码。例如，Linux内核允许通过<code>sched_setscheduler()</code>系统调用为进程选择不同的调度策略 (如<code>SCHED_FIFO</code>, <code>SCHED_RR</code>, <code>SCHED_NORMAL/CFS</code>) ，但它们都使用相同的底层上下文切换机制。</li> <li><strong>模块化:</strong> 代码结构更清晰，职责分明。调度策略模块可以独立开发、测试和更新。</li> <li><strong>可定制性:</strong> 用户或管理员可以更容易地根据特定需求调整调度策略参数，甚至在某些系统中插入自定义的调度模块。</li> </ol> <p><strong>例子:</strong> 调度器的主循环可能是一个通用的框架 (机制) ，它调用一个函数 (策略) 来选择下一个进程。不同的调度算法可以通过实现这个选择函数来插入。上下文切换函数是另一个独立的机制。优先级队列的实现 (如使用堆或链表) 是机制，而如何利用这个队列 (是按优先级取还是按FIFO取) 是策略。</p> <h4>实例操作系统的调度算法都是什么？</h4> <p>现代通用操作系统通常采用复杂且混合的调度策略，以平衡各种需求。</p> <ol> <li> <p><strong>Linux:</strong></p> <ul> <li><strong>主要调度器 (针对普通进程): 完全公平调度器 (Completely Fair Scheduler, CFS)</strong>，自内核2.6.23起引入。 <ul> <li>目标：为所有运行中的任务提供尽可能公平的CPU时间份额。</li> <li>机制：不再基于固定时间片，而是维护每个任务的<strong>虚拟运行时间 (vruntime)</strong>。总是选择vruntime最小的任务来运行。任务运行会增加其vruntime。I/O等待的任务vruntime增长慢，因此返回时更容易被选中。</li> <li>实现：使用红黑树来高效地找到vruntime最小的任务。</li> </ul> </li> <li><strong>实时调度策略:</strong> <ul> <li><code>SCHED_FIFO</code>: 静态优先级的先来先服务 (非时间片轮转) 。相同优先级的任务按到达顺序执行，直到阻塞、退出或被更高优先级抢占。</li> <li><code>SCHED_RR</code>: 静态优先级的轮转法。同<code>SCHED_FIFO</code>，但增加了时间片，同一优先级任务轮流运行。</li> </ul> </li> <li>优先级：实时任务优先级高于普通任务。普通任务也有优先级 (nice值) ，但CFS主要通过vruntime实现公平性，nice值影响vruntime增长的速度。</li> </ul> </li> <li> <p><strong>Windows (NT内核及以后):</strong></p> <ul> <li>采用<strong>基于优先级</strong>的<strong>抢占式</strong>调度算法，结合了<strong>多级反馈队列</strong>的思想。</li> <li>优先级：分为32个优先级。0为系统空闲线程，1-15为<strong>可变优先级类</strong> (Variable Priority Classes) ，16-31为<strong>实时优先级类</strong> (Real-time Priority Classes) 。内核线程可能使用更高的内部优先级。</li> <li>动态调整： <ul> <li>对于可变优先级类，系统会<strong>动态提升</strong>线程的优先级 (Priority Boost) ，例如： <ul> <li>当线程完成I/O操作时。</li> <li>当等待事件/信号量被满足时。</li> <li>前台窗口的线程优先级通常会被提升，以改善交互响应。</li> <li>短时间片用完后，优先级可能会暂时降低。</li> </ul> </li> <li>长时间消耗CPU的线程其动态优先级会逐渐衰减回基础优先级。</li> </ul> </li> <li>时间片：不同优先级的线程可能有不同的时间片长度。前台进程的时间片通常比后台进程长且可变。</li> <li>Quantum：Windows中称为Quantum，不是固定的，可以根据系统设置和前后台状态调整。</li> </ul> </li> <li> <p><strong>macOS:</strong></p> <ul> <li>基于XNU内核 (混合了Mach微内核和BSD Unix) 。</li> <li>调度也采用<strong>基于优先级</strong>的<strong>抢占式</strong>模型，具有<strong>多级反馈</strong>特性。</li> <li>线程优先级分为几个主要波段 (bands)：内核模式、系统高优先级、用户交互 (UI响应关键) 、用户启动、后台任务等。</li> <li>动态调整：系统会根据线程的行为 (如CPU使用情况、是否阻塞等待I/O、是否与用户界面交互) 动态调整其优先级，类似于Windows。</li> <li>也使用了类似Mach的线程调度原语和概念，例如时间片捐赠 (Time-sharing donation) 等机制来优化性能。</li> <li>近年来引入了<strong>服务质量 (Quality of Service, QoS)</strong> 类的概念，让开发者可以指定任务的意图 (如用户交互、后台数据处理、维护任务) ，系统据此进行更智能的资源 (包括CPU调度) 管理。</li> </ul> </li> </ol> <p><strong>总结:</strong> 现代主流操作系统都使用抢占式、基于优先级的调度框架，并结合动态优先级调整、多级队列/反馈机制，以及针对公平性 (如Linux CFS) 或服务质量 (如macOS QoS) 的特定优化，以适应通用计算环境中复杂多变的需求。</p> <hr> <h2>2. 处理器调度的基本概念</h2> <h3>2.1 调度的三个层次</h3> <p>操作系统中的调度可以发生在不同层面，对应不同的资源管理和时间尺度：</p> <ol> <li><strong>长程调度 (Long-term Scheduling / 作业调度):</strong> <ul> <li><strong>时机:</strong> 创建新进程时。</li> <li><strong>决策:</strong> 决定是否将新创建的进程纳入当前活跃进程集合 (即是否允许进入内存和就绪队列) 。</li> <li><strong>目标:</strong> 控制系统的并发度 (道数) 。</li> </ul> </li> <li><strong>中程调度 (Medium-term Scheduling / 内存调度):</strong> <ul> <li><strong>时机:</strong> 内存资源紧张或需要优化内存使用时。</li> <li><strong>决策:</strong> 决定哪些进程的部分或全部从内存换出到外存 (挂起) ，以及何时将挂起的进程换回内存。</li> <li><strong>目标:</strong> 提高内存利用率和系统吞吐量，通过交换 (Swapping) 技术实现。</li> </ul> </li> <li><strong>短程调度 (Short-term Scheduling / CPU调度 / 微观调度):</strong> <ul> <li><strong>时机:</strong> 发生特定事件 (如中断、系统调用、进程阻塞/唤醒、时间片用完等) 后，需要选择下一个占用CPU的进程时。</li> <li><strong>决策:</strong> 从就绪队列中选择一个进程/线程，将CPU的使用权分配给它。</li> <li><strong>频率:</strong> 非常频繁，通常在毫秒级。</li> <li><strong>要求:</strong> 实现必须高效。</li> </ul> </li> </ol> <p><strong>联系:</strong> 这三个层次的调度相互关联，共同管理进程从创建到完成的整个生命周期及其资源使用。</p> <h3>2.2 处理器调度的定义与场景</h3> <ul> <li><strong>定义:</strong> 控制和协调多个进程对CPU资源的竞争。</li> <li><strong>场景:</strong> 系统中有 N 个进程处于就绪状态，等待在 M 个CPU (M ≥ 1) 上运行。</li> <li><strong>任务:</strong> 调度程序 (内核函数) 根据特定的调度算法，从就绪队列中选择一个进程，并将CPU使用权交给它。</li> <li><strong>Idle进程:</strong> 如果就绪队列为空 (没有可运行的用户或系统进程) ，系统会调度一个特殊的<strong>空闲进程 (idle process)</strong> 来运行，它通常执行一些低优先级任务 (如系统监控、节能) 或简单地循环等待中断。</li> </ul> <h3>2.3 调度需要解决的核心问题</h3> <ol> <li><strong>调度时机 (When):</strong> 何时进行处理器分配决策。</li> <li><strong>调度算法 (What):</strong> 依据何种原则挑选进程/线程。</li> <li><strong>调度过程 (How):</strong> 如何完成CPU的分配，即上下文切换。</li> </ol> <h3>2.4 CPU调度的时机</h3> <p>调度通常在以下事件发生后，内核处理完相应事件并准备返回用户态之前的最后时刻进行：</p> <ul> <li><strong>进程生命周期变化:</strong> <ul> <li>进程执行完毕并退出 (<code>exit()</code>)。</li> <li>进程因错误或异常而终止 (<code>abort</code>)。</li> <li>创建新进程 (<code>fork()</code>)。</li> </ul> </li> <li><strong>进程状态转换:</strong> <ul> <li>运行进程因等待I/O或资源而进入阻塞态 (<code>wait()</code>)。</li> <li>阻塞进程被唤醒，回到就绪态 (I/O完成中断)。</li> <li>运行进程用完分配的时间片，回到就绪态 (时钟中断)。</li> <li>运行进程主动放弃 CPU (<code>yield()</code>)。</li> </ul> </li> <li><strong>中断:</strong> <ul> <li>I/O 中断。</li> <li>时钟中断 (用于时间片、计时器)。</li> <li>系统调用返回前。</li> <li>异常处理后。</li> </ul> </li> </ul> <p><strong>流程:</strong> 事件发生 → 暂停当前进程 → 硬件响应 → 进入内核处理事件 → 事件处理结束 (可能导致进程状态变化、就绪队列调整) → 执行进程调度 → 选择新进程运行。</p> <h3>2.5 调度过程：上下文切换 (Context Switching)</h3> <ul> <li><strong>定义:</strong> 将CPU的控制权从一个进程 (或线程) 转移给另一个进程 (或线程) 的过程。这涉及到保存当前进程的状态并加载新进程的状态。</li> <li><strong>上下文 (Context):</strong> 进程运行时，其执行状态 (硬件上下文) 保存在CPU的寄存器中 (如程序计数器PC, 程序状态字PSW, 栈指针SP, 通用寄存器等) 。进程不运行时，这些信息保存在其<strong>进程控制块 (PCB)</strong> 中。</li> <li><strong>主要工作:</strong> <ol> <li><strong>切换地址空间:</strong> 修改页目录寄存器 (如CR3 on x86) 以指向新进程的页表，加载新的虚拟地址空间。</li> <li><strong>切换内核栈和硬件上下文:</strong> <ul> <li>保存当前进程的寄存器值到其PCB或内核栈。</li> <li>从新进程的PCB或内核栈中恢复其寄存器值到CPU。</li> <li><strong>内核栈 (Kernel Stack):</strong> <ul> <li>每个进程都有自己的内核栈，用于在进程执行内核代码时存储函数调用、局部变量和上下文信息。</li> <li>当进程从用户态切换到内核态 (如系统调用、中断) 时，CPU会自动切换到该进程的内核栈。</li> <li>内核栈位于内核地址空间，对用户程序不可见，大小通常是固定的 (如 Linux 中为 8KB 或 16KB) 。</li> <li>内核栈的地址通常保存在进程的 PCB 中，在上下文切换时需要更新相关寄存器 (如栈指针) 指向新进程的内核栈。</li> </ul> </li> </ul> </li> </ol> </li> <li><strong>具体步骤 (进程A切换到进程B):</strong> <ol> <li>保存进程A的硬件上下文 (寄存器值) 。</li> <li>更新进程A的PCB (如状态改为就绪或阻塞，记录PC等) 。</li> <li>将进程A移入相应的队列 (就绪队列、等待队列) 。</li> <li>选择进程B作为下一个运行进程。</li> <li>更新进程B的PCB (状态改为运行) 。</li> <li>加载进程B的上下文 (恢复寄存器值，切换地址空间) 。</li> <li>开始执行进程B。</li> </ol> </li> <li><strong>XV6 Context Switch Example (<code>swtch.S</code>):</strong> (此处展示汇编代码逻辑，具体代码略) <ul> <li><code>swtch</code> 函数接受两个参数：旧进程上下文指针 (<code>old</code>) 和新进程上下文指针 (<code>new</code>)。</li> <li>它负责保存 <code>old</code> 进程的callee-saved寄存器到其上下文结构中。</li> <li>然后，从 <code>new</code> 进程的上下文结构中恢复callee-saved寄存器。</li> <li>最后，通过 <code>ret</code> 指令返回，此时CPU将跳转到 <code>new</code> 进程之前保存的PC地址， effectively switching execution flow. The key is switching the stack pointer.</li> </ul> </li> <li><strong>上下文切换开销 (Cost):</strong> <ul> <li><strong>直接开销:</strong> 内核执行切换操作所花费的CPU时间。 <ul> <li>保存和恢复寄存器。</li> <li>切换地址空间 (TLB Flush相关指令通常较昂贵) 。</li> <li>执行调度算法本身的代码。</li> </ul> </li> <li><strong>间接开销:</strong> 切换导致缓存性能下降。 <ul> <li><strong>CPU Cache 失效:</strong> 新进程的代码和数据不在缓存中，需要从内存加载。</li> <li><strong>TLB (Translation Lookaside Buffer) 失效:</strong> 地址翻译缓存失效，需要重新查询页表。</li> <li><strong>缓冲区缓存 (Buffer Cache) 可能失效:</strong> 文件系统相关的缓存可能对新进程无效。</li> </ul> </li> </ul> </li> </ul> <hr> <h2>3. 处理器调度算法的设计</h2> <h3>3.1 不同操作系统类型的调度目标</h3> <p>调度算法的选择与操作系统的主要应用场景和目标密切相关：</p> <ul> <li><strong>批处理系统 (Batch Systems):</strong> <ul> <li><strong>特点:</strong> 通常运行长任务，无需用户交互。</li> <li><strong>目标:</strong> <ul> <li><strong>高吞吐量 (Throughput):</strong> 单位时间内完成的作业数量最大化。</li> <li><strong>短周转时间 (Turnaround Time):</strong> 作业从提交到完成的总时间最小化。</li> <li><strong>高CPU利用率 (CPU Utilization):</strong> 让CPU尽可能处于忙碌状态。</li> </ul> </li> </ul> </li> <li><strong>交互式系统 (Interactive Systems):</strong> <ul> <li><strong>特点:</strong> 需要频繁与用户交互，用户等待输入。</li> <li><strong>目标:</strong> <ul> <li><strong>快速响应时间 (Response Time):</strong> 从用户输入命令到系统首次给出反馈的时间要短 (通常要求低于50-150ms) 。</li> <li><strong>均衡性 (Proportionality):</strong> 用户感觉系统性能稳定，符合预期。</li> </ul> </li> </ul> </li> <li><strong>实时系统 (Real-time Systems):</strong> <ul> <li><strong>特点:</strong> 任务有严格的时间限制 (截止时间, Deadline) 。</li> <li><strong>目标:</strong> <ul> <li><strong>满足最后期限 (Meeting Deadlines):</strong> 关键任务必须在规定时间内完成 (硬实时) 或尽可能满足 (软实时) 。</li> <li><strong>可预测性 (Predictability):</strong> 系统行为在时间上是确定的。</li> </ul> </li> </ul> </li> </ul> <h3>3.2 调度算法的设计考量</h3> <p>设计调度算法时，需在多个目标之间进行权衡 (Trade-off) ：</p> <ul> <li><strong>用户角度 (User-oriented):</strong> <ul> <li><strong>周转时间 (Turnaround Time):</strong> T(completion) - T(arrival)。进程从进入系统到完成的总时间。<strong>目标：最小化平均周转时间。</strong></li> <li><strong>响应时间 (Response Time):</strong> 从请求发出到第一次产生响应的时间。<strong>目标：最小化响应时间 (对交互式系统尤为重要) 。</strong></li> <li><strong>最后期限 (Deadline):</strong> 实时任务必须在规定时间前完成。<strong>目标：确保满足所有 (硬实时) 或重要 (软实时) 的截止时间。</strong></li> <li><strong>可预测性 (Predictability):</strong> 任务运行时间稳定，尤其对实时系统。</li> </ul> </li> <li><strong>系统角度 (System-oriented):</strong> <ul> <li><strong>吞吐量 (Throughput):</strong> 单位时间内完成的进程数量。<strong>目标：最大化吞吐量。</strong></li> <li><strong>CPU 利用率 (CPU Utilization):</strong> CPU忙于执行有效工作的时间百分比。<strong>目标：最大化CPU利用率。</strong></li> <li><strong>公平性 (Fairness):</strong> 各进程获得合理的CPU时间份额，防止饥饿。</li> <li><strong>均衡性 (Balance):</strong> 系统资源 (CPU, I/O设备等) 应保持忙碌，充分利用。</li> <li><strong>强制优先级 (Enforcing Priorities):</strong> 确保高优先级进程优先获得服务。</li> </ul> </li> </ul> <h3>3.3 调度算法的关键决策点</h3> <p>设计或选择调度算法时，需要考虑以下几个方面：</p> <ol> <li> <p><strong>进程优先级 (Priority):</strong></p> <ul> <li><strong>优先数:</strong> 用于表示优先级的数值 (数值越大优先级越高或越低，取决于系统定义) 。</li> <li><strong>静态优先级 (Static Priority):</strong> 进程创建时指定，运行期间不变。简单，但可能不适应进程行为变化。</li> <li><strong>动态优先级 (Dynamic Priority):</strong> 进程优先级在运行过程中可以调整。例如，可以提升长时间等待的进程的优先级 (老化, Aging) ，或降低长时间占用CPU进程的优先级。更能适应系统变化。</li> <li><strong>PCB记录:</strong> PCB中需要包含优先级信息。</li> </ul> </li> <li> <p><strong>就绪队列组织 (Ready Queue Organization):</strong></p> <ul> <li><strong>单一队列:</strong> 所有就绪进程放在一个队列中，按某种顺序 (如FCFS、优先级) 排列。</li> <li><strong>多级队列 (Multiple Queues):</strong> 按进程属性 (如优先级、类型) 划分多个队列。不同队列可采用不同调度策略。 <ul> <li><strong>按优先级排队:</strong> 每个优先级一个队列。调度器先服务高优先级队列。</li> <li><strong>按类型排队:</strong> 如前台 (交互) 进程队列、后台 (批处理) 进程队列。</li> </ul> </li> </ul> </li> <li> <p><strong>抢占 vs. 非抢占 (Preemptive vs. Non-preemptive):</strong></p> <ul> <li><strong>非抢占式 (Non-preemptive / 不可剥夺):</strong> 一旦进程获得CPU，它将一直运行，直到它自愿放弃 (完成、阻塞、<code>yield</code>) 。适用于批处理，简单，但响应性差。</li> <li><strong>抢占式 (Preemptive / 可剥夺):</strong> 当前运行的进程可以被更高优先级的就绪进程或时钟中断强制中断，CPU被分配给新进程。适用于交互式和实时系统，响应性好，但有上下文切换开销。</li> </ul> </li> <li> <p><strong>I/O密集型 vs. CPU密集型进程 (I/O-bound vs. CPU-bound):</strong></p> <ul> <li><strong>I/O密集型:</strong> 进程大部分时间在等待I/O操作完成，CPU计算时间短。</li> <li><strong>CPU密集型 (计算密集型):</strong> 进程大部分时间在进行CPU计算，很少I/O操作。</li> <li><strong>调度倾向:</strong> 现代系统通常倾向于优先调度I/O密集型进程，以保持I/O设备忙碌，提高系统整体吞吐量和响应性。让I/O进程尽快发出下一个I/O请求，然后在其等待时运行CPU密集型进程。</li> </ul> </li> <li> <p><strong>时间片 (Time Slice / Quantum):</strong></p> <ul> <li><strong>定义:</strong> 在抢占式调度 (特别是轮转RR) 中，分配给进程一次连续运行的最大CPU时间。</li> <li><strong>选择:</strong> 时间片大小的选择是一个重要的权衡： <ul> <li><strong>太长:</strong> 接近非抢占，长任务会阻塞短任务，交互式响应变慢。退化为FCFS。</li> <li><strong>太短:</strong> 频繁发生上下文切换，系统开销增大，有效工作比例下降。</li> <li><strong>合适的大小:</strong> 通常需要在几十到几百毫秒之间，取决于系统负载、CPU速度、上下文切换开销和对响应时间的要求。应略大于典型的一次交互所需CPU时间。</li> </ul> </li> <li><strong>固定 vs. 可变:</strong> 时间片可以是固定的，也可以根据进程优先级或行为动态调整。</li> </ul> </li> </ol> <hr> <h2>4. 典型的处理器调度算法</h2> <h3>4.1 批处理系统调度算法</h3> <p>主要目标：高吞吐量、低周转时间、高CPU利用率。</p> <ul> <li> <p><strong>先来先服务 (FCFS - First Come First Serve):</strong></p> <ul> <li><strong>策略:</strong> 按进程到达就绪队列的顺序进行调度。非抢占式。</li> <li><strong>优点:</strong> 公平 (按到达顺序) 、简单易实现。</li> <li><strong>缺点:</strong> <ul> <li>平均周转时间和平均等待时间可能很长，特别是当短进程排在长进程之后时 (护航效应, Convoy Effect) 。</li> <li>不利于I/O密集型进程 (长CPU进程运行时，I/O进程等待；I/O进程运行时，CPU空闲) 。</li> <li>对交互式用户不友好。</li> </ul> </li> <li><strong>例子:</strong> 进程P1(24s), P2(3s), P3(3s) 按 P1, P2, P3 顺序到达。 <ul> <li>执行顺序: P1 -> P2 -> P3</li> <li>完成时间: P1(24), P2(27), P3(30)</li> <li>周转时间: P1(24), P2(27), P3(30) -> 平均 27s</li> <li>若按 P2, P3, P1 顺序调度: <ul> <li>执行顺序: P2 -> P3 -> P1</li> <li>完成时间: P2(3), P3(6), P1(30)</li> <li>周转时间: P2(3), P3(6), P1(30) -> 平均 13s (显著改善)</li> </ul> </li> </ul> </li> </ul> </li> <li> <p><strong>最短作业优先 (SJF - Shortest Job First):</strong></p> <ul> <li><strong>策略:</strong> 选择预计运行时间最短的进程投入运行。</li> <li><strong>版本:</strong> <ul> <li><strong>非抢占式 SJF:</strong> 当前进程一直运行直到结束或阻塞。</li> <li><strong>抢占式 SJF (最短剩余时间优先, SRTN - Shortest Remaining Time Next):</strong> 当一个新进程到达，其预计总运行时间比当前进程的 <em>剩余</em> 运行时间还短时，抢占当前进程。</li> </ul> </li> <li><strong>优点:</strong> 理论上可证明，在所有进程同时到达时，SJF(非抢占)具有最低的平均周转时间。SRTN通常比非抢占SJF的平均周转时间更短。</li> <li><strong>缺点:</strong> <ul> <li><strong>需要预测未来:</strong> 如何准确知道进程的运行时间？通常基于历史数据进行估计，可能不准。</li> <li><strong>饥饿 (Starvation):</strong> 长进程可能永远得不到CPU，如果总有短进程到来。</li> <li><strong>不公平:</strong> 明显偏袒短进程。</li> </ul> </li> <li><strong>例子 (SRTN):</strong> | 进程 | 到达时刻 | 运行时间 | | :--- | :------- | :------- | | P1 | 0 | 7 | | P2 | 2 | 4 | | P3 | 4 | 1 | | P4 | 5 | 4 | <ul> <li>0: P1 运行 (剩余 7)</li> <li>2: P2 到达 (剩余 4) &#x3C; P1 (剩余 5)，P2 抢占 P1。P2 运行 (剩余 4)</li> <li>4: P3 到达 (剩余 1) &#x3C; P2 (剩余 2)，P3 抢占 P2。P3 运行 (剩余 1)</li> <li>5: P3 完成。P4 到达 (剩余 4)。比较 P1(剩余 5), P2(剩余 2), P4(剩余 4)。P2 剩余时间最短，P2 运行 (剩余 2)</li> <li>7: P2 完成。比较 P1(剩余 5), P4(剩余 4)。P4 剩余时间最短，P4 运行 (剩余 4)</li> <li>11: P4 完成。只剩 P1，P1 运行 (剩余 5)</li> <li>16: P1 完成。</li> <li>执行序列: P1(0-2) -> P2(2-4) -> P3(4-5) -> P2(5-7) -> P4(7-11) -> P1(11-16)</li> </ul> </li> </ul> </li> <li> <p><strong>最高响应比优先 (HRRN - Highest Response Ratio Next):</strong></p> <ul> <li><strong>策略:</strong> 综合考虑等待时间和运行时间，选择响应比最高的进程。非抢占式。</li> <li><strong>响应比 R = (等待时间 + 预计运行时间) / 预计运行时间 = 1 + (等待时间 / 预计运行时间)</strong></li> <li><strong>优点:</strong> <ul> <li>试图在SJF和FCFS之间取得平衡。</li> <li>短进程：预计运行时间小，响应比增长快，容易被选中 (类似SJF) 。</li> <li>长进程：等待时间足够长后，响应比会提高，最终能获得CPU，避免了饥饿。</li> </ul> </li> <li><strong>缺点:</strong> 仍需预测运行时间。计算响应比有额外开销。</li> <li><strong>抢占式HRRN?</strong> 理论上可以，但每次事件 (如新进程到达) 都需要重新计算所有就绪进程的响应比并排序，开销较大。</li> </ul> </li> </ul> <h3>4.2 交互式系统调度算法</h3> <p>主要目标：快速响应时间、均衡性、公平性。</p> <ul> <li> <p><strong>时间片轮转 (RR - Round Robin):</strong></p> <ul> <li><strong>策略:</strong> 将所有就绪进程按FCFS排成队列。调度器选择队首进程，分配一个时间片 (quantum) 。进程用完时间片后，若未完成或阻塞，则移到队尾。抢占式。</li> <li><strong>优点:</strong> <ul> <li>公平：每个进程都能获得运行机会。</li> <li>响应时间快：短进程能较快完成或得到响应。非常适合分时系统。</li> </ul> </li> <li><strong>缺点:</strong> <ul> <li>上下文切换开销：时间片过短会导致开销过大。</li> <li>性能与时间片长度密切相关。</li> <li>对周转时间不一定最优。对于运行时间相近的进程，RR的平均周转时间可能比FCFS差。</li> </ul> </li> <li><strong>例子 (时间片 q=20):</strong> P1(53), P2(8), P3(68), P4(24) <ul> <li>执行序列: P1(0-20) -> P2(20-28) -> P3(28-48) -> P4(48-68) -> P1(68-88) -> P3(88-108) -> P4(108-112) -> P1(112-125) -> P3(125-145) -> P3(145-153)</li> <li>平均等待时间 = ( (68-20)+(112-88) + (20-0) + (28-0)+(88-48)+(125-108) + (48-0)+(108-68) ) / 4 = (72 + 20 + 85 + 88) / 4 = 66.25 ms (假设到达时间为0)</li> </ul> </li> </ul> </li> <li> <p><strong>虚拟轮转 (Virtual RR - VRR):</strong></p> <ul> <li><strong>动机:</strong> RR对I/O密集型进程可能不公平。I/O进程经常在时间片未用完时就阻塞，返回就绪队列时排在队尾，下次获得CPU可能要等很久。</li> <li><strong>策略:</strong> 维护一个辅助就绪队列 (如AUX队列) 。当一个进程因I/O阻塞完成而返回时，不放入主RR队列尾部，而是放入AUX队列头部。调度器优先检查AUX队列，若非空则调度AUX队首进程，给其一个<strong>较短</strong>的时间片 (通常是其上次阻塞时剩余的时间片) ；若AUX队列为空，则按标准RR调度主队列。从AUX队列运行完时间片的进程回到主RR队列尾部。</li> <li><strong>目标:</strong> 给I/O密集型进程更多机会运行，提高I/O设备利用率。</li> </ul> </li> <li> <p><strong>优先级调度 (Priority Scheduling):</strong></p> <ul> <li><strong>策略:</strong> 选择就绪队列中优先级最高的进程运行。可以是抢占式或非抢占式。</li> <li><strong>优点:</strong> 实现简单，能满足不同进程的紧急程度需求 (如系统进程>用户进程，前台>后台，I/O型>CPU型) 。</li> <li><strong>缺点:</strong> <ul> <li><strong>饥饿:</strong> 低优先级进程可能永远无法运行。</li> <li><strong>优先级反转 (Priority Inversion):</strong> 一个低优先级进程持有高优先级进程所需的资源 (如锁) ，导致高优先级进程被迫等待低优先级进程。更糟的是，如果此时有一个中等优先级的CPU密集型进程就绪，它会抢占低优先级进程，使得高优先级进程的等待时间变得更长甚至不可预测。</li> </ul> </li> <li><strong>优先级反转解决方案:</strong> <ul> <li><strong>优先级继承 (Priority Inheritance):</strong> 当高优先级进程等待低优先级进程持有的资源时，暂时将低优先级进程的优先级提升到与高优先级进程相同，使其能尽快运行并释放资源。</li> <li><strong>优先级天花板协议 (Priority Ceiling Protocol):</strong> 给每个资源预设一个优先级上限 (等于可能使用该资源的所有进程中的最高优先级) 。当一个进程获得资源时，将其优先级提升到该资源的优先级上限。这能预防死锁并限制阻塞时间。</li> <li><strong>中断禁止:</strong> 在临界区执行期间禁止中断 (简单粗暴，在通用操作系统中通常不可取，但用于某些嵌入式或实时内核) 。</li> </ul> </li> </ul> </li> <li> <p><strong>多级队列调度 (Multilevel Queue Scheduling):</strong></p> <ul> <li><strong>策略:</strong> 将就绪队列划分为多个独立的队列，每个队列有自己的调度算法和优先级。例如： <ul> <li>系统进程队列 (最高优先级, RR 或 FCFS)</li> <li>交互式进程队列 (中优先级, RR)</li> <li>批处理进程队列 (最低优先级, FCFS)</li> </ul> </li> <li>调度器首先处理高优先级队列中的所有进程，然后才处理次高优先级队列，以此类推。队列之间通常是抢占式的 (高优先级队列进程可抢占低优先级队列进程) 。</li> <li><strong>优点:</strong> 灵活性高，可以为不同类型的进程定制调度策略。</li> <li><strong>缺点:</strong> 进程通常被固定分配到一个队列，缺乏灵活性；低优先级队列可能饥饿。</li> </ul> </li> <li> <p><strong>多级反馈队列调度 (Multilevel Feedback Queue Scheduling - MFQ):</strong></p> <ul> <li><strong>策略:</strong> 结合了多级队列和动态优先级调整。进程可以在不同队列之间移动。</li> <li><strong>典型实现:</strong> <ol> <li>设置多个优先级队列 (Q0, Q1, ..., Qn)，优先级 Q0 > Q1 > ... > Qn。</li> <li>不同队列分配不同的时间片长度，优先级越高的队列时间片越短 (如 Q0=q, Q1=2q, Q2=4q...) 。</li> <li>新进程进入最高优先级队列 Q0。</li> <li>调度器总是先运行最高非空队列中的进程，同队列内通常用RR。</li> <li>如果进程在一个队列中用完了其时间片但未完成，它会被 <strong>降级</strong> 到下一个较低优先级队列。</li> <li>如果进程在时间片未用完前因 <strong>阻塞</strong> (如等待I/O) 而放弃CPU，当它再次就绪时，通常会回到 <strong>原来的</strong> 队列 (或有时提升一级) ，以优待I/O密集型进程。(<strong>讨论点：</strong> 回到原队列还是队首/队尾？提升吗？具体策略不同系统可能不同。)</li> <li>最低优先级队列通常采用FCFS或很长的时间片RR。</li> <li>(可选) 可以加入 <strong>老化 (Aging)</strong> 机制：在低优先级队列等待过久的进程可以被提升到较高优先级队列，防止饥饿。</li> </ol> </li> <li><strong>优点:</strong> 非常灵活，能同时满足交互式 (响应快) 和批处理 (吞吐量) 的需求，能自动适应进程行为，是最常用的调度算法之一。</li> <li><strong>缺点:</strong> 设计和调优 (队列数量、时间片大小、升级降级策略) 比较复杂。</li> </ul> </li> <li> <p><strong>其他交互式算法 (简述):</strong></p> <ul> <li><strong>公平共享调度 (Fair-share Scheduling):</strong> 不仅考虑单个进程，还考虑进程所属的用户或用户组，确保CPU时间在用户/组之间公平分配。</li> <li><strong>保证调度 (Guaranteed Scheduling):</strong> 向用户承诺每个进程将获得 CPU 时间的 1/n (如果有n个进程) ，并跟踪进程实际获得的CPU时间，优先运行获得时间最少的进程。</li> <li><strong>彩票调度 (Lottery Scheduling):</strong> 给每个进程分配一定数量的“彩票”，调度器随机抽取一张彩票，持有该彩票的进程获得CPU。进程持有的彩票越多，获得CPU的机会越大。优先级可以通过分配不同数量的彩票来体现。简单，易实现概率公平。</li> </ul> </li> </ul> <h3>4.3 实时系统调度算法</h3> <p>主要目标：满足任务截止时间、可预测性。</p> <ul> <li> <p><strong>可调度性分析:</strong> 对于周期性实时任务，需要判断系统是否能在所有任务的截止时间内完成它们。</p> <ul> <li>若有 m 个周期任务，任务 i 的周期为 Pi，每次执行需 Ci 的CPU时间，则一个简单的 (充分非必要) 可调度条件是： <strong>Σ (Ci / Pi) ≤ 1</strong> (CPU利用率不超过100%)</li> <li>更精确的条件取决于具体算法 (如RM, EDF) 。</li> </ul> </li> <li> <p><strong>速率单调调度 (Rate-Monotonic Scheduling - RM):</strong></p> <ul> <li><strong>类型:</strong> 静态优先级，抢占式。</li> <li><strong>策略:</strong> 任务的优先级根据其 <strong>周期</strong> (Rate) 设定：周期越短 (频率越高) ，优先级越高。</li> <li><strong>适用:</strong> 周期性实时任务。</li> <li><strong>优点:</strong> 简单，理论成熟，可进行精确的可调度性分析 (Liu &#x26; Layland 条件：Σ(Ci/Pi) ≤ n(2^(1/n)-1))。</li> <li><strong>缺点:</strong> 仅适用于周期任务，对任务集利用率上限有要求 (不是100%)。</li> </ul> </li> <li> <p><strong>最早截止时间优先 (Earliest Deadline First - EDF):</strong></p> <ul> <li><strong>类型:</strong> 动态优先级，抢占式。</li> <li><strong>策略:</strong> 调度器在每次调度时，选择就绪队列中 <strong>绝对截止时间 (Deadline)</strong> 最早的任务运行。</li> <li><strong>适用:</strong> 周期性和非周期性实时任务。</li> <li><strong>优点:</strong> 理论上是最优的动态优先级算法，只要系统总利用率 ≤ 1，EDF就能找到一个可行的调度 (如果存在的话) 。CPU利用率上限可达100%。</li> <li><strong>缺点:</strong> 实现比RM复杂 (需要跟踪每个任务的截止时间) ，可能出现瞬时过载导致多米诺骨牌效应 (一个任务错过deadline可能导致后续任务都错过) 。</li> </ul> </li> </ul> <h3>4.4 各种调度算法比较总结</h3> <p>| 调度算法 | 选择依据 | 决策模式 | 吞吐量 | 响应时间 | 开销 | 对进程影响 | 饥饿问题 | | :----------- | :------------- | :----------- | :-------- | :-------------------------- | :------- | :--------------------------------- | :------------ | | <strong>FCFS</strong> | <code>max[w]</code> | 非抢占 | 不强调 | 可能很差 (长作业阻塞短作业) | 最小 | 对短进程/IO密集型不利 | 无 | | <strong>RR</strong> | 固定时间片 | 抢占(时间片) | q过小则低 | 短进程好 | 较小 | 公平 | 无 | | <strong>SJF</strong> | <code>min[s]</code> | 非抢占 | 高 | 短进程好 | 可能较高 | 对长进程不利 | 可能 | | <strong>SRTN</strong> | <code>min[s-e]</code> | 抢占(到达时) | 高 | 好 | 可能较高 | 对长进程不利 | 可能 | | <strong>HRRN</strong> | <code>max[(w+s)/s]</code> | 非抢占 | 高 | 较好 | 可能较高 | 平衡 | 无 | | <strong>Feedback</strong> | 见算法思想 | 抢占(时间片) | 不强调 | 较好 (可调优) | 可能较高 | 可优待IO密集型，可能对某些进程不利 | 可能 (需老化) |</p> <p><em>(表中 <code>w</code>: 等待时间, <code>s</code>: 总服务时间, <code>e</code>: 已执行时间)</em></p> <hr> <h2>5. 调度中的重要原则与实践</h2> <h3>5.1 机制与策略分离 (Mechanism vs. Policy Separation)</h3> <ul> <li><strong>原则:</strong> 将调度的具体实现 (<strong>机制</strong>，如何进行上下文切换、如何管理队列等) 与调度的决策逻辑 (<strong>策略</strong>，选择哪个进程运行、优先级如何确定等) 分离开。</li> <li><strong>为什么?</strong> <ul> <li><strong>灵活性:</strong> 更容易修改或替换调度策略，而无需改变底层机制。</li> <li><strong>可扩展性:</strong> 方便添加新的调度策略。</li> <li><strong>模块化:</strong> 代码结构更清晰，易于理解和维护。</li> </ul> </li> <li><strong>怎么做?</strong> 操作系统内核提供通用的调度框架 (机制，如优先级队列、上下文切换函数) ，而具体的调度算法 (策略) 作为可配置或可插拔的模块实现。例如，Linux 的 <code>sched_class</code> 结构就体现了这种思想。</li> </ul> <h3>5.2 线程调度 (Thread Scheduling)</h3> <ul> <li><strong>背景:</strong> 现代操作系统多数支持内核级线程。调度单元从进程变为线程。</li> <li><strong>用户级线程 vs. 内核级线程:</strong> <ul> <li><strong>用户级线程:</strong> 调度由用户空间的线程库管理，内核只看到一个进程。切换快，但一个线程阻塞会导致整个进程阻塞。无法利用多核。</li> <li><strong>内核级线程:</strong> 调度由内核管理，每个线程有自己的上下文。切换开销比用户级线程大，但比进程切换小。一个线程阻塞不影响其他线程。可以并发运行在多核上。</li> </ul> </li> <li><strong>调度对象:</strong> 内核调度器直接调度内核级线程。对于用户级线程，内核调度的是其所属的进程 (或承载用户线程的内核线程LWP) 。</li> </ul> <hr> <h2>6. 实例：操作系统调度算法</h2> <h3>6.1 典型系统采用的算法概览</h3> <ul> <li><strong>UNIX (早期):</strong> 动态优先级，基于nice值和CPU使用情况调整。</li> <li><strong>5.3BSD:</strong> 多级反馈队列算法。</li> <li><strong>Windows:</strong> 基于优先级的抢占式多任务调度 (细节见下) 。</li> <li><strong>Linux:</strong> 抢占式调度，主要使用CFS (普通进程) 和实时调度策略 (实时进程) (细节见下) 。</li> <li><strong>Solaris:</strong> 综合调度算法，支持多种调度类 (实时、分时、交互、系统等) 。</li> </ul> <h3>6.2 Windows 线程调度</h3> <ul> <li><strong>调度单位:</strong> 线程 (内核级线程)。</li> <li><strong>核心算法:</strong> 基于 <strong>动态优先级</strong> 的 <strong>抢占式</strong> 调度，结合 <strong>时间配额 (Quantum)</strong> 调整。</li> <li><strong>就绪队列:</strong> 维护多个优先级队列 (0-31) 。系统总是选择当前最高非空优先级队列中的线程运行。</li> <li><strong>同优先级调度:</strong> 同一优先级队列内部，线程按 <strong>时间片轮转 (RR)</strong> 方式调度。</li> <li>**多处理器:**允许多个线程在不同处理器上并行运行。</li> <li><strong>调度触发条件:</strong> <ul> <li>线程创建、终止。</li> <li>线程状态改变 (运行->阻塞, 阻塞->就绪, 运行->就绪) 。</li> <li>线程优先级改变。</li> <li>线程改变其处理器亲和性 (Affinity)。</li> <li>时间片用完。</li> <li>主动放弃 (<code>yield</code>)。</li> </ul> </li> <li><strong>线程优先级:</strong> <ul> <li>共32个优先级级别 (0-31)。</li> <li><strong>实时优先级 (16-31):</strong> 优先级固定不变。用于需要紧急响应的任务。最高。</li> <li><strong>可变优先级 (1-15):</strong> 线程有一个<strong>基本优先级 (Base Priority)</strong>，其<strong>当前优先级 (Current Priority)</strong> 可以在此基础上动态调整 (提升或降低) 。用于普通用户和系统线程。</li> <li><strong>系统线程 (1-15中的一部分):</strong> 用于操作系统内部任务。</li> <li><strong>零页线程 (0):</strong> 特殊线程，优先级最低，用于在系统空闲时将物理内存页清零。</li> </ul> </li> <li><strong>时间配额 (Quantum):</strong> <ul> <li>不是绝对时间值，而是以 <strong>配额单位 (quantum unit)</strong> 的整数表示。系统时钟中断时递减。</li> <li><code>Quantum</code> 和 <code>QuantumReset</code> 记录在 <code>KTHREAD</code> 结构中。</li> <li>当线程用完时间配额： <ul> <li>如果 <strong>没有</strong> 其他同优先级或更高优先级的线程就绪，Windows会 <strong>重新分配</strong> 一个新的时间配额给该线程，让它继续运行 (避免不必要的切换) 。</li> <li>如果 <strong>有</strong> 其他同优先级线程就绪，该线程移到其优先级队列的末尾，调度器选择下一个线程。</li> <li>如果用完时间配额 <strong>且</strong> 优先级被降低，则会被抢占。</li> </ul> </li> <li><strong>作用:</strong> 调整时间配额 (而非仅优先级) 可以影响进程获得CPU时间的比例，而不会完全饿死其他进程。例如，给前台游戏进程更大配额，使其运行更流畅，同时后台计算任务也能获得一些CPU时间。</li> </ul> </li> <li><strong>调度数据结构:</strong> <ul> <li>每个进程有默认优先级、亲和性、时间配额。</li> <li>每个线程有基本优先级、当前优先级、亲和性、时间配额。</li> <li><strong>Dispatcher Ready List:</strong> 包含32个就绪线程队列的数组。</li> <li><strong>KiDispatcherReadyListHead:</strong> 指向就绪队列的指针数组。</li> <li><strong>Ready Summary (就绪位图):</strong> 一个32位掩码，每一位对应一个优先级队列，指示该队列是否为空。调度器通过查找第一个置位的位 (Find First Set bit, FFS) 快速找到最高优先级的非空队列。</li> <li><strong>Idle Summary (空闲位图):</strong> (多处理器) 位图，指示哪些处理器当前处于空闲状态。</li> </ul> </li> <li><strong>调度策略细节:</strong> <ul> <li><strong>主动切换:</strong> 进程自愿放弃CPU (阻塞、Yield等) 。</li> <li><strong>抢占:</strong> <ul> <li>更高优先级的线程变为就绪。</li> <li>当前线程优先级降低，低于另一个就绪线程。</li> <li>被抢占线程放回其 <strong>原</strong> 优先级就绪队列的 <strong>队首</strong>。</li> <li>实时优先级线程被抢占，下次运行时获得完整时间配额。</li> <li>可变优先级线程被抢占，下次运行时继续执行剩余时间配额。</li> </ul> </li> <li><strong>时间配额用完:</strong> <ul> <li>优先级不降低：若队列无其他线程则重置配额继续，否则移到队尾。</li> <li>优先级降低：移到新优先级的队列，可能被抢占。</li> </ul> </li> </ul> </li> <li><strong>线程优先级提升 (Priority Boost):</strong> <ul> <li><strong>目的:</strong> 改善响应性、解决饥饿、提高吞吐量。仅针对可变优先级线程 (1-15)。</li> <li><strong>触发情况:</strong> <ol> <li><strong>I/O操作完成:</strong> 临时提升等待该I/O的线程优先级，幅度由设备驱动程序建议 (与设备响应要求相关) ，使其能快速处理数据。提升后时间配额会减1 (避免不公平利用I/O提升) 。</li> <li><strong>等待事件或信号量结束:</strong> 线程优先级提升1级 (不超过15) ，以补偿其等待时间。完成提升后的运行后，优先级会逐渐衰减回基本优先级。时间配额减1。</li> <li><strong>前台进程中的线程</strong> 完成等待操作。</li> <li>因 <strong>窗口消息</strong> (GUI活动) 而唤醒的线程。</li> <li><strong>反饥饿:</strong> 系统线程"平衡集管理器" (Balance Set Manager) 定期扫描，将等待过久 (如 > 300时钟中断) 的线程优先级提升到15，并给予4倍时间配额。用完后优先级立即恢复。</li> </ol> </li> </ul> </li> <li><strong>空闲线程 (Idle Thread):</strong> <ul> <li>每个处理器核都有一个对应的空闲线程。优先级为0。</li> <li>当没有其他可运行线程时，调度器调度空闲线程。</li> <li><strong>功能:</strong> 循环检测是否有工作要做：处理挂起的中断(DPCs)、检查是否有新就绪线程、调用HAL执行电源管理 (如让CPU进入低功耗状态) 。</li> </ul> </li> </ul> <h3>6.3 多处理器调度 (Multiprocessor Scheduling)</h3> <ul> <li><strong>特点:</strong> 系统包含多个CPU (核) ，可共享负载。</li> <li><strong>对称多处理 (SMP - Symmetric Multiprocessing):</strong> <ul> <li>所有CPU地位平等，都可以运行内核代码和用户进程。</li> <li>每个CPU通常有自己的调度器实例。</li> <li>调度器访问共享数据结构 (如就绪队列) 需要同步 (锁、原子操作) 。</li> </ul> </li> <li><strong>设计挑战:</strong> <ul> <li><strong>进程/线程分配:</strong> 决定哪个任务在哪个CPU上运行。</li> <li><strong>负载均衡 (Load Balancing):</strong> 使各CPU负载大致均匀，避免某些CPU过载而其他CPU空闲。</li> <li><strong>处理器亲和性 (Processor Affinity):</strong> 尽量让一个进程/线程连续在同一个CPU上运行，以利用CPU缓存 (L1/L2 cache) 中已加载的数据和TLB条目，减少缓存失效带来的开销。</li> <li><strong>缓存一致性 (Cache Coherence):</strong> 硬件机制 (如MESI协议) 确保多个CPU缓存中共享数据的副本是一致的。</li> </ul> </li> <li><strong>进程分配策略:</strong> <ul> <li><strong>静态进程分配 (Static Assignment):</strong> 进程从创建到结束都绑定在某个特定CPU上。每个CPU有自己的私有就绪队列。调度开销小，易于维护亲和性，但可能导致负载不均。</li> <li><strong>动态进程分配 (Dynamic Assignment):</strong> 进程可以在不同CPU之间迁移。通常有一个全局共享就绪队列，或各CPU有私有队列但允许任务迁移。负载均衡好，但调度开销大 (需要同步、迁移成本) 。</li> </ul> </li> <li><strong>多核处理器问题:</strong> <ul> <li><strong>缓存一致性:</strong> 如上所述，硬件解决。</li> <li><strong>缓存亲和性:</strong> 调度器需要考虑。让任务倾向于留在上次运行的核上。</li> <li><strong>核间数据共享:</strong> 需要高效的同步机制。</li> <li><strong>负载均衡:</strong> 需要策略在CPU间迁移任务。 <ul> <li><strong>缓存亲和性 vs. 负载均衡:</strong> 这是个权衡。过于强调亲和性可能导致负载失衡；过于频繁地迁移以追求负载均衡则会破坏缓存亲和性，增加开销。</li> <li><strong>例子:</strong> <ul> <li><strong>并行计算/渲染:</strong> 任务与数据绑定到核心可利用缓存，但计算量不均时需迁移任务以平衡负载，导致缓存失效。</li> <li><strong>CDN:</strong> 内容按地理位置缓存 (亲和性) ，但负载高时请求可能路由到其他节点 (破坏亲和性) 以均衡负载。</li> </ul> </li> <li><strong>工作窃取 (Work Stealing):</strong> 一种常见的负载均衡策略。每个CPU维护一个本地任务队列 (通常是双端队列) 。CPU优先执行自己队列的任务。当一个CPU空闲时，它会随机选择另一个CPU，并从其任务队列的 <strong>尾部</strong> “窃取” 一个任务来执行。 (被窃取的CPU从头部获取任务) 。 <ul> <li><strong>优点:</strong> 实现了负载均衡，同时本地任务优先执行保证了一定的缓存亲和性，分布式决策减少了中心瓶颈。</li> <li><strong>缺点:</strong> 仍有通信和同步开销。</li> <li><strong>实例:</strong> Go语言的GMP调度器，Java的ForkJoinPool，Hadoop YARN。</li> </ul> </li> </ul> </li> </ul> </li> </ul> <h3>6.4 实时调度 (Real-time Scheduling) (回顾)</h3> <ul> <li><strong>目标:</strong> 满足时间约束 (截止时间) ，高可靠性，确定性。</li> <li><strong>类型:</strong> 硬实时 (必须满足) vs. 软实时 (尽量满足)。周期性 vs. 偶发性 vs. 非周期性任务。</li> <li><strong>关键参数:</strong> 时间 (周期、执行时间、截止时间) 。</li> <li><strong>算法:</strong> RM (静态优先级, 周期短优先), EDF (动态优先级, 截止时间早优先)。</li> </ul> <h3>6.5 OpenEuler 多核调度技术 (简述)</h3> <ul> <li><strong>基础:</strong> CPU调度是为保证并发性，通过调度程序(Scheduler)按调度策略(Policy)选择进程占用CPU。</li> <li><strong>算法:</strong> 结合使用 FIFO, RR, 优先级调度 (用于实时进程) 。</li> <li><strong>普通进程:</strong> 主要采用 <strong>CFS (Completely Fair Scheduler)</strong> 算法，追求公平性，基于虚拟运行时间 (vruntime) 按优先级比例分配CPU时间。</li> <li><strong>多核调度:</strong> <ul> <li><strong>早期单队列问题:</strong> 所有CPU共享一个队列。 <ul> <li>策略一 (简单RR) ：进程在CPU间频繁迁移，破坏缓存亲和性。</li> <li>策略二 (带亲和性) ：尽量让进程留在一个CPU，但可能牺牲某些进程 (如E) 的公平性或导致负载失衡。</li> </ul> </li> <li><strong>多队列调度:</strong> 每个CPU维护自己的就绪队列 (如Q0 for CPU0, Q1 for CPU1) 。 <ul> <li><strong>优点:</strong> 提高缓存亲和性，减少锁竞争。</li> <li><strong>问题:</strong> 可能导致负载失衡 (如一个队列空了，另一个还很忙) 。</li> </ul> </li> <li><strong>迁移线程 (Migration Thread):</strong> OpenEuler 使用迁移线程解决负载不均衡。每个CPU有一个 <code>migration/CPUID</code> 内核线程。当检测到负载不均时 (如CPU0空闲，CPU1忙) ，CPU0可以向CPU1的停机工作队列 (stop machine workqueue) 添加一个任务，唤醒CPU1的迁移线程。该线程优先级很高，会立即执行迁移任务 (如将进程D从CPU1迁移到CPU0) ，从而实现负载均衡。</li> </ul> </li> </ul> <h3>6.6 Linux 进程调度</h3> <ul> <li> <p><strong>调度单位:</strong> 线程 (内核级线程，Linux中称为'进程'或'任务') 。</p> </li> <li> <p><strong>进程分类与调度策略:</strong></p> <ul> <li><strong>实时进程 (Real-time Processes):</strong> <ul> <li>要求：调度延迟最低，立即响应。</li> <li>策略：<code>SCHED_FIFO</code> (静态优先级，非抢占式，除非更高优先级到达或阻塞)、<code>SCHED_RR</code> (静态优先级，抢占式，带时间片轮转)。优先级范围 1-99。</li> </ul> </li> <li><strong>普通进程 (Normal Processes):</strong> <ul> <li>包括交互式进程 (需要快速响应) 和批处理进程 (后台运行，容忍延迟) 。</li> <li>策略：<code>SCHED_NORMAL</code> (也叫 <code>SCHED_OTHER</code>), <code>SCHED_BATCH</code>, <code>SCHED_IDLE</code>。主要由 <strong>CFS (Completely Fair Scheduler)</strong> 算法管理。优先级范围 100-139 (对应nice值 -20 到 +19)。</li> </ul> </li> </ul> </li> <li> <p><strong>Linux调度算法演化:</strong></p> <ul> <li><strong>Linux 2.4:</strong> 简单 O(n) 调度器。基于优先级和时间片。遍历整个运行队列找最高优先级进程。所有进程时间片用完后统一重新计算。对交互式进程通过剩余时间片补偿来提升优先级。<strong>缺点:</strong> 扩展性差 (高负载时慢) ，交互性优化不完善，非抢占内核。</li> <li><strong>Linux 2.6 (早期): O(1) 调度器 (by Ingo Molnar):</strong> <ul> <li>引入 active/expired 两个优先级数组队列。调度只需 O(1) 时间找到最高优先级非空队列。</li> <li>动态优先级基于静态优先级(nice值)和平均睡眠时间 bonus 计算，试图区分交互式/批处理。</li> <li>进程时间片用完后移入 expired 队列 (除非是特殊情况) 。active 队列空后，交换 active 和 expired 指针。</li> <li><strong>缺点:</strong> 区分交互式的启发式规则复杂难懂且易失效，代码难维护。</li> </ul> </li> <li><strong>Linux 2.6 (中期): SD (Staircase Scheduler by Con Kolivas) / RSDL (Rotating Staircase Deadline Scheduler):</strong> <ul> <li>追求公平，抛弃复杂动态优先级。</li> <li><strong>SD:</strong> 进程用完时间片后优先级降低一级 (下楼梯) ，到底后回到较高层并获更多时间片。交互进程睡眠时停留在高层，唤醒后响应快。</li> <li><strong>RSDL:</strong> 引入 group quota (Tg) 和 expired 数组。高优先级组用完 Tg 后整体降级 (minor rotation) ，保证低优先级任务的可预测等待时间。时间片用完进 expired 队列。active 队列空或到底后触发 major rotation (交换 active/expired)。</li> <li><strong>影响:</strong> 启发了CFS的公平思想。</li> </ul> </li> <li><strong>Linux 2.6.23 至今: CFS (Completely Fair Scheduler by Ingo Molnar):</strong> <ul> <li><strong>核心思想:</strong> 完全公平。理想情况下，每个进程获得 1/n 的CPU时间。不再区分交互式/批处理，不再使用固定时间片。</li> <li><strong>虚拟运行时间 (vruntime):</strong> <code>vruntime</code> 记录进程的加权运行时间。<code>vruntime</code> 增长速度与实际运行时间成正比，与进程权重 (优先级) 成反比。 <code>vruntime ≈ 实际运行时间 * (NICE_0_LOAD / 进程权重)</code> (NICE_0_LOAD 是 nice=0 进程的权重)。</li> <li><strong>调度决策:</strong> 总是选择就绪队列中 <strong><code>vruntime</code> 最小</strong> 的进程运行。</li> <li><strong>数据结构:</strong> 使用 <strong>红黑树 (Red-Black Tree)</strong> 存储就绪进程，按 <code>vruntime</code> 排序。插入、删除、查找最小节点都是 O(log n) 时间。调度器取最左节点运行。</li> <li><strong>公平性实现:</strong> 优先级高的进程权重高，<code>vruntime</code> 增长慢，更容易被选中；优先级低的进程权重低，<code>vruntime</code> 增长快。最终达到按权重比例分配CPU时间的效果。</li> </ul> </li> <li><strong>Linux 6.6+ (实验性/可选): EEVDF (Earliest Eligible Virtual Deadline First):</strong> <ul> <li>对CFS的改进，旨在解决CFS在极短任务和延迟敏感任务上的一些问题，进一步改善延迟和公平性。它结合了虚拟时间和截止时间的概念。</li> </ul> </li> </ul> </li> <li> <p><strong>CFS 调度器详解:</strong></p> <ul> <li> <p><strong><code>task_struct</code>:</strong> Linux 进程/任务描述符。</p> </li> <li> <p><strong><code>sched_entity</code>:</strong> 调度实体，嵌入 <code>task_struct</code> 中，包含CFS调度所需信息 (如 <code>load_weight</code> 权重, <code>rb_node</code> 红黑树节点, <code>vruntime</code> 等) 。一个 <code>sched_entity</code> 可以代表一个任务或一个任务组 (用于组调度) 。</p> </li> <li> <p><strong><code>sched_class</code>:</strong> 调度类结构体，定义了一套调度器操作函数接口 (如 <code>enqueue_task</code>, <code>dequeue_task</code>, <code>pick_next_task</code>) 。CFS, RT(FIFO/RR), Idle 都有自己的 <code>sched_class</code> 实现。内核按优先级顺序查询 <code>sched_class</code> 来决定使用哪个调度器。</p> </li> <li> <p><strong><code>cfs_rq</code>:</strong> CFS 运行队列，每个CPU有一个。包含红黑树 <code>tasks_timeline</code> 和 <code>min_vruntime</code> 等信息。<code>min_vruntime</code> 记录该队列中所有进程的最小 <code>vruntime</code>，作为新进程/唤醒进程 <code>vruntime</code> 计算的基准。</p> </li> <li> <p><strong>红黑树 (<code>rb_node</code>, <code>rb_root tasks_timeline</code>):</strong> 按 <code>vruntime</code> 组织就绪的 <code>sched_entity</code>。</p> </li> <li> <p><strong>CFS 关键情景:</strong></p> <ul> <li><strong>新进程创建 (<code>fork()</code>):</strong> <ul> <li><code>vruntime</code> 初始值通常设为当前 <code>cfs_rq->min_vruntime</code> (或略大) ，确保新进程不会立即获得过多优势。</li> <li><strong>父子 <code>vruntime</code> 交换?</strong> 如果设置了<code>sysctl_sched_child_runs_first</code>，且父子在同CPU，父<code>vruntime</code> &#x3C; 子<code>vruntime</code>，则交换，让子进程优先运行。</li> <li>插入红黑树。</li> <li>检查是否需要抢占当前进程。</li> </ul> </li> <li><strong>进程唤醒 (<code>wake_up_process()</code>):</strong> <ul> <li>调整 <code>vruntime</code>：通常设为 <code>max(waker->vruntime, cfs_rq->min_vruntime - delta)</code>，其中 <code>delta</code> 是一个小的补偿值。确保进程不会因睡眠获得不公平优势，但也给予一定补偿使其尽快运行。</li> <li>插入红黑树。</li> <li>检查是否需要抢占当前进程 (如果唤醒进程 <code>vruntime</code> 足够小) 。</li> </ul> </li> <li><strong>时钟中断 (<code>scheduler_tick()</code>):</strong> <ul> <li>更新当前运行进程的 <code>vruntime</code> (<code>actual_runtime * NICE_0_LOAD / weight</code>) 。</li> <li>更新 <code>cfs_rq->min_vruntime</code>。</li> <li>检查当前进程是否已运行超过其“理想运行时间” (基于调度周期和权重计算得出) 。如果是，则设置抢占标记 (<code>TIF_NEED_RESCHED</code>)，在中断返回前会调用 <code>schedule()</code>。</li> </ul> </li> <li><strong>主动调度 (<code>schedule()</code>):</strong> <ul> <li>当前进程阻塞、<code>yield</code> 或被标记抢占时调用。</li> <li>更新当前进程 <code>vruntime</code>。</li> <li>如果当前进程仍是就绪态，将其重新插入红黑树。</li> <li>调用 <code>pick_next_task()</code> 选择下一个运行进程： <ul> <li>按优先级查询 <code>sched_class</code> (RT -> CFS -> Idle)。</li> <li>CFS 中，通常选择红黑树最左节点 (<code>vruntime</code> 最小者) 。</li> <li>特殊情况：考虑 <code>cfs_rq->next</code> (上次被抢占者) 和 <code>cfs_rq->last</code> (刚运行完者) 的缓存亲和性，可能优先选择它们。</li> </ul> </li> <li>从红黑树中移除被选中进程的 <code>sched_entity</code>。</li> <li>执行上下文切换 (<code>context_switch()</code>)。</li> </ul> </li> </ul> </li> <li> <p><strong>CFS 与进程状态转换图示:</strong></p> <pre><code class="language-mermaid">graph TD New -- fork() --> Ready(Ready State: In Red-Black Tree); Ready -- schedule() selects --> Running(Running State); Running -- Block (I/O, wait) --> Blocked(Blocked State); Blocked -- Wakeup --> Ready; Running -- Timeslice Check in Tick / Preempted --> Ready; Running -- exit() --> Terminated(Terminated State); subgraph CFS Logic direction LR Ready -- select min vruntime --> Running; Running -- update vruntime &#x26; re-insert --> Ready; end </code></pre> </li> </ul> </li> </ul> <hr> <h2>7. 重点小结</h2> <ul> <li><strong>调度基本概念:</strong> 层次 (长/中/短程) 、时机、上下文切换 (过程、开销) 。</li> <li><strong>进程行为:</strong> I/O密集型 vs. CPU密集型。</li> <li><strong>设计目标:</strong> 吞吐量、周转时间、响应时间、公平性、实时性等，需权衡。</li> <li><strong>典型算法:</strong> <ul> <li>批处理: FCFS, SJF/SRTN, HRRN。</li> <li>交互式: RR, Priority (含反转问题), 多级队列, 多级反馈队列。</li> <li>实时: RM, EDF。</li> </ul> </li> <li><strong>关键设计点:</strong> 优先级 (静/动) 、队列组织、抢占、时间片。</li> <li><strong>核心原则:</strong> 机制与策略分离。</li> <li><strong>实例分析:</strong> Windows 线程调度 (优先级、时间配额、提升机制) 、Linux 进程调度 (演化、CFS核心思想、vruntime、红黑树) 。</li> <li><strong>多处理器调度:</strong> SMP、负载均衡、缓存亲和性、工作窃取。</li> </ul>https://www.lyt0112.com/blog/operating_systems_note_03-zhhttps://www.lyt0112.com/blog/operating_systems_note_03-zhOperating Systems Notes 03: 进程线程模型Thu, 27 Mar 2025 00:13:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>gemini-2.5-pro-preview-03-25</code></p> <p>This article uses LLM to improve efficiency, which can make mistakes. I have tried my best to check and proofread, but still cannot guarantee complete accuracy.</p> <p>For personal use, may be nagging for you.</p> <h2>1. 核心问题解答</h2> <ol> <li> <p><strong>怎样理解“进程是对CPU的抽象”这句话？</strong></p> <ul> <li><strong>解答：</strong> 物理CPU只有一个 (或有限个) ，但通过多道程序设计和操作系统的进程调度，可以让多个程序在宏观上“同时”运行。操作系统为每个运行的程序创建一个进程，并管理它们对CPU的使用 (分时复用) 。这使得每个进程都感觉自己仿佛独占了一个CPU (或一个虚拟CPU) 来执行自己的指令序列。因此，进程机制将一个或多个物理CPU虚拟化成了多个虚拟CPU，供多个程序并发执行，这是对CPU计算能力的抽象。</li> </ul> </li> <li> <p><strong>何谓进程映像？进程有实体吗？在哪里？</strong></p> <ul> <li><strong>解答：</strong> <strong>进程映像 (Process Image)</strong> 是指进程在执行时的完整状态描述，是进程实体的静态体现。它包括： <ul> <li><strong>程序代码 (Code Segment):</strong> 进程要执行的指令。</li> <li><strong>程序数据 (Data Segment):</strong> 程序使用的全局变量、静态变量等。</li> <li><strong>程序堆栈 (Stack):</strong> 用于函数调用、局部变量存储。</li> <li><strong>堆 (Heap):</strong> 动态分配内存的区域。</li> <li><strong>进程控制块 (PCB):</strong> 包含进程的所有管理信息 (状态、ID、寄存器值、资源列表等) 。</li> </ul> </li> <li><strong>进程是有实体的</strong>。它的实体就是进程映像所包含的内存区域 (代码、数据、堆栈、堆) 以及在操作系统内核中的数据结构 (PCB) 。这些实体主要存在于 <strong>内存</strong> 中 (代码、数据、堆栈、堆) 和 <strong>操作系统内核空间</strong> (PCB及其相关数据结构) 。当进程被挂起时，部分映像可能被交换到 **磁盘 (交换空间) ** 上。</li> </ul> </li> <li> <p><strong>怎样描述进程？一个进程都有什么 (组成要素) ？</strong></p> <ul> <li><strong>解答：</strong> 描述一个进程主要通过其 <strong>进程控制块 (PCB)</strong>。PCB是操作系统感知进程存在的唯一标志，包含了描述和控制进程运行所需的所有信息。</li> <li>一个进程的组成要素 (即进程映像) 包括： <ul> <li><strong>程序代码</strong></li> <li><strong>数据集合</strong> (全局变量、静态变量、动态分配的内存)</li> <li><strong>执行上下文</strong> (CPU寄存器值、程序计数器PC、程序状态字PSW、栈指针等)</li> <li><strong>进程控制块 (PCB)</strong> (包含进程标识符、状态、优先级、资源列表等)</li> </ul> </li> </ul> </li> <li> <p><strong>创建进程主要完成哪些工作？</strong></p> <ul> <li><strong>解答：</strong> 创建一个进程 (例如通过 <code>fork()</code> 或 <code>CreateProcess</code>) 主要包括： <ul> <li><strong>分配进程标识符 (PID):</strong> 给新进程一个唯一的ID。</li> <li><strong>创建和初始化进程控制块 (PCB):</strong> 分配PCB结构，并填入初始信息 (如PID、父进程ID、初始状态设为New或Ready、优先级等) 。</li> <li><strong>分配地址空间:</strong> 为进程分配独立的虚拟内存空间 (可能通过复制父进程空间或加载新程序) 。</li> <li><strong>加载程序和数据:</strong> 将可执行文件的代码和数据加载到进程的地址空间中 (<code>exec</code> 的工作) 。</li> <li><strong>初始化执行上下文:</strong> 设置PC指向程序入口，初始化栈指针和寄存器。</li> <li><strong>分配资源:</strong> 分配进程所需的其他资源 (如文件描述符，继承自父进程或新创建) 。</li> <li><strong>状态设置与调度:</strong> 将进程状态设置为就绪态 (Ready)，并将其链入就绪队列，等待调度器分配CPU。</li> </ul> </li> </ul> </li> <li> <p><strong>进程的生命周期内都会经历哪些变化？怎样表示这些变化？</strong></p> <ul> <li><strong>解答：</strong> 进程在其生命周期中会经历状态的转换。基本的状态包括： <ul> <li><strong>创建态 (New):</strong> 进程正在被创建。</li> <li><strong>就绪态 (Ready):</strong> 具备运行条件，等待CPU。</li> <li><strong>运行态 (Running):</strong> 正在CPU上执行。</li> <li><strong>等待态/阻塞态 (Waiting/Blocked):</strong> 等待某个事件 (如I/O完成) 而暂停执行。</li> <li><strong>终止态 (Terminated):</strong> 进程执行完毕或被终止，等待系统回收资源。</li> </ul> </li> <li>这些变化通常用 <strong>进程状态转换图</strong> 来表示，图中的节点代表状态，有向边代表状态之间的转换及其触发条件 (如调度、等待事件、事件完成等) 。</li> </ul> </li> <li> <p>**进程有哪些状态？进程状态之间的转换 (条件？操作？) **</p> <ul> <li><strong>解答：</strong> <ul> <li><strong>基本状态：</strong> 运行态 (Running)、就绪态 (Ready)、等待态 (Waiting/Blocked)。</li> <li><strong>其他状态：</strong> 创建态 (New)、终止态 (Terminated)。还可能引入挂起态 (Suspended Ready, Suspended Blocked)。</li> <li><strong>常见转换及条件/操作：</strong> <ul> <li><code>New -> Ready</code>: OS完成进程创建的必要工作，资源基本到位，允许参与调度。</li> <li><code>Ready -> Running</code>: 进程被调度器 (Scheduler) 选中，获得CPU使用权。<strong>操作：</strong> 上下文切换，恢复进程现场。</li> <li><code>Running -> Ready</code>: 时间片用完；或被更高优先级的进程抢占。<strong>操作：</strong> 上下文切换，保存进程现场。</li> <li><code>Running -> Waiting</code>: 进程请求I/O操作或等待某一资源/事件。<strong>操作：</strong> 进程主动调用阻塞原语 (e.g., <code>wait()</code>)，保存现场，移入等待队列。</li> <li><code>Waiting -> Ready</code>: 进程等待的事件发生或资源可用 (如I/O完成) 。<strong>操作：</strong> 中断处理程序或相关内核线程执行唤醒原语 (e.g., <code>wakeup()</code>)，将进程移入就绪队列。</li> <li><code>Running -> Terminated</code>: 进程正常执行完毕或出错退出。<strong>操作：</strong> 进程调用退出原语 (e.g., <code>exit()</code>)，进入终止态。</li> <li><code>Terminated -> Gone</code>: OS回收进程所占资源 (PCB、内存等) 。</li> </ul> </li> </ul> </li> </ul> </li> <li> <p><strong>进程状态转换的发生，是否一定导致另一个转换发生？</strong></p> <ul> <li><strong>解答：</strong> <strong>是的，通常是这样。</strong> 操作系统是一个动态系统，进程状态转换往往是相互关联的。 <ul> <li>例如，一个进程从 <strong>Running -> Waiting</strong>，会释放CPU，这使得调度器可以选择另一个处于 <strong>Ready</strong> 状态的进程，使其发生 <strong>Ready -> Running</strong> 的转换。</li> <li>一个进程从 <strong>Waiting -> Ready</strong> (如I/O完成)，它进入就绪队列，可能在未来某个时刻引发 <strong>Ready -> Running</strong> 的转换 (当它被调度时) 。</li> <li>一个进程 <strong>Running -> Terminated</strong>，会释放它占有的资源，这可能使得另一个 <strong>Waiting</strong> (等待该资源) 的进程变为 <strong>Ready</strong>。</li> </ul> </li> </ul> </li> <li> <p><strong>操作系统给进程提供内存空间，该空间的地址是虚拟地址还是物理地址？为什么？</strong></p> <ul> <li><strong>解答：</strong> 操作系统提供给进程的地址空间是 <strong>虚拟地址空间 (Virtual Address Space)</strong>。</li> <li><strong>原因：</strong> <ul> <li><strong>隔离与保护:</strong> 每个进程拥有独立的虚拟地址空间，一个进程无法直接访问另一个进程的内存，提供了安全保护。</li> <li><strong>地址空间扩展:</strong> 虚拟地址空间可以大于物理内存，借助内存管理单元(MMU)和磁盘交换空间，给进程提供更大的可用地址范围。</li> <li><strong>内存管理简化:</strong> 操作系统可以更灵活地管理物理内存，例如将非连续的物理内存页映射到连续的虚拟地址空间，简化了内存分配和程序加载。</li> <li><strong>程序加载和链接简化:</strong> 程序可以在编译链接时确定其在虚拟地址空间的布局，而无需关心实际加载到物理内存的哪个位置。</li> </ul> </li> </ul> </li> <li> <p><strong>操作系统如何描述进程的地址空间？</strong></p> <ul> <li><strong>解答：</strong> 操作系统内核通常使用特定的数据结构来描述进程的地址空间。例如： <ul> <li>在 <strong>Linux</strong> 中，使用 <code>mm_struct</code> 结构来表示一个进程的整个地址空间。<code>mm_struct</code> 内部包含一个 <code>vm_area_struct</code> (VMA) 的链表或树，每个 VMA 描述了虚拟地址空间中的一个连续区域 (段) ，包括其起止地址、访问权限 (读/写/执行) 、映射的文件 (如果有) 等信息。</li> <li>通过 <strong>页表 (Page Tables)</strong> 或 <strong>段表 (Segment Tables)</strong> 将虚拟地址映射到物理地址。这些表由硬件 (MMU) 使用，操作系统负责维护。</li> <li>可以通过 <code>cat /proc/&#x3C;PID>/maps</code> 命令查看一个进程的虚拟地址空间布局和 VMA 信息。需要将 <code>&#x3C;PID></code> 替换为实际的进程 ID (可通过 <code>ps</code> 命令查找)，否则会提示文件或目录不存在。</li> </ul> </li> </ul> </li> <li> <p><strong>为什么有了进程后又引入线程？</strong></p> <ul> <li><strong>解答：</strong> 引入线程主要是为了解决进程的以下不足： <ul> <li><strong>并发应用需求:</strong> 许多应用内部包含多个并发执行的任务 (如Web服务器处理多个请求，GUI程序响应用户输入同时后台处理) 。用多进程实现这些任务，开销较大且通信复杂。</li> <li><strong>开销问题:</strong> 创建进程、撤销进程、以及在进程间切换 (上下文切换) 都需要较大的时间和系统资源开销。线程作为“轻量级进程”，创建、销毁和切换的开销小得多。</li> <li><strong>通信效率:</strong> 同一进程内的线程共享地址空间和大部分资源，它们之间的通信 (通过共享内存) 非常高效，无需内核介入。进程间通信 (IPC) 通常需要内核的协调，更复杂且效率较低。</li> <li><strong>性能提升:</strong> 在多核处理器上，同一进程的多个线程可以真正并行执行在不同的核心上，提高应用程序的吞吐量。</li> </ul> </li> </ul> </li> <li> <p><strong>怎样实现线程机制？为什么有各种支持线程的方式？</strong></p> <ul> <li><strong>解答：</strong> 线程机制主要有三种实现方式： <ul> <li><strong>用户级线程 (User-Level Threads, ULT):</strong> 线程的管理 (创建、调度、同步) 完全在用户空间由一个线程库来完成。内核对线程无感知，只管理进程。 <ul> <li><strong>优点:</strong> 切换快 (不需内核模式) ，可自定义调度算法，可移植性好。</li> <li><strong>缺点:</strong> 一个线程阻塞 (如系统调用) ，整个进程会阻塞；无法利用多核并行。</li> </ul> </li> <li><strong>核心级线程 (Kernel-Level Threads, KLT):</strong> 线程的管理由操作系统内核完成。内核知道每个线程的存在，并进行调度。 <ul> <li><strong>优点:</strong> 一个线程阻塞不影响其他线程；可以利用多核并行。</li> <li><strong>缺点:</strong> 线程创建、销毁、切换需要进入内核，开销比ULT大。</li> </ul> </li> <li><strong>混合实现 (Hybrid Implementation):</strong> 结合了ULT和KLT。内核管理KLT，用户空间线程库将多个ULT映射到一个或多个KLT上。 <ul> <li><strong>目标:</strong> 兼具两者的优点，但实现复杂。</li> </ul> </li> </ul> </li> <li><strong>存在多种方式的原因：</strong> 是在性能、并发能力、实现复杂度、系统资源消耗之间进行权衡的结果。 <ul> <li>ULT优先考虑低开销和灵活性。</li> <li>KLT优先考虑真正的并发和对阻塞系统调用的处理。</li> <li>混合模型试图找到一个平衡点。</li> </ul> </li> </ul> </li> <li> <p><strong>线程包Pthreads中相关的函数的功能？</strong></p> <ul> <li><strong>解答:</strong> Pthreads (POSIX Threads) 是一个线程API标准，提供了一系列函数来管理线程： <ul> <li><code>pthread_create()</code>: 创建一个新的线程。</li> <li><code>pthread_exit()</code>: 终止调用该函数的线程。</li> <li><code>pthread_join()</code>: 等待指定的线程终止。</li> <li><code>pthread_yield()</code>: 主动让出CPU，让其他线程运行。</li> <li><code>pthread_self()</code>: 获取调用线程自身的线程ID。</li> <li><code>pthread_mutex_init()</code>, <code>pthread_mutex_lock()</code>, <code>pthread_mutex_unlock()</code>, <code>pthread_mutex_destroy()</code>: 互斥锁相关操作，用于保护临界区，实现线程互斥。</li> <li><code>pthread_cond_init()</code>, <code>pthread_cond_wait()</code>, <code>pthread_cond_signal()</code>, <code>pthread_cond_broadcast()</code>, <code>pthread_cond_destroy()</code>: 条件变量相关操作，用于线程间的同步 (等待某个条件满足) 。</li> </ul> </li> </ul> </li> <li> <p><strong>中断/异常机制与进程线程模型的关联？</strong></p> <ul> <li><strong>解答：</strong> 中断和异常是操作系统得以实现进程/线程调度和管理的关键机制。 <ul> <li><strong>上下文切换触发:</strong> 时钟中断 (Timer Interrupt) 使得操作系统可以剥夺当前运行进程/线程的CPU使用权 (时间片用完) ，进行调度，切换到其他就绪的进程/线程。这是实现分时复用的基础。</li> <li><strong>状态转换:</strong> I/O完成中断会通知操作系统，操作系统可以将等待该I/O的进程/线程从等待态转换为就绪态。</li> <li><strong>系统调用:</strong> 进程通过执行特定的指令 (如 <code>syscall</code> 或 <code>int 0x80</code>) 产生异常 (陷阱 Trap) ，主动陷入内核态，请求操作系统服务 (如创建进程、读写文件、阻塞等待) 。内核处理完请求后，可能会进行调度。</li> <li><strong>错误处理:</strong> 异常 (如除零、缺页故障 Page Fault) 也需要内核介入处理。缺页故障处理是虚拟内存管理的核心部分，可能导致进程阻塞 (等待页面从磁盘调入) 。</li> <li><strong>保存与恢复现场:</strong> 发生中断/异常时，硬件和操作系统内核协作，必须保存当前进程/线程的执行上下文 (寄存器、PC、状态等) ，处理事件后，再恢复某个进程/线程 (可能是同一个，也可能是不同的) 的上下文继续执行。</li> </ul> </li> </ul> </li> <li> <p><strong>机制和策略分离的原则在进程线程模型中的体现？</strong></p> <ul> <li>有点像操作系统提供的 API 和调用这些 API 的策略之间的关系</li> <li><strong>解答：</strong> 机制与策略分离 (Separation of Mechanism and Policy) 是操作系统设计的重要原则，意指提供实现某种功能的基础能力 (机制) ，与决定何时、如何使用这些能力的决策逻辑 (策略) 分开。 <ul> <li><strong>进程/线程状态管理 (机制) vs. 调度算法 (策略) ：</strong> 操作系统提供了进程/线程状态 (就绪、运行、等待等) 以及在它们之间转换的机制 (如阻塞/唤醒原语、上下文切换) 。但是，<strong>选择</strong> 哪个就绪进程/线程投入运行，则是调度算法 (策略) 决定的 (如FIFO、轮转、优先级调度等) 。</li> <li><strong>挂起/激活 (机制) vs. 负载调节 (策略) ：</strong> 操作系统提供将进程换出到磁盘 (挂起) 和换回内存 (激活) 的机制。但是，<strong>决定</strong> 何时挂起哪个进程 (例如，为了降低内存压力或提高系统吞吐量) ，则是系统负载调节策略的一部分。</li> <li><strong>线程实现 (机制) vs. 应用并发模型 (策略) ：</strong> 用户级线程库提供创建和管理线程的机制。应用程序<strong>如何</strong> 利用这些线程来构建并发逻辑 (例如，线程池大小、任务分配方式) 则是应用层面的策略。</li> </ul> </li> </ul> </li> <li> <p><strong>协程是什么？为什么引入协程？协程怎么用？</strong></p> <ul> <li><strong>解答：</strong> <ul> <li><strong>是什么：</strong> <strong>协程 (Coroutine)</strong> 是一种比线程更轻量级的用户态并发 (或协作式多任务) 实现方式。它们是可以在特定点暂停执行，并在稍后从同一点恢复执行的计算过程。协程之间的切换由程序员 (或协程库/语言运行时) 显式控制，通常发生在用户态，不需要内核介入。</li> <li><strong>为什么引入：</strong> <ul> <li><strong>极低的切换开销:</strong> 协程切换完全在用户态进行，避免了内核态和用户态之间的切换以及内核调度，开销远小于线程切换。</li> <li><strong>高并发能力:</strong> 单个线程可以管理成千上万个协程，特别适合处理大量并发连接 (如网络服务器) 或I/O密集型任务，能有效减少线程数量和内存消耗。</li> <li><strong>简化异步编程:</strong> 允许使用看似同步的代码风格来编写异步逻辑 (例如，使用 <code>async</code>/<code>await</code> 关键字) ，从而避免 <strong>回调地狱 (Callback Hell)</strong>。回调地狱是指在传统异步编程中，当一个操作依赖于另一个异步操作的结果时，需要将后续操作放在前一个操作的回调函数中，如果存在多层依赖，就会形成层层嵌套的回调函数结构，导致代码难以阅读、理解和维护。</li> </ul> </li> <li><strong>怎么用：</strong> 通常通过编程语言或第三方库提供的支持来使用。 <ul> <li><strong>语言原生支持:</strong> 如 Python (<code>async</code>/<code>await</code>), Go (<code>goroutine</code>), C++20 (<code>co_await</code>, <code>co_yield</code>, <code>co_return</code>), Rust (<code>async</code>/<code>await</code>)。</li> <li><strong>库支持:</strong> 通过特定的协程库在不支持原生协程的语言中使用。</li> <li><strong>用法:</strong> 开发者定义协程函数，在需要等待的操作 (通常是I/O) 前使用特定关键字 (如 <code>await</code> 或 <code>yield</code>) 暂停当前协程，让出执行权给其他协程或事件循环，当操作完成后，协程从暂停点恢复执行。</li> </ul> </li> </ul> </li> </ul> </li> </ol> <hr> <h2>2. 进程模型 (Process Model)</h2> <h3>2.1 基本概念</h3> <ol> <li> <p><strong>顺序程序与顺序环境 (Sequential Program &#x26; Environment)</strong></p> <ul> <li><strong>程序 (Program):</strong> 指令或语句的序列，体现某种算法，是静态的。</li> <li><strong>顺序环境:</strong> 系统中只有一个程序在运行，独占所有资源，执行不受外界干扰。</li> <li><strong>特征:</strong> <ul> <li><strong>顺序性:</strong> 指令严格按程序规定顺序执行。</li> <li><strong>封闭性:</strong> 程序运行时独占资源，不受外界干扰。</li> <li><strong>可再现性:</strong> 只要输入相同，程序执行结果总是相同，与速度无关。</li> </ul> </li> </ul> </li> <li> <p><strong>多道程序设计 (Multiprogramming)</strong></p> <ul> <li>允许多个程序 <strong>同时</strong> 进入内存并 <strong>交替</strong> 运行。</li> <li><strong>目的:</strong> 提高CPU利用率和系统整体效率。当一个程序等待I/O时，CPU可以切换去执行另一个程序。</li> </ul> </li> <li> <p><strong>并发环境与并发程序 (Concurrent Environment &#x26; Program)</strong></p> <ul> <li><strong>并发环境:</strong> 一段时间间隔内，单处理器上有两个或以上程序<strong>同时处于开始运行但尚未结束的状态</strong>，并且执行次序不确定。宏观上并行，微观上串行 (在单核CPU上) 。</li> <li><strong>并发程序:</strong> 在并发环境中执行的程序。</li> <li><strong>特征:</strong> <ul> <li><strong>间断性:</strong> 程序执行走走停停 (<code>执行 -> 停 -> 执行</code>)。</li> <li><strong>资源共享:</strong> 多个程序可能共享系统资源 (CPU、内存、I/O设备) 。</li> <li><strong>不可再现性:</strong> 由于执行走停的时机和顺序不确定，以及共享资源可能被修改，程序执行结果可能与执行速度有关，变得不可再现。</li> <li><strong>独立性与制约性:</strong> 程序各自独立运行，但也可能因共享资源或需要协作而相互制约。</li> <li><strong>程序与计算不再一一对应:</strong> 一个程序可能对应多次执行 (多个进程) ，一次执行也可能断续完成。</li> </ul> </li> </ul> </li> <li> <p><strong>进程 (Process)</strong></p> <ul> <li><strong>定义:</strong> <ul> <li>程序的一次执行过程。</li> <li>正在运行程序的抽象。</li> <li>操作系统进行 <strong>资源分配</strong> 和 <strong>调度</strong> 的 <strong>独立单位</strong>。</li> <li>具有独立功能的程序在某个数据集合上的一次运行活动。</li> </ul> </li> <li><strong>进程是对CPU的抽象:</strong> 如前所述，它将物理CPU虚拟化为多个逻辑CPU。</li> <li><strong>资源分配单位:</strong> 系统资源 (如内存、文件句柄) 以进程为单位进行分配。每个进程通常拥有独立的 <strong>地址空间</strong>。</li> <li><strong>调度单位:</strong> 操作系统将CPU时间片调度给进程 (或进程中的线程) 。</li> <li><strong>进程与程序的区别:</strong> <ul> <li><strong>动态 vs. 静态:</strong> 进程是动态的 (有生命周期) ，程序是静态的 (文件) 。</li> <li><strong>并发描述:</strong> 进程是描述并发的基本单位，程序不能。</li> <li><strong>生命周期:</strong> 进程是暂时的 (创建、运行、消亡) ，程序是相对长久的。</li> <li><strong>对应关系:</strong> 一个程序可以对应多个进程实例。</li> </ul> </li> </ul> </li> </ol> <h3>2.2 进程模型详解</h3> <ol> <li> <p><strong>进程状态 (Process States)</strong></p> <ul> <li><strong>三种基本状态:</strong> <ul> <li><strong>运行态 (Running):</strong> 进程占有CPU，并在CPU上运行。</li> <li><strong>就绪态 (Ready):</strong> 进程已具备运行条件 (资源到位) ，但因无空闲CPU而等待。</li> <li><strong>等待态 (Waiting/Blocked):</strong> 进程因等待某一事件 (如I/O完成、信号量) 而暂时不能运行。</li> </ul> </li> <li><strong>其他状态:</strong> <ul> <li><strong>创建态 (New):</strong> 进程正在被创建，OS已分配PCB，但尚未完成所有初始化或未被批准执行。</li> <li><strong>终止态 (Terminated):</strong> 进程已停止执行，等待OS回收资源。</li> <li><strong>挂起态 (Suspended):</strong> 进程映像被从内存移到外存 (磁盘) ，用于调节系统负载或用户请求。可以有 <strong>挂起就绪 (Suspended Ready)</strong> 和 <strong>挂起阻塞 (Suspended Blocked)</strong> 两种状态。</li> </ul> </li> </ul> </li> <li> <p><strong>进程状态转换模型 (State Transition Models)</strong></p> <ul> <li> <p><strong>三状态模型:</strong></p> <pre><code class="language-mermaid">graph LR Ready(就绪) --> |调度|Running(运行) Running --> |时间片到/高优先级进程抢占|Ready Running --> |等待事件|Waiting(阻塞) Waiting --> |事件发生|Ready </code></pre> </li> <li> <p><strong>五状态模型:</strong></p> <pre><code class="language-mermaid">graph LR New(创建) --> |提交|Ready(就绪) Ready --> |调度|Running(运行) Running --> |时间片到/高优先级进程抢占|Ready Running --> |等待事件|Waiting(阻塞) Waiting --> |事件发生|Ready Running --> |完成|Terminated(终止) </code></pre> </li> <li> <p><strong>七状态模型:</strong></p> <pre><code class="language-mermaid">graph LR New(创建) --> |提交|Ready(就绪) Ready --> |调度|Running(运行) Running --> |时间片到/高优先级进程抢占|Ready Running --> |等待事件|Waiting(阻塞) Waiting --> |事件发生|Ready Running --> |完成|Terminated(终止) Ready --> |挂起Suspend|SReady(就绪挂起) SReady --> |激活Activate|Ready Waiting --> |挂起Suspend|SWaiting(阻塞挂起) SWaiting --> |事件发生|SReady SWaiting --> |激活Activate|Waiting New --> |提交|SReady Running --> |挂起Suspend|SReady </code></pre> </li> <li> <p><strong>Linux 进程状态:</strong> 包括 <code>R (TASK_RUNNING)</code> (运行或就绪), <code>S (TASK_INTERRUPTIBLE)</code> (可中断睡眠), <code>D (TASK_UNINTERRUPTIBLE)</code> (不可中断睡眠), <code>T (TASK_STOPPED)</code> (停止), <code>Z (TASK_DEAD - ZOMBIE)</code> (僵尸) 等。其状态模型与理论模型有所差异，更贴近实现。</p> </li> <li> <p><strong>XV6 进程状态:</strong> <code>UNUSED</code>, <code>USED</code>, <code>SLEEPING</code>, <code>RUNNABLE</code>, <code>RUNNING</code>, <code>ZOMBIE</code>。这是一个简化的教学模型。</p> </li> <li> <p><strong>不同模型的意义:</strong> 体现了 <strong>机制和策略分离</strong>，基础状态转换是机制，增加挂起等状态是为了实现更复杂的内存管理和负载均衡策略。</p> </li> </ul> </li> <li> <p><strong>进程控制块 (Process Control Block, PCB)</strong></p> <ul> <li><strong>定义:</strong> 操作系统用于管理进程的核心数据结构，是进程存在的唯一标志。也称进程描述符。所有进程的PCB集合构成进程表。</li> <li><strong>作用:</strong> 保存进程状态、资源、上下文等信息，供OS进行调度和管理。</li> <li><strong>主要内容:</strong> <ul> <li><strong>进程描述信息:</strong> PID (唯一标识), 进程名, 用户ID (UID), 进程组关系。</li> <li><strong>进程控制信息:</strong> <ul> <li>当前状态 (State)。</li> <li>优先级 (Priority)。</li> <li>CPU现场信息 (Context): 程序计数器 (PC), 各种CPU寄存器, 程序状态字 (PSW), 栈指针 (SP)。<strong>这是进程切换时需要保存和恢复的关键信息。</strong></li> <li>调度相关信息 (如等待事件、时间片等)。</li> </ul> </li> <li><strong>所拥有的资源和使用情况:</strong> <ul> <li>虚拟地址空间描述 (指向页表/段表的指针)。</li> <li>打开文件列表。</li> <li>I/O设备信息。</li> </ul> </li> <li><strong>进程间通信与同步信息:</strong> 消息队列指针, 信号量等。</li> <li><strong>记账信息:</strong> CPU使用时间, 内存使用量等。</li> </ul> </li> <li><strong>具体实现:</strong> 不同OS有不同结构，如 Linux 的 <code>task_struct</code>, Windows 的 <code>EPROCESS</code>/<code>KPROCESS</code>/<code>PEB</code>, Solaris 的 <code>proc_t</code>。真实系统中的PCB结构非常庞大复杂。</li> </ul> </li> <li> <p><strong>进程地址空间 (Process Address Space)</strong></p> <ul> <li><strong>概念:</strong> 操作系统为每个进程分配的、独立的 <strong>虚拟内存</strong> 范围。是对内存的抽象。</li> <li><strong>典型布局 (从低地址到高地址):</strong> <ul> <li><strong>代码段 (.text):</strong> 存放程序指令，通常只读。</li> <li><strong>数据段 (.data, .bss):</strong> 存放已初始化的全局/静态变量 (.data) 和未初始化的全局/静态变量 (.bss)。</li> <li><strong>堆 (Heap):</strong> 动态内存分配区域 (<code>malloc</code>, <code>new</code>)，向上增长。</li> <li><strong>(文件映射区/共享库):</strong> 加载动态链接库、内存映射文件等。</li> <li><strong>栈 (Stack):</strong> 存放函数参数、局部变量、返回地址等，向下增长。</li> <li><strong>内核空间:</strong> 每个进程地址空间的高地址部分映射到操作系统的内核空间，供系统调用和中断处理使用 (用户态不可直接访问) 。</li> </ul> </li> <li><strong>独立性来源:</strong> 每个进程有自己的页表/段表，将相同的虚拟地址映射到不同的物理内存页 (或相同的只读页，如共享库代码) 。</li> <li><strong>写时复制 (Copy-on-Write, COW):</strong> <code>fork()</code> 创建子进程时，并不立即复制整个地址空间，而是让父子进程共享物理页面，并将页面标记为只读。当任何一方尝试写入时，触发异常，内核才真正复制该页面，使其私有化。这极大地优化了 <code>fork()</code> 的效率，特别是 <code>fork()</code> 后立即 <code>exec()</code> 的情况，因为<code>exec()</code>会替换整个地址空间，使得大部分共享页面在被写入前就已被丢弃，从而避免了不必要的复制开销。 <ul> <li><strong>COW异常的详细处理流程：</strong> <ol> <li><strong>写操作触发页面故障：</strong> 当父进程或子进程尝试写入共享的只读页面时，CPU检测到违反内存保护，触发页面故障异常(page fault)。</li> <li><strong>进入内核态：</strong> CPU立即切换到内核态，保存当前上下文，并跳转到页面故障处理程序。</li> <li><strong>异常处理：</strong> 内核的页面故障处理程序检查故障原因，发现是COW页面的写操作。</li> <li><strong>页面复制：</strong> 内核为写操作进程分配一个新的物理页框，将原共享页面的内容完整复制到新页框中。</li> <li><strong>页表更新：</strong> 修改发起写操作的进程的页表，将相关虚拟地址映射到新分配的物理页框，并设置为可写权限。</li> <li><strong>恢复执行：</strong> 内核返回用户态，恢复被中断的进程执行，此时写操作可以正常进行，且不会影响另一进程的内存视图。</li> </ol> </li> </ul> </li> <li><strong>查看:</strong> <code>cat /proc/&#x3C;PID>/maps</code> (Linux) 可以查看进程的虚拟内存区域布局。</li> </ul> </li> <li> <p><strong>进程队列 (Process Queues)</strong></p> <ul> <li>操作系统通常根据进程状态将PCB组织在不同的队列中。</li> <li><strong>就绪队列 (Ready Queue):</strong> 存放所有处于就绪态的进程PCB。调度器从中选择下一个要运行的进程。可能按优先级组织成多个队列。</li> <li><strong>等待队列 (Waiting Queues):</strong> 可能有多个，每个队列对应一个特定的等待事件 (如等待磁盘I/O、等待键盘输入、等待某个信号量) 。当进程等待某事件时，其PCB被移入相应的等待队列。</li> <li>进程状态的改变伴随着其PCB在不同队列间的移动。</li> </ul> </li> </ol> <h3>2.3 进程控制</h3> <h4>进程控制原语</h4> <p><strong>原语 (Primitive) <strong>是完成某种特定功能的一段程序，具有</strong>不可分割性</strong>或<strong>不可中断性</strong>，即原语的执行必须是连续的，在执行过程中不允许被中断，也称为**原子操作 (Atomic) **。</p> <p>进程控制操作完成进程各状态之间的转换，由具有特定功能的原语完成：</p> <ul> <li>进程创建原语</li> <li>进程撤销原语</li> <li>阻塞原语</li> <li>唤醒原语</li> <li>挂起原语</li> <li>激活 (解挂) 原语</li> <li>改变进程优先级原语</li> <li>等等</li> </ul> <h4>进程的生命周期</h4> <p><strong>进程创建的时机：</strong></p> <ul> <li>系统初始化时</li> <li>操作系统提供的服务</li> <li>交互用户登录系统</li> <li>由现有的进程派生出一个新进程</li> <li>提交一个程序执行 (例如，命令行)</li> </ul> <p><strong>进程终止的时机：</strong></p> <ul> <li>正常退出 (自愿的)</li> <li>出错退出 (自愿的)</li> <li>严重错误 (非自愿)</li> <li>被其他进程杀死 (非自愿)</li> </ul> <p><strong>进程终止的各种事件：</strong></p> <ul> <li>正常结束</li> <li>给定时限到</li> <li>缺少内存</li> <li>存储器出界</li> <li>保护性出错 (写只读文件)</li> <li>算术错误</li> <li>超出时间 (进程等待超过对某事件的最大值)</li> <li>I/O 失败</li> <li>无效指令 (如试图执行数据)</li> <li>特权指令</li> <li>操作系统干预 (如当死锁发生时)</li> <li>父进程请求中止某一子进程</li> <li>父进程中止 (子进程也中止)</li> </ul> <h4>进程控制操作</h4> <h5>进程的创建</h5> <p>进程创建的主要步骤：</p> <ul> <li>给新进程分配一个唯一标识(pid)以及进程控制块(PCB)</li> <li>为进程分配地址空间</li> <li>初始化进程控制块 <ul> <li>设置默认值 (如：状态为 New，...)</li> <li>设置相应的队列指针 (如：把新进程加到就绪队列的链表中)</li> </ul> </li> <li>创建或扩充其他数据结构</li> </ul> <p>不同操作系统的实现：</p> <ul> <li>UNIX：fork/exec</li> <li>WINDOWS：CreateProcess</li> </ul> <h5>进程的撤销</h5> <p>进程撤销的主要步骤：</p> <ul> <li>结束子进程或线程</li> <li>收回进程所占有的资源 <ul> <li>关闭打开的文件</li> <li>断开网络连接</li> <li>回收分配的内存等</li> </ul> </li> <li>撤销该进程的PCB</li> </ul> <p>不同操作系统的实现：</p> <ul> <li>UNIX：exit</li> <li>WINDOWS：ExitProcess</li> </ul> <h5>进程阻塞和进程唤醒</h5> <p>处于运行状态的进程，在其运行过程中期待某一事件发生 (如等待键盘输入、等待磁盘数据传输完成、等待其它进程发送消息) ，当被等待的事件未发生时，由进程自己执行阻塞原语，使自己由运行态变为阻塞态。</p> <p>不同操作系统的实现：</p> <ul> <li>UNIX：wait</li> <li>WINDOWS：WaitForSingleObject</li> </ul> <h5>UNIX系统设计的进程控制操作</h5> <p>UNIX系统提供了一系列系统调用来实现进程控制：</p> <ul> <li><strong>fork()</strong>: 通过复制调用进程来建立新的进程，是最基本的进程建立过程</li> <li><strong>exec()</strong>: 包括一系列系统调用，它们都是通过用一段新的代码覆盖原来的内存空间，实现进程执行代码的转换</li> <li><strong>wait()</strong>: 提供初级的进程同步措施，能使一个进程等待，直到另外一个进程结束为止</li> <li><strong>exit()</strong>: 用来终止一个进程的运行</li> </ul> <p>这些系统调用之间的关联 (shell、fork()、exec()、wait()) 体现了UNIX进程管理的设计哲学，通过简单而正交的原语组合实现复杂功能。</p> <h4>UNIX的fork()实现及优化</h4> <p>UNIX的fork()实现步骤：</p> <ul> <li>为子进程分配一个空闲的进程描述符 (proc结构)</li> <li>分配给子进程唯一标识pid</li> <li>以一次一页的方式复制父进程地址空间</li> <li>从父进程处继承共享资源，如打开的文件和当前工作目录等</li> <li>将子进程的状态设为就绪，插入到就绪队列</li> <li>对子进程返回标识符0</li> <li>对父进程返回子进程的pid</li> </ul> <p><strong>优化方案：</strong> Linux的解决方案是利用存储管理模块中的"写时复制技术"COW (Copy-On-Write) 对fork()进行了优化。</p> <h4>写时复制 (Copy-on-Write, COW) 技术</h4> <p>重新审视fork函数：</p> <ul> <li>虚拟内存和内存映射解释了fork如何为每个进程提供私有地址空间 <ul> <li>fork()后跟exec()的常见情况的完美方法</li> </ul> </li> <li>为新进程创建虚拟地址空间的步骤： <ul> <li>创建新的进程mm_struct、vm_area_struct、页表的精确副本</li> <li>将两个进程中的每个页面标记为只读</li> <li>将两个进程中的每个vm_area_struct标记为私有COW</li> <li>返回时，每个进程都有虚拟内存的精确副本</li> <li>后续写入使用COW机制创建新页面</li> </ul> </li> </ul> <hr> <h2>3. 线程模型 (Thread Model)</h2> <h3>3.1 线程的引入</h3> <ol> <li><strong>为什么引入线程？</strong> <ul> <li><strong>应用的需要:</strong> 一个应用程序内部往往有多个并发执行流的需求。例如： <ul> <li><strong>字处理软件:</strong> 用户输入 (前台线程) 、后台自动保存 (后台线程) 、拼写检查 (后台线程) 。</li> <li><strong>Web服务器:</strong> 主线程监听连接，每个连接分配一个工作线程处理请求 (读文件、网络发送) 。</li> </ul> </li> <li><strong>开销的考虑:</strong> <ul> <li>进程创建、销毁、切换的开销 (时间、空间) 较大。</li> <li>线程是轻量级的，其创建、销毁、切换开销小得多。</li> </ul> </li> <li><strong>性能的考虑:</strong> <ul> <li><strong>通信效率:</strong> 同一进程的线程共享地址空间和资源，通信 (共享内存) 非常高效，无需内核干预。</li> <li><strong>并行计算:</strong> 在多核CPU上，同一进程的多个线程可以真正并行执行。</li> </ul> </li> </ul> </li> </ol> <h3>3.2 线程的基本概念</h3> <ol> <li> <p><strong>线程 (Thread)</strong></p> <ul> <li>进程内的一个 <strong>执行实体 (或执行流)</strong>。</li> <li>是 <strong>CPU调度</strong> 的基本单位。</li> <li>有时称为 <strong>轻量级进程 (Lightweight Process, LWP)</strong>。</li> <li>进程现在被视为 <strong>资源分配</strong> 的基本单位。</li> </ul> </li> <li> <p><strong>线程的属性:</strong></p> <ul> <li><strong>拥有独立的状态:</strong> (Running, Ready, Blocked等)，需要进行状态转换管理。</li> <li><strong>拥有独立的执行上下文:</strong> 程序计数器 (PC), 寄存器集合, 栈 (Stack) 和栈指针 (SP)。<strong>线程切换时保存/恢复的是这部分私有上下文。</strong></li> <li><strong>共享所在进程的资源:</strong> <ul> <li>地址空间 (代码段、数据段、堆) 。</li> <li>打开的文件。</li> <li>全局变量。</li> <li>信号处理器等。</li> </ul> </li> <li><strong>可以创建、撤销、同步其他线程。</strong></li> </ul> </li> <li> <p><strong>多线程进程模型:</strong> 一个进程包含一个PCB和<strong>多个线程控制块 (Thread Control Block, TCB)</strong>。所有TCB共享进程的地址空间和资源，但每个TCB有自己独立的PC、寄存器和栈。</p> </li> </ol> <h3>3.3 线程的实现</h3> <ol> <li> <p><strong>用户级线程 (User-Level Threads, ULT)</strong></p> <ul> <li><strong>实现:</strong> 在用户空间通过线程库实现，内核对线程无感知。线程调度由库函数完成。</li> <li><strong>优点:</strong> <ul> <li>创建、销毁、切换非常快 (不涉及内核模式切换) 。</li> <li>调度算法可以由应用程序定制。</li> <li>可以运行在不支持线程的操作系统上 (只需有线程库) 。</li> </ul> </li> <li><strong>缺点:</strong> <ul> <li><strong>阻塞问题:</strong> 如果一个用户级线程执行了阻塞式系统调用，整个进程都会被内核阻塞，即使其他线程是就绪的。</li> <li><strong>多核利用问题:</strong> 内核只把CPU分配给进程，所以一个进程中的多个ULT不能在多核上并行执行。</li> </ul> </li> <li><strong>阻塞处理:</strong> <ul> <li>使用非阻塞系统调用。</li> <li>使用 "Jacketing" / "Wrapper" 技术：库函数在调用可能阻塞的系统调用前检查，如果会阻塞，则不调用，而是切换到另一个用户线程。</li> </ul> </li> </ul> </li> <li> <p><strong>核心级线程 (Kernel-Level Threads, KLT)</strong></p> <ul> <li><strong>实现:</strong> 线程的管理 (创建、调度、同步) 由操作系统内核完成。内核维护每个线程的TCB。</li> <li><strong>优点:</strong> <ul> <li>一个线程阻塞不影响进程内其他线程的执行。</li> <li>内核可以直接调度线程，可以在多核CPU上实现真正的并行。</li> </ul> </li> <li><strong>缺点:</strong> <ul> <li>线程的创建、销毁、切换都需要进入内核态，开销比ULT大 (但仍远小于进程切换) 。</li> </ul> </li> <li><strong>例子:</strong> Windows 线程, Linux 的 NPTL (Native POSIX Thread Library，实际上是KLT)。</li> </ul> </li> <li> <p><strong>混合模型 (Hybrid Implementation)</strong></p> <ul> <li><strong>实现:</strong> 内核支持KLT，用户空间线程库将多个ULT映射到少量KLT上 (M:N模型) 。线程创建在用户态快，调度利用内核。</li> <li><strong>例子:</strong> 早期的 Solaris。</li> <li><strong>目标:</strong> 试图结合ULT的低开销和KLT的并发优势，但实现复杂，现在较少见，Linux和Windows都主要采用KLT模型。</li> </ul> </li> </ol> <hr> <h2>4. 协程 (Coroutine)</h2> <ol> <li> <p><strong>为什么引入协程？</strong></p> <ul> <li>为了在单线程内实现更高效率的并发，尤其是针对 I/O 密集型任务和需要管理大量连接的场景。</li> <li>解决线程在高并发场景下的资源消耗 (内存、内核调度开销) 问题。</li> <li>用同步的方式编写异步代码，提高可读性。</li> </ul> </li> <li> <p><strong>协程是什么？</strong></p> <ul> <li>一种 <strong>用户态的、协作式</strong> 的多任务实现。</li> <li>可以看作是比线程更轻量级的执行单元，由 <strong>程序员/运行时</strong> 在 <strong>用户态</strong> 控制切换。</li> <li>协程可以在执行过程中的特定点 <strong>暂停 (yield)</strong>，然后在未来从同一点 <strong>恢复 (resume)</strong>。</li> </ul> </li> <li> <p><strong>协程怎么用？</strong></p> <ul> <li>依赖于 <strong>编程语言或库</strong> 的支持。</li> <li><strong>常见模式:</strong> <ul> <li>定义协程函数 (如 Python 的 <code>async def</code>) 。</li> <li>在协程函数内部，遇到需要等待的操作 (如异步I/O) 时，使用特定关键字 (如 <code>await</code>, <code>yield</code>) 主动让出控制权。</li> <li>一个事件循环 (Event Loop) 或调度器负责管理协程的暂停和恢复。</li> </ul> </li> <li><strong>例子:</strong> Python <code>asyncio</code>, Go <code>goroutine</code>, C++20 <code>coroutine</code>, Rust <code>async/await</code>。</li> </ul> </li> <li> <p><strong>纤程 (Fiber)</strong></p> <ul> <li>Windows 操作系统提供的一种类似协程的机制，也是用户态调度的轻量级执行单元，一个线程内可以包含多个纤程。</li> </ul> </li> </ol> <hr> <h2>5. 重点小结</h2> <ul> <li><strong>进程 (Process):</strong> <ul> <li>并发执行程序的实例，动态产生和消亡。</li> <li>OS <strong>资源分配</strong> 的独立单位，拥有独立地址空间。</li> <li>基本特征：并发性、动态性、独立性、制约性、异步性。</li> <li><strong>进程映像</strong> = 代码 + 数据 + 栈 + 堆 + PCB。</li> </ul> </li> <li><strong>线程 (Thread):</strong> <ul> <li>进程内的一个执行流，<strong>CPU调度</strong> 的基本单位。</li> <li>拥有私有执行上下文 (PC, Regs, Stack) ，共享进程资源 (地址空间, 文件) 。</li> <li>引入原因：应用并发需求、低开销、高性能 (通信、并行) 。</li> <li>实现方式：用户级 (ULT)、核心级 (KLT)、混合。各有优劣。</li> </ul> </li> <li><strong>协程 (Coroutine):</strong> <ul> <li>用户态协作式多任务单元，比线程更轻量。</li> <li>切换开销极低，适合高并发I/O密集型任务。</li> <li>通过语言/库支持，用同步方式写异步代码。</li> </ul> </li> <li><strong>可再入程序 (Reentrant Program):</strong> <ul> <li>可被多个进程同时调用的程序。</li> <li>特点：纯代码 (执行中不修改自身) ，不使用静态/全局变量存储可变状态 (或通过参数传入/线程本地存储) 。</li> </ul> </li> </ul>https://www.lyt0112.com/blog/operating_systems_note_02-zhhttps://www.lyt0112.com/blog/operating_systems_note_02-zhOperating Systems Notes 02: 中断异常机制Thu, 13 Mar 2025 04:20:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>claude-3-7-sonnet-20250219</code></p> <p>This article uses LLM to improve efficiency, which can make mistakes. I have tried my best to check and proofread, but still cannot guarantee complete accuracy.</p> <p>For personal use, may be nagging for you.</p> <h2>1. 核心问题解答</h2> <ol> <li> <p>应用程序是如何与操作系统交互的？</p> <ul> <li>应用程序通过系统调用与操作系统交互。系统调用提供了应用程序访问操作系统服务的接口，例如文件操作、进程管理和内存管理等。</li> </ul> </li> <li> <p>怎样理解“操作系统是由中断/异常/事件驱动的“这句话？</p> <ul> <li>这句话的意思是操作系统的运行依赖于中断、异常和事件的触发。中断和异常是硬件或软件产生的信号，通知操作系统需要处理的事件。操作系统通过响应这些信号来管理系统资源和执行任务。</li> </ul> </li> <li> <p>中断/异常的来源有什么不同？处理方式是一样的吗？</p> <ul> <li>中断通常由外部设备 (如键盘、鼠标、网络接口等) 产生，而异常通常由CPU在执行指令时检测到的错误 (如除零错误、非法指令等) 产生。处理方式有所不同，中断处理程序通常较为简单，主要负责响应外部设备的请求，而异常处理程序则需要更复杂的错误处理机制。</li> </ul> </li> <li> <p>回顾一下：ICS对异常的描述及分类</p> <ul> <li>ICS (计算机系统结构) 将异常分为四类：陷入 (Trap) 、故障 (Fault) 、终止 (Abort) 和中断 (Interrupt) 。陷入是由用户程序主动发起的系统调用，故障是可恢复的错误，终止是不可恢复的错误，中断是由外部设备发起的请求。</li> </ul> </li> <li> <p>中断/异常处理流程中，哪些工作是硬件 (体系结构) 负责的？哪些工作是软件 (操作系统) 负责的？</p> <ul> <li>硬件负责检测中断/异常、保存当前的处理器状态、查找中断向量表并跳转到相应的中断/异常处理程序。软件负责具体的中断/异常处理逻辑，包括错误处理、资源管理和恢复系统状态等。</li> </ul> </li> <li> <p>从中断响应 (硬件) 到中断处理程序 (软件) 执行结束，计算机系统经过了哪些流程？</p> <ul> <li>计算机系统首先由硬件检测到中断信号，保存当前处理器状态，查找中断向量表并跳转到中断处理程序。中断处理程序执行相应的处理逻辑，处理完成后恢复处理器状态，返回到中断前的执行点继续执行。</li> </ul> </li> <li> <p>操作系统初始化与中断/异常有哪些关联？</p> <ul> <li>操作系统初始化时会设置中断向量表、初始化中断控制器、注册中断/异常处理程序等。中断/异常机制是操作系统正常运行的重要保障。</li> </ul> </li> <li> <p>什么是软件异常？它是如何工作的？</p> <ul> <li>软件异常是由软件引发的异常情况，例如非法内存访问、除零错误等。软件异常通过硬件检测并触发相应的异常处理程序，操作系统负责处理这些异常并采取相应的措施，如终止进程、生成错误报告等。</li> </ul> </li> <li> <p>X86有哪些控制和状态寄存器？所起的作用是什么？</p> <ul> <li>X86处理器有多个控制和状态寄存器，包括CR0-CR4 (控制寄存器) 、EFLAGS (状态寄存器) 、GDTR/IDTR (全局/中断描述符表寄存器) 等。控制寄存器用于控制处理器的操作模式，状态寄存器保存处理器的状态标志，描述符表寄存器用于存储全局和中断描述符表的地址。</li> </ul> </li> <li> <p>X86在PentiumII 300之后提供了sysenter/sysexit指令，为什么？与int 0x80/iret有什么不同？X86-64提供的系统调用指令是什么？</p> <ul> <li>sysenter/sysexit指令提供了更高效的系统调用机制，减少了系统调用的开销。与int 0x80/iret相比，sysenter/sysexit指令不需要保存和恢复中断标志，减少了上下文切换的开销。X86-64提供的系统调用指令是syscall/sysret。</li> </ul> </li> <li> <p>关于基于x86体系结构的Linux的系统调用实现：</p> </li> </ol> <ul> <li>系统调用入口程序system_call()与中断描述符表是什么关系？与系统调用表是什么关系？ <ul> <li>system_call()是系统调用的入口程序，通过中断描述符表 (IDT) 中的中断向量指向。系统调用表 (sys_call_table) 存储了所有系统调用的地址，system_call()根据系统调用号查找并调用相应的系统调用处理程序。</li> </ul> </li> <li>系统调用处理结束后，处理器转去执行哪个模块？ <ul> <li>系统调用处理结束后，处理器会返回到用户态，继续执行被中断的用户程序。</li> </ul> </li> </ul> <ol start="12"> <li>系统调用与函数/过程调用的区别是什么？系统调用与C函数调用的区别？系统调用与API的关系？ <ul> <li>系统调用是操作系统提供的接口，用于应用程序请求操作系统服务。函数/过程调用是程序内部的调用机制。系统调用与C函数调用的区别在于系统调用需要从用户态切换到内核态，而C函数调用在用户态内执行。API (应用程序编程接口) 是应用程序与操作系统或库函数之间的接口，系统调用是API的一部分，提供底层操作系统服务。</li> </ul> </li> </ol> <p><strong>关键核心：ECF——异常控制流</strong></p> <p>理解ECF (异常控制流) 是深入理解计算机系统和操作系统交互的关键。</p> <ol> <li> <p><strong>理解应用程序是如何与操作系统交互的</strong>：</p> <ul> <li>ECF描述了应用程序在运行过程中如何通过系统调用、中断和异常与操作系统进行交互。通过理解ECF，可以更好地理解操作系统如何管理硬件资源和提供服务。</li> </ul> </li> <li> <p><strong>编写有趣的新应用程序</strong>：</p> <ul> <li>通过掌握ECF的原理，开发者可以编写更高效、更可靠的应用程序。理解系统调用和异常处理机制，可以帮助开发者优化程序性能，并处理各种异常情况。</li> </ul> </li> <li> <p><strong>理解并发</strong>：</p> <ul> <li>ECF在并发编程中起着重要作用。通过理解中断和异常的处理流程，可以更好地设计和实现多线程、多进程的并发程序，确保程序的正确性和高效性。</li> </ul> </li> <li> <p><strong>理解软件异常如何工作</strong>：</p> <ul> <li>软件异常是ECF的重要组成部分。通过理解软件异常的触发和处理机制，可以更好地调试和维护程序，提升程序的稳定性和安全性。</li> </ul> </li> </ol> <hr> <h2>2. 中央处理器(CPU)</h2> <h3>2.1 关于寄存器</h3> <p>处理器由运算器、控制器、寄存器及高速缓存构成：</p> <p><strong>用户可见寄存器</strong>：</p> <ul> <li>机器语言可以直接访问</li> <li>数据寄存器(通用寄存器)</li> <li>地址寄存器</li> <li>条件码寄存器：保存CPU操作结果的标记位</li> </ul> <p><strong>控制和状态寄存器</strong>：</p> <ul> <li>用于控制处理器操作，在特权级别下可访问</li> <li>程序计数器(PC, Program Counter)</li> <li>指令寄存器(IR, Instruction Register)</li> <li>程序状态字(PSW, Program Status Word)：存储处理器当前运行状态的关键寄存器，包含多种重要信息： <ul> <li>条件码标志位：如零标志(Zero)、进位标志(Carry)、溢出标志(Overflow)等，反映算术和逻辑运算的结果</li> <li>中断控制位：控制处理器对中断的响应方式，如中断使能/禁止标志</li> <li>处理器模式位：指示当前CPU运行在什么特权级别(如用户态/内核态)</li> <li>内存管理相关标志：如分页模式、虚拟内存使能等 PSW在进程上下文切换和中断处理过程中会被保存和恢复，是操作系统实现特权保护和进程隔离的核心机制。</li> </ul> </li> </ul> <h3>2.2 操作系统的需求之一 —— 保护</h3> <h4>从操作系统的特征考虑</h4> <p>操作系统需要处理并发和共享资源的问题，这就提出了对系统进行保护与控制的要求。为了实现这一点，操作系统依赖于硬件机制来隔离操作系统和用户程序。</p> <h4>硬件机制的支持</h4> <p>为了实现保护，硬件需要提供基本的运行机制：</p> <ol> <li> <p><strong>处理器的不同运行模式</strong>：</p> <ul> <li>处理器具有不同的运行模式，每种模式下运行的指令集合不同，这些模式被称为特权级别。</li> <li>通过特权级别，处理器可以区分内核态和用户态，从而控制哪些指令可以在特定模式下执行。</li> </ul> </li> <li> <p><strong>特权级别</strong>：</p> <ul> <li>特权级别决定了处理器可以执行哪些指令以及访问哪些资源。</li> <li>在高特权级别 (如内核态) ，处理器可以执行所有指令并访问所有资源。</li> <li>在低特权级别 (如用户态) ，处理器只能执行非特权指令，访问受限的资源。</li> </ul> </li> </ol> <p>通过这些硬件机制，操作系统能够有效地保护自身不被用户程序破坏，同时也能控制用户程序的行为，确保系统的稳定和安全。</p> <h3>2.3 处理器的状态(模式)</h3> <p>现代处理器通常将CPU状态划分为两种、三种或四种，在程序状态字寄存器PSW中设置位，根据运行程序对资源和指令的使用权限设置不同的CPU状态。</p> <p>例如X86架构中的EFLAGS寄存器，RISC-V的三种特权模式：</p> <ul> <li>机器模式(M模式)</li> <li>用户模式(U模式)</li> <li>监管模式(S模式)</li> </ul> <h3>2.4 特权指令和非特权指令</h3> <p>操作系统需要两种CPU状态：</p> <ul> <li><strong>内核态(Kernel Mode)</strong>：运行操作系统程序</li> <li><strong>用户态(User Mode)</strong>：运行用户程序</li> </ul> <p><strong>特权指令</strong>：只能由操作系统使用、用户程序不能使用的指令 <strong>非特权指令</strong>：用户程序可以使用的指令</p> <p>X86支持4个处理器特权级别(特权环 Ring)：R0、R1、R2和R3</p> <ul> <li>R0相当于内核态，特权能力最高</li> <li>R3相当于用户态，特权能力最低</li> <li>目前大多数基于x86处理器的操作系统只用了R0和R3两个特权级别</li> </ul> <h3>2.5 CPU状态之间的转换</h3> <ul> <li><strong>用户态 → 内核态</strong>：唯一途径是通过中断/异常/陷入机制</li> <li><strong>内核态 → 用户态</strong>：通过设置程序状态字PSW</li> </ul> <p>陷入指令(访管指令, supervisor call)：提供给用户程序的接口，用于调用操作系统功能 例如：int, trap, syscall, sysenter/sysexit, ecall</p> <hr> <h2>3. 中断机制</h2> <p>中断对于操作系统的重要性就如同汽车发动机、飞机引擎的作用，操作系统是由"中断驱动"或"事件驱动"的。</p> <p>主要作用：</p> <ul> <li>及时处理设备发来的中断请求</li> <li>捕获用户程序提出的服务请求</li> <li>防止用户程序执行过程中的破坏性活动</li> </ul> <h3>3.1 中断/异常的概念</h3> <p>CPU对系统发生的某个事件作出的一种反应：</p> <ul> <li>CPU暂停正在执行的程序</li> <li>保留现场后自动转去执行相应事件的处理程序</li> <li>处理完成后返回断点，继续执行被打断的程序</li> </ul> <p>特点：</p> <ul> <li>是随机发生的</li> <li>是自动处理的</li> <li>是可恢复的</li> </ul> <h4>中断/异常的来源及处理方式</h4> <p><strong>中断的来源</strong>：</p> <ul> <li>外部设备：如键盘、鼠标、网络接口卡等外设发出的中断信号</li> <li>定时器：系统定时器发出的中断信号</li> <li>其他硬件部件：如硬盘、打印机等</li> </ul> <p><strong>异常的来源</strong>：</p> <ul> <li>程序错误：如除零错误、非法指令、页面错误等</li> <li>系统调用：用户程序通过系统调用引发的陷入</li> <li>其他内部事件：如调试事件、断点等</li> </ul> <p><strong>处理方式</strong>：</p> <ul> <li>中断处理：中断处理程序通常是操作系统的一部分，负责响应外部设备的请求。处理过程包括保存当前CPU状态、执行中断处理程序、恢复CPU状态并返回被中断的程序。</li> <li>异常处理：异常处理程序也由操作系统提供，负责处理程序运行过程中出现的错误或特殊事件。处理过程包括识别异常类型、执行相应的处理程序、根据异常类型决定是否返回被中断的程序或终止程序。</li> </ul> <h4>术语演化的历史背景</h4> <ul> <li> <p><strong>中断的引入</strong>：为了支持CPU和设备之间的并行操作</p> <ul> <li>当CPU启动设备进行输入/输出后，设备便可以独立工作，CPU转去处理与此次输入/输出不相关的事情；当设备完成输入/输出后，通过向CPU发中断报告此次输入/输出的结果，让CPU决定如何处理以后的事情</li> </ul> </li> <li> <p><strong>异常的引入</strong>：表示CPU执行指令时本身出现的问题</p> <ul> <li>如算术溢出、除零、取数时的奇偶错，访存地址时越界或执行了“陷入指令”等，这时硬件改变了CPU当前的执行流程，转到相应的错误处理程序或异常处理程序或执行系统调用</li> </ul> </li> </ul> <h3>3.2 事件</h3> <p>事件可分为中断(外中断)和异常(内中断, 即下面三个表项)：</p> <p>| 类别 | 原因 | 异步/同步 | 返回行为 | | --------------- | ------------------------- | --------- | -------------------- | | 中断(Interrupt) | 来自I/O设备、其他硬件部件 | 异步 | 总是返回到下一条指令 | | 陷入(Trap) | 有意识安排的 | 同步 | 返回到下一条指令 | | 故障(Fault) | 可恢复的错误 | 同步 | 返回到当前指令 | | 终止(Abort) | 不可恢复的错误 | 同步 | 不会返回 |</p> <h3>3.3 中断/异常机制工作原理</h3> <p>中断/异常机制是现代计算机系统的核心机制之一，通过硬件和软件相互配合，使计算机系统得以充分发挥能力：</p> <p><strong>硬件工作</strong>：中断/异常响应</p> <ul> <li>捕获中断源发出的中断/异常请求</li> <li>以一定方式响应</li> <li>将处理器控制权交给特定的处理程序</li> </ul> <p><strong>软件工作</strong>：中断/异常处理程序</p> <ul> <li>识别中断/异常类型</li> <li>完成相应的处理</li> </ul> <p>在每条指令执行周期的最后时刻扫描中断寄存器，查看是否有中断信号。 若无中断信号，继续执行下一条指令。 若有中断，中断硬件将该中断触发器内容按规定编码送入PSW的相应位，称为中断码，通过交换中断向量引出中断处理程序。</p> <p><strong>硬件——中断响应过程示意</strong>：</p> <ol> <li>在每条指令执行周期的最后时刻，扫描中断寄存器。</li> <li>检查是否有中断信号。 <ul> <li>若无中断信号，继续执行下一条指令。</li> <li>若有中断信号，中断硬件将中断触发器内容按规定编码送入PSW的相应位，称为中断码。</li> </ul> </li> <li>通过交换中断向量，引出中断处理程序。</li> <li>硬件将处理器控制权交给特定的中断处理程序。</li> <li>中断处理程序执行相应的中断处理任务。</li> <li>中断处理完成后，恢复CPU状态并返回被中断的程序。</li> </ol> <h3>3.4 软硬协同——中断向量表</h3> <p>中断向量：一个内存单元，存放中断处理程序入口地址和程序运行所需的处理机状态字</p> <p>硬件执行流程按中断号/异常类型的不同，通过中断向量表转移控制权给中断处理程序</p> <p><strong>Linux中的中断向量(X86)</strong>：</p> <ul> <li>0～19：不可屏蔽中断和异常 <ul> <li>0: 除法错误 #DE</li> <li>1: 调试异常 #DB</li> <li>2: NMI中断</li> <li>3: 断点异常 #BP</li> <li>4: 溢出异常 #OF</li> <li>5: 边界检查异常 #BR</li> <li>6: 无效操作码异常 #UD</li> <li>7: 设备不可用异常 #NM</li> <li>8: 双重故障异常 #DF</li> <li>9: 协处理器段越界异常</li> <li>10: 无效TSS异常 #TS</li> <li>11: 段不存在异常 #NP</li> <li>12: 栈段错误 #SS</li> <li>13: 通用保护异常 #GP</li> <li>14: <strong>页错误异常 #PF</strong> (包含COW写时复制机制的页错误)</li> <li>15: 保留</li> <li>16: 浮点异常 #MF</li> <li>17: 对齐检查异常 #AC</li> <li>18: 机器检查异常 #MC</li> <li>19: SIMD浮点异常 #XF</li> </ul> </li> <li>20～31：Intel保留</li> <li>32～127：外部中断(IRQ)</li> <li>128(0x80)：用于系统调用的可编程异常</li> <li>129～238：外部中断</li> <li>239：本地APIC时钟中断</li> <li>240：本地APIC高温中断</li> <li>241～250：Linux保留</li> <li>251～253：处理器间中断</li> <li>254：本地APIC错误中断</li> <li>255：本地APIC伪中断</li> </ul> <h3>3.5 中断响应流程</h3> <ol> <li>设备发中断信号</li> <li>硬件保存现场</li> <li>根据中断码查表</li> <li>把中断处理程序入口地址等推送到相应的寄存器</li> <li>执行中断处理程序</li> </ol> <h3>3.6 上半部和下半部处理</h3> <p>在 Linux 系统中，中断处理程序应该尽量短且快，以减少对正常进程调度的影响。然而，中断处理程序可能会暂时关闭中断，如果执行时间过长，可能会丢失其他设备的中断请求。为了解决这个问题，Linux 将中断过程分为上半部和下半部。</p> <p>上半部用于快速处理中断，通常会暂时关闭中断请求，主要负责处理与硬件紧密相关或时间敏感的任务。下半部用于延迟处理上半部未完成的工作，一般以内核线程的方式运行。</p> <p>**上半部 (Top Half) **：</p> <ul> <li>上半部是中断处理程序的第一部分，直接由硬件中断触发。</li> <li>其主要任务是快速响应中断，处理与硬件紧密相关或时间敏感的操作。</li> <li>上半部运行在中断上下文中，通常会暂时关闭中断，不能被阻塞，也不能进行复杂的操作。</li> <li>典型的上半部操作包括：读取硬件寄存器、清除中断源、调度下半部等。</li> </ul> <p>**下半部 (Bottom Half) **：</p> <ul> <li>下半部是中断处理程序的第二部分，通常由上半部调度执行。</li> <li>其主要任务是延迟处理上半部未完成的工作，完成较为复杂和耗时的处理。</li> <li>下半部运行在进程上下文中，可以被阻塞，也可以进行复杂的操作。</li> <li>典型的下半部操作包括：数据处理、更新数据结构、唤醒等待的进程等。</li> </ul> <p>例如，当网卡收到网络包后，通过 DMA 将数据写入内存，并通过硬件中断通知内核有新数据到达。内核调用中断处理程序，分为上半部和下半部。上半部会先禁止网卡中断，避免频繁硬中断降低内核效率，然后触发软中断，将耗时且复杂的任务交给软中断处理程序 (下半部) 处理，如解析网络数据并将其传递给应用程序。</p> <p><strong>为什么引入上半部和下半部处理？</strong></p> <ol> <li><strong>提高响应速度</strong>：上半部只执行最紧急的操作，尽量缩短中断处理时间，使系统能够快速响应其他中断。</li> <li><strong>减少中断禁用时间</strong>：上半部运行在中断上下文中，系统在处理上半部时会禁用中断。通过将复杂操作移到下半部，可以减少中断禁用时间，提高系统的并发性。</li> <li><strong>分离紧急和非紧急任务</strong>：将紧急任务放在上半部，非紧急任务放在下半部，有助于合理分配系统资源，提高系统的整体性能和稳定性。</li> </ol> <p>所以，中断处理程序的上半部和下半部可以理解为：</p> <ul> <li>上半部直接处理硬件请求，也就是硬中断，主要是负责耗时短的工作，特点是快速执行；</li> <li>下半部是由内核触发，也就是软中断，主要是负责上半部未完成的工作，通常都是耗时比较长的事情，特点是延迟执行。</li> </ul> <p>还有一个区别，硬中断 (上半部) 是会打断 CPU 正在执行的任务，然后立即执行中断处理程序，而软中断 (下半部) 是以内核线程的方式执行，并且每一个 CPU 都对应一个软中断内核线程，名字通常为「ksoftirqd/CPU 编号」，比如 0 号 CPU 对应的软中断内核线程的名字是 ksoftirqd/0。</p> <p>Ref: <a href="https://xiaolincoding.com/os/1_hardware/soft_interrupt.html#%E4%BB%80%E4%B9%88%E6%98%AF%E8%BD%AF%E4%B8%AD%E6%96%AD">软中断</a></p> <h3>3.7 软件——中断处理程序</h3> <p>设计操作系统时，为每一类中断/异常事件编好相应的处理程序，并设置好中断向量表。系统运行时若响应中断，中断硬件部件将CPU控制权转给中断处理程序：</p> <ol> <li>保存相关寄存器信息</li> <li>分析中断/异常的具体原因</li> <li>执行对应的处理功能</li> <li>恢复现场，返回被事件打断的程序</li> </ol> <h3>3.8 中断/异常机制小结</h3> <p>以设备输入输出中断为例：</p> <ul> <li>打印机给CPU发中断信号</li> <li>CPU处理完当前指令后检测到中断，判断出中断来源并向相关设备发确认信号</li> <li>CPU开始为软件处理中断做准备： <ul> <li>处理器状态被切换到内核态</li> <li>在系统栈中保存被中断程序的重要上下文环境，主要是程序计数器PC、程序状态字PSW</li> </ul> </li> <li>CPU根据中断码查中断向量表，获得与该中断相关的处理程序的入口地址，并将PC设置成该地址，新的指令周期开始时，CPU控制转移到中断处理程序</li> <li>中断处理程序开始工作 <ul> <li>在系统栈中保存现场信息</li> <li>检查I/O设备的状态信息，操纵I/O设备或者在设备和内存之间传送数据等等</li> </ul> </li> <li>中断处理结束时，CPU检测到中断返回指令，从系统栈中恢复被中断程序的上下文环境，CPU状态恢复成原来的状态，PSW和PC恢复成中断前的值，CPU开始一个新的指令周期</li> </ul> <hr> <h2>4. IA32 体系结构对中断的支持</h2> <h3>4.1 基本概念——X86处理器</h3> <p><strong>中断</strong>：由硬件信号引发的，分为可屏蔽和不可屏蔽中断</p> <p><strong>异常</strong>：由指令执行引发的，比如除零异常</p> <ul> <li>80x86处理器发布了大约20种不同的异常</li> <li>对于某些异常，CPU会在执行异常处理程序之前产生硬件出错码，并压入内核态堆栈</li> </ul> <p><strong>系统调用</strong>：异常的一种，用户态到系统态的唯一入口</p> <h3>4.2 IA32体系结构对中断的支持</h3> <p><strong>中断控制器(PIC或APIC)</strong>：</p> <ul> <li>负责将硬件的中断信号转换为中断向量，引发CPU中断</li> </ul> <p><strong>实模式</strong>：中断向量表(Interrupt Vector)</p> <ul> <li>存放中断服务程序的入口地址</li> <li>不支持CPU运行状态切换</li> <li>中断处理与一般的过程调用相似</li> </ul> <p><strong>保护模式</strong>：中断描述符表(Interrupt Descriptor table)</p> <ul> <li>采用门(gate)描述符数据结构描述中断向量</li> <li>表项包含四种类型门描述符： <ul> <li>任务门(Task Gate)</li> <li>中断门(Interrupt Gate)</li> <li>陷阱门(Trap Gate)</li> <li>调用门(Call Gate)</li> </ul> </li> </ul> <p><strong>中断向量表/中断描述符表</strong></p> <ul> <li>表项包含四种类型门描述符： <ul> <li><strong>任务门(Task Gate)</strong> <ul> <li>中断发生时，必须取代当前进程的那个进程的TSS选择符存放在任务门中 (Linux没有使用任务门)</li> </ul> </li> <li><strong>中断门(Interrupt Gate)</strong> <ul> <li>给出段选择符 (Segment Selector)、中断/异常程序的段内偏移量 (Offset)</li> <li>通过中断门后系统会自动禁止中断</li> </ul> </li> <li><strong>陷阱门(Trap Gate)</strong> <ul> <li>与中断门类似，但通过陷阱门后系统不会自动关中断</li> </ul> </li> <li><strong>调用门(Call Gate)</strong></li> </ul> </li> </ul> <p><strong>中断/异常的硬件处理过程</strong>：</p> <ol> <li>确定与中断或异常关联的向量i</li> <li>通过IDTR寄存器找到IDT表，获得中断描述符 (表中的第i个表项)</li> <li>从GDTR寄存器获得GDT的地址，结合中断描述符中的段选择符，在GDT表获取对应的段描述符</li> <li>特权级检查</li> <li>检查是否发生了特权级的变化，如需要则进行堆栈切换</li> <li>硬件压栈，保存上下文环境</li> <li>如果是中断，清IF位</li> <li>通过中断描述符中的段内偏移量和段描述符中的基地址，找到中断/异常处理程序的入口地址，执行其第一条指令</li> </ol> <hr> <h2>5. 系统调用(System call)</h2> <p>系统调用是用户在编程时可以调用的操作系统功能：</p> <ul> <li>系统调用是操作系统提供给编程人员的唯一接口</li> <li>使CPU状态从用户态陷入内核态</li> </ul> <p>每个操作系统都提供几百种系统调用，包括进程控制、进程通信、文件使用、目录操作、设备管理、信息维护等。</p> <h4>经典问题：系统调用与C函数调用的区别？</h4> <ol> <li> <p><strong>系统调用</strong>：</p> <ul> <li><strong>定义</strong>：系统调用是操作系统提供给用户程序的接口，用于执行特权操作，如文件操作、进程控制、内存管理等。</li> <li><strong>执行环境</strong>：系统调用会导致CPU从用户态切换到内核态，执行内核中的代码。</li> <li><strong>实现方式</strong>：通过特定的陷入指令 (如<code>int 0x80</code>) 触发中断或异常，进入内核态执行相应的系统调用服务例程。</li> <li><strong>开销</strong>：由于涉及用户态到内核态的切换，系统调用的开销较大。</li> </ul> </li> <li> <p><strong>C函数调用</strong>：</p> <ul> <li><strong>定义</strong>：C函数调用是程序内部的函数调用，用于实现特定的功能或算法。</li> <li><strong>执行环境</strong>：C函数调用在用户态执行，不涉及特权操作。</li> <li><strong>实现方式</strong>：通过函数调用指令 (如<code>call</code>) 在程序内部跳转到函数的入口地址执行。</li> <li><strong>开销</strong>：C函数调用的开销较小，因为不涉及用户态和内核态的切换。</li> </ul> </li> </ol> <p>例如，<code>printf</code>函数是一个C库函数，它最终会调用系统调用<code>write</code>来将数据输出到终端。<code>printf</code>函数本身在用户态执行，而<code>write</code>系统调用会切换到内核态执行实际的输出操作。</p> <h3>5.1 静态：系统调用机制的设计</h3> <p>机制与策略分离原则指导下的系统调用设计：</p> <ol> <li><strong>中断/异常机制</strong>：支持系统调用服务的实现</li> <li><strong>陷入指令</strong>：引发异常，完成用户态到内核态的切换</li> <li><strong>系统调用号和参数</strong>：每个系统调用都事先给定一个编号(功能号)</li> <li><strong>系统调用表</strong>：存放系统调用服务例程的入口地址</li> </ol> <h3>5.2 静态：参数传递过程问题</h3> <p>怎样实现用户程序的参数传递给内核？常用的3种实现方法：</p> <ul> <li>由陷入指令自带参数：陷入指令的长度有限，只能自带有限的参数</li> <li>通过通用寄存器传递参数：寄存器的个数会限制传递参数的数量</li> <li>在内存中开辟专用堆栈区来传递参数</li> </ul> <p><strong>数据段部分</strong>：</p> <pre><code class="language-asm">section .data output: ascii "Hello!\n" output_end: equ len, output_end - output </code></pre> <ol> <li><code>section .data</code>：定义数据段，用于存放程序中的数据</li> <li><code>output:</code>：定义一个标签，表示数据的起始位置</li> <li><code>ascii "Hello!\n"</code>：定义一个ASCII字符串"Hello!"，后跟换行符</li> <li><code>output_end:</code>：定义另一个标签，表示数据的结束位置</li> <li><code>equ len, output_end - output</code>：定义一个常量<code>len</code>，其值为<code>output_end</code>和<code>output</code>之间的字节数，即字符串的长度</li> </ol> <p><strong>代码段部分</strong>：</p> <pre><code class="language-asm">section .text globl _start _start: movl $4, %eax #eax存放系统调用号 movl $1, %ebx movl $output, %ecx movl $len, %edx int $0x80 #引发一次系统调用 end: movl $1, %eax #1这个系统调用的作用？ movl $0, %ebx int $0x80 </code></pre> <ol> <li><code>section .text</code>：定义代码段，用于存放程序的指令</li> <li><code>globl _start</code>：声明<code>_start</code>标签为全局的，使链接器能够找到程序的入口点</li> <li><code>_start:</code>：程序的入口点</li> <li><code>movl $4, %eax</code>：将4放入eax寄存器，4是Linux系统调用表中<code>write</code>函数的调用号</li> <li><code>movl $1, %ebx</code>：将1放入ebx寄存器，1代表标准输出文件描述符</li> <li><code>movl $output, %ecx</code>：将output字符串的地址放入ecx寄存器，作为要输出的数据</li> <li><code>movl $len, %edx</code>：将len (字符串长度) 放入edx寄存器</li> <li><code>int $0x80</code>：触发中断0x80，执行系统调用，这里执行的是write(1, "Hello!\n", 7)</li> <li><code>movl $1, %eax</code>：将1放入eax寄存器，1是Linux系统调用表中<code>exit</code>函数的调用号</li> <li><code>movl $0, %ebx</code>：将0放入ebx寄存器，作为exit()的参数，表示程序正常退出 (返回值为0)</li> <li><code>int $0x80</code>：再次触发中断0x80，执行系统调用exit(0)，终止程序</li> </ol> <h3>5.3 动态：系统调用的执行过程</h3> <p>当CPU执行到特殊的陷入指令时：</p> <ol> <li><strong>中断/异常机制</strong>：硬件保护现场；通过查中断向量表把控制权转给系统调用总入口程序</li> <li><strong>系统调用总入口程序</strong>：保存现场；将参数保存在内核堆栈里；通过查系统调用表把控制权转给相应的系统调用处理例程或内核函数</li> <li><strong>执行系统调用例程</strong></li> <li><strong>恢复现场，返回用户程序</strong></li> </ol> <hr> <h2>6. Linux系统调用实现</h2> <p>基于x86体系结构的Linux系统调用实现：</p> <ul> <li><strong>陷入指令选择</strong>：<code>int $0x80</code></li> <li><strong>门描述符</strong>：系统初始化时对IDT表中的第128号门初始化</li> <li><strong>门类型</strong>：15，陷阱门：陷阱门不会自动屏蔽中断，允许在处理系统调用时继续响应其他中断，提高系统的并发性和响应速度。</li> <li><strong>DPL</strong>：3，与用户级别相同，允许用户进程使用该门描述符</li> </ul> <h3>6.1 系统调用号示例</h3> <pre><code class="language-c"># define __NR_exit 1 # define __NR_fork 2 # define __NR_read 3 # define __NR_write 4 # define __NR_open 5 # define __NR_close 6 # define __NR_waitpid 7 # define __NR_creat 8 # define __NR_link 9 # define __NR_unlink 10 # define __NR_execve 11 # define __NR_chdir 12 # define __NR_time 13 ... </code></pre> <h3>6.2 系统执行 <code>int $0x80</code> 指令</h3> <ol> <li> <p><strong>特权级的改变</strong>：由于从用户态切换到内核态，CPU需要切换栈。</p> <ul> <li>用户栈切换到内核栈：CPU从任务状态段 (TSS) 中装入新的栈指针 (SS:ESP) ，指向内核栈。</li> </ul> </li> <li> <p><strong>保存用户态信息</strong>：用户栈的信息 (SS:ESP) 、EFLAGS、用户态CS、EIP寄存器的内容会被压栈，以便返回时使用。</p> <ul> <li>将EFLAGS压栈后，复位TF (陷阱标志) ，IF (中断标志) 位保持不变。</li> </ul> </li> <li> <p><strong>查找IDT</strong>：使用128在中断描述符表 (IDT) 中找到对应的门描述符，从中找出段选择符装入代码段寄存器CS。</p> <ul> <li>代码段描述符中的基地址加上陷阱门描述符中的偏移量，定位到system_call的入口地址。</li> </ul> </li> <li> <p><strong>特权级检查</strong>：代码只能访问相同或较低特权级的数据。</p> <ul> <li>确保系统调用在内核态执行，防止用户态代码直接访问内核数据。</li> </ul> </li> <li> <p><strong>系统调用号和参数传递</strong>：</p> <ul> <li>系统调用号：通过EAX寄存器传递。</li> <li>系统调用参数：通过EBX、ECX、EDX、ESI、EDI寄存器传递。</li> </ul> </li> <li> <p><strong>执行系统调用</strong>：根据系统调用号，查找系统调用表，找到对应的系统调用处理例程并执行。</p> <ul> <li>处理完成后，将结果放入EAX寄存器，并通过ret_from_sys_call例程返回用户态程序。</li> </ul> </li> </ol> <h3>6.3 Linux系统调用执行流程</h3> <pre><code class="language-bash">应用程序 → 封装例程 → 陷入处理 → 内核函数 </code></pre> <ol> <li>用户态下调用C库的库函数，比如write()</li> <li>封装后的write()先做好参数传递工作，然后使用int 0x80指令产生一次异常</li> <li>CPU通过0x80号在IDT中找到对应的服务例程system_call()，并调用之</li> <li>system_call()将参数保存在内核栈；根据系统调用号索引系统调用表，找到系统调用程序入口，比如sys_write()</li> <li>sys_write()执行完后，经过ret_from_sys_call()例程返回用户程序</li> </ol> <h3>6.4 示例：系统调用的参数传递</h3> <p>系统调用使用寄存器传递参数，要传递的参数包括：</p> <ul> <li>系统调用号</li> <li>系统调用所需的参数</li> </ul> <p>用于传递参数的寄存器有：</p> <ul> <li>eax用于保存系统调用号和系统调用返回值</li> <li>系统调用参数保存在ebx, ecx, edx, esi和edi中，参数个数不超过6个</li> </ul> <p>进入内核态后，system_call再将这些参数保存在内核堆栈中。</p> <p>假如C库中封装的系统调用号3的函数原型如下：</p> <pre><code class="language-asm">movl 0x8(%esp), %ecx # 将用户态堆栈中的para2放入ecx movl 0x4(%esp), %ebx # 将用户态堆栈中的para1放入ebx movl $0x3, %eax # 系统调用号保存在eax中 int $0x80 # 引发系统调用 movl %eax, errno # 将结果存入全局变量errno中 movl $-1, %eax # eax置为-1，表示出错 </code></pre> <p>则调用时，参数传递如下：</p> <ul> <li>eax = 3</li> <li>ebx = para1</li> <li>ecx = para2</li> </ul> <hr> <h2>7. 系统调用小结</h2> <ul> <li>系统调用：用户在程序中调用操作系统提供的一些子功能</li> <li>一种特殊的过程调用，由特殊的机器指令实现 (每种机器的指令集都支持—访管指令)</li> <li>系统调用是操作系统提供给编程人员的唯一接口</li> <li>CPU状态从目态转入管态</li> <li>利用系统调用，可以动态请求和释放系统资源，完成与硬件相关的工作以及控制程序的执行等</li> <li>每个操作系统都提供几百种系统调用 (POSIX标准)</li> <li>系统调用与C函数调用的区别？</li> <li>完成系统调用机制的运行需要什么条件 (准备工作) ？ <ul> <li>静态 和 动态</li> <li>封装内核函数 - 库函数 (API) ；访管指令与陷入机制；编译器；操作系统 (初始化、系统调用编号及参数；系统调用表)</li> <li>陷入内核，总入口程序，保存现场 (压栈) ，查表分派，执行返回</li> </ul> </li> </ul>https://www.lyt0112.com/blog/operating_systems_note_01-zhhttps://www.lyt0112.com/blog/operating_systems_note_01-zhOperating Systems Notes 01: 操作系统概述Tue, 11 Mar 2025 22:14:00 GMT<p>import { Aside } from '@/components/user'</p> <p>Model: <code>claude-3-7-sonnet-20250219</code></p> <p>This article uses LLM to improve efficiency, which can make mistakes. I have tried my best to check and proofread, but still cannot guarantee complete accuracy.</p> <p>For personal use, may be nagging for you.</p> <h2>1. 操作系统是什么？</h2> <h3>1.1 操作系统的定义</h3> <p>操作系统是计算机系统中的一个系统软件，是一些程序模块的集合：</p> <ul> <li><strong>资源的管理者</strong>：能以尽量有效、合理的方式组织和管理计算机的软硬件资源</li> <li><strong>服务的提供者</strong>：合理地组织计算机的工作流程，控制程序的执行并向用户提供各种服务功能</li> <li><strong>机器能力的扩展</strong>：使得用户能够灵活、方便地使用计算机，使整个计算机系统能高效地运行</li> </ul> <h3>1.2 操作系统的作用</h3> <ul> <li><strong>虚拟机</strong>：将物理资源(处理器、内存、磁盘)转换成更通用、更强大、更易用的虚拟形式</li> <li><strong>APIs</strong>：提供可供用户调用的接口，提供应用程序的标准库</li> <li><strong>资源管理器</strong>：允许多程序运行(共享CPU)，允许多程序并发访问内存，允许多程序访问设备</li> </ul> <h3>1.3 设计与实现目标</h3> <ul> <li><strong>抽象</strong> <ul> <li>模块化</li> <li><strong>使用高级语言</strong>(C)而非汇编</li> </ul> </li> <li><strong>性能</strong>(最小化开销) <ul> <li>最小化额外的时间(指令)</li> <li>最小化额外的空间(内存/磁盘)</li> </ul> </li> <li><strong>保护</strong>：应用之间、操作系统与应用之间的隔离</li> <li><strong>可靠性</strong></li> <li><strong>节能</strong></li> <li><strong>安全性</strong>：防止恶意应用的入侵</li> <li><strong>移动性</strong>：能够运行在越来越小的设备上</li> </ul> <hr> <h2>2. 从不同角度认知操作系统</h2> <h3>2.1 资源管理的观点</h3> <ul> <li><strong>自底向上</strong> 操作系统是资源的管理者</li> <li><strong>硬件资源</strong>：CPU，内存，设备(I/O设备、磁盘、时钟、网络接口等)</li> <li><strong>软件资源</strong>：磁盘上的文件、信息</li> <li><strong>资源管理目的</strong>：实现资源共享、提高资源利用率</li> <li><strong>复用方式</strong>：时间及空间</li> </ul> <p>怎样管理资源？</p> <ul> <li><strong>数据结构与算法</strong> <ul> <li>跟踪记录资源使用状况</li> <li>分配和回收资源(资源分配策略与算法) <ul> <li>静态分配策略</li> <li>动态分配策略 ✓</li> </ul> </li> </ul> </li> <li><strong>资源管理目标</strong> <ul> <li>提高资源利用率</li> <li>资源使用时的保护</li> <li>协调多个进程对资源请求的冲突</li> </ul> </li> </ul> <h3>2.2 进程的观点</h3> <p>从操作系统运行的角度动态观察操作系统：</p> <ul> <li>操作系统是由一些可同时、独立运行的进程和一个对这些进程进行协调的核心组成</li> <li><strong>进程</strong>：完成某一特定功能的程序，是程序的一次执行过程，动态的、有生命的，有诞生/消亡</li> </ul> <h3>2.3 虚机器观点</h3> <p>从操作系统内部结构来看：</p> <ul> <li>把操作系统分成若干层</li> <li>每一层完成其特定功能，构成一个虚机器，并对上一层提供支持</li> <li>通过逐层功能扩充，最终完成整个操作系统虚机器</li> <li>操作系统虚机器向用户提供各种功能，完成用户请求</li> </ul> <hr> <h2>3. 操作系统的特征</h2> <h3>3.1 并发(concurrency)</h3> <ul> <li>处理多个同时性活动的能力</li> <li>计算机系统中同时运行多个程序</li> <li><strong>宏观上</strong>：这些程序同时在执行</li> <li><strong>微观上</strong>：单CPU情况下，任何时刻只有一个程序在执行，即这些程序在CPU上轮流执行</li> <li>由并发引起的问题：活动切换、保护、相互依赖的活动间的同步</li> <li>**并行(parallel)**与"并发"的区别</li> </ul> <h3>3.2 共享(sharing)</h3> <p>操作系统与多个用户程序共同使用计算机系统中的资源</p> <ul> <li>共享有限的系统资源</li> <li>操作系统要对系统资源进行合理分配和使用</li> <li>资源在一个时间段内交替被多个进程所用 <ul> <li><strong>互斥共享</strong>(如打印机)</li> <li><strong>同时共享(访问)</strong>(如可重入代码，磁盘文件)</li> </ul> </li> <li>由于共享引发的问题：资源分配难以达到最优化，资源使用时需要保护</li> </ul> <h3>3.3 虚拟(Virtual)</h3> <ul> <li>一个物理实体映射为若干个对应的逻辑实体(分时或分空间)</li> <li>虚拟技术是操作系统管理系统资源的重要手段，可提高资源利用率 <ul> <li><strong>CPU</strong>：每个用户(进程)的"虚处理器"</li> <li><strong>存储器</strong>：每个进程都占有的地址空间(代码＋数据＋堆、栈)</li> <li><strong>显示设备</strong>：多窗口或虚拟终端</li> </ul> </li> </ul> <h3>3.4 随机性(不确定性)</h3> <ul> <li>操作系统必须随时对以不可预测的次序发生的事件进行响应</li> <li>进程的运行速度不可预知：多个进程并发执行，"走走停停"，无法预知每个进程的运行推进快慢</li> <li>难以重现系统在某个时刻的状态(包括重现运行中的错误)</li> </ul> <hr> <h2>4. 操作系统发展历史</h2> <h3>技术变化与概念重用</h3> <p>技术变化导致某些思想过时并迅速消失，但技术的另一种变化还可能使它们复活。例如：</p> <ul> <li>磁盘上文件分配—连续文件(CD-ROM文件系统)</li> <li>硬件保护</li> <li>动态链接(MULTICS首先提出)</li> <li>计算服务(MULTICS，以大量的、附有相对简单用户机器的、集中式Internet服务器形式回归) → 云计算</li> </ul> <h3>4.1 操作系统发展阶段</h3> <h4>第1阶段(1948-1970)：硬件昂贵，人工便宜</h4> <ul> <li><strong>控制台</strong>：一次一个用户(独占资源)</li> <li><strong>批处理</strong>：装入程序 → 运行 → 打印输出结果(无保护)</li> <li><strong>多道程序设计</strong>：多个程序同时运行，多个用户共享系统(需要存储保护)</li> <li><strong>SPOOLing技术</strong>：批处理作业处理流程</li> </ul> <h4>第2阶段(1970-1985)：硬件便宜，人工昂贵</h4> <ul> <li><strong>交互、分时</strong>：多个用户同时与系统交互</li> <li>用户可以在线工作：开发、调试、编辑等</li> <li>问题：增加用户时 → 系统性能降低(响应时间、抖动)</li> </ul> <p><strong>第一个分时操作系统CTSS</strong>：</p> <ul> <li>1959年在MIT提出分时系统思想</li> <li>每个用户有一个联机终端</li> <li>计算机能够为许多用户提供交互式、快速服务，同时在CPU空闲时还能在后台运行大作业</li> </ul> <p><strong>重要历史事件</strong>：</p> <ul> <li><strong>OS/360</strong>：IBM发布时带着已知的1000个错误</li> <li><strong>Multics</strong>：1963年开始，1969年才发布</li> <li><strong>UNIX</strong>：一群计算机迷在贝尔实验室开发，初衷是在DEC PDP-7小型计算机上玩星际探险游戏</li> </ul> <h4>第3阶段(1981-)：硬件非常便宜，人工非常昂贵</h4> <ul> <li>个人计算时代</li> <li>开始PC硬件资源有限，一次运行一个程序，OS是一个例程库，回归简单</li> <li>逐渐PC资源丰富，OS又成为一个庞然大物(大型OS)，存储保护、多道程序设计再次出现</li> </ul> <h4>第4阶段(1981-)：分布式</h4> <ul> <li>网络：允许不同机器很容易地相互共享资源(打印机、文件服务器、Web服务器)</li> <li>解决问题：共享，安全</li> </ul> <h4>第5阶段(1995-)：移动计算时代</h4> <ul> <li>各种移动终端的出现(笔记本、平板、手机、机顶盒、可穿戴设备等)</li> <li>特点：小型、移动、便宜，但能力有限</li> </ul> <h4>第6阶段(2006-)：云计算时代</h4> <ul> <li>提供可无限扩展的、可随时获取的、按需使用、按使用付费的资源</li> <li>云计算操作系统：云计算后台数据中心的整体管理运营系统</li> <li>作用： <ul> <li>管理和驱动海量服务器、存储等基础硬件</li> <li>为云应用软件提供统一、标准的接口</li> <li>管理海量的计算任务以及资源调配</li> </ul> </li> </ul> <h4>第7阶段(200?-)：泛在计算/普适计算/物联网</h4> <ul> <li>许多联网设备为许多人提供个性化的服务</li> </ul> <hr> <h2>5. 操作系统分类</h2> <h3>5.1 传统分类</h3> <h4>1. 批处理操作系统</h4> <ul> <li> <p><strong>批</strong>：供一次加载的磁带或磁盘，通常由若干个作业组装成</p> </li> <li> <p><strong>工作方式</strong>：</p> <ol> <li>用户将作业交给系统操作员</li> <li>系统操作员将许多用户的作业组成一批作业，输入到计算机系统中</li> <li>系统操作员启动操作系统</li> <li>系统自动、依次执行每个作业</li> <li>由系统操作员将作业结果交给用户</li> </ol> </li> <li> <p><strong>典型的作业结构</strong>：由一张张卡片组成，卡片上是命令和程序</p> </li> <li> <p><strong>分类</strong>：</p> <ul> <li><strong>单道批处理系统</strong>(simple batch processing, uni-programming)</li> <li><strong>多道批处理系统</strong>(multiprogramming system)</li> </ul> </li> </ul> <p>SPOOLing系统(技术)</p> <ul> <li>1961年，英国曼彻斯特大学，Atalas机</li> <li><strong>Simultaneous Peripheral Operation On-Line</strong>(同时的外围设备联机操作)--假脱机技术</li> <li><strong>思想</strong>：利用磁盘作缓冲，将输入、计算、输出分别组织成独立的任务流，使I/O和计算真正并行</li> <li><strong>工作原理</strong> <ul> <li>作业进入到磁盘上的输入井</li> <li>按某种调度策略选择几种搭配得当的作业，并调入内存</li> <li>作业运行的结果输出到磁盘上的输出井</li> <li>结果从磁盘上的输出井送到打印机</li> </ul> </li> <li><strong>主要特点</strong>： <ul> <li>提高I/O速度</li> <li>将独占设备改造为共享设备</li> <li>实现虚拟设备功能</li> </ul> </li> </ul> <h4>2. 分时操作系统(time-sharing system)</h4> <ul> <li><strong>时间片</strong>(time slice)：操作系统将CPU的时间划分成若干个片段</li> <li>操作系统以时间片为单位，轮流为每个终端用户服务, 每次服务一个时间片 (其特点是利用人的错觉，使人感觉不到)</li> <li><strong>追求目标</strong>：及时响应(依据是响应时间)</li> <li><strong>响应时间</strong>：从终端发出命令到系统给予回答所经历的时间</li> </ul> <h4>3. 实时操作系统</h4> <ul> <li>使计算机能及时响应外部事件的请求，在规定的严格时间内完成对该事件的处理</li> <li><strong>分类</strong>： <ul> <li><strong>实时过程控制</strong>：工业控制，军事控制</li> <li><strong>实时通信(信息)处理</strong>：电讯(自动交换)，银行，飞机订票，股市行情</li> </ul> </li> <li><strong>追求目标</strong>：对外部请求在严格时间范围内作出反应，高可靠性</li> <li><strong>特征</strong>：关键参数是时间</li> <li><strong>类型</strong>： <ul> <li><strong>硬实时系统</strong>：某个动作绝对必须在规定的时刻或时间范围完成</li> <li><strong>软实时系统</strong>：接受偶尔违反最终时限</li> </ul> </li> </ul> <h4>4. 个人计算机操作系统</h4> <ul> <li>计算机在某一时间内为单用户服务</li> <li><strong>追求目标</strong>：界面友好，使用方便，丰富的应用软件</li> </ul> <h4>5. 网络操作系统</h4> <ul> <li>基于计算机网络，在各种计算机操作系统上按网络体系结构协议标准开发的软件</li> <li><strong>功能</strong>：网络管理，通信，安全，资源共享和各种网络应用</li> <li><strong>追求目标</strong>：相互通信，资源共享</li> </ul> <h4>6. 分布式操作系统</h4> <ul> <li><strong>分布式系统</strong>：处理和控制的分散(相对于集中式系统)</li> <li>以计算机网络为基础，基本特征是处理的分布(功能和任务的分布)</li> <li>所有系统任务可在系统中任何处理机上运行，自动实现全系统范围内的任务分配</li> <li><strong>特征</strong>： <ol> <li>是一个统一的操作系统</li> <li>资源进一步共享</li> <li>透明性: 资源共享，分布对用户来讲是不知道的</li> <li>自治性: 处于分布式系统的多个主机处于平等地位，无主从关系</li> <li>处理能力增强、速度更快、可靠性增强</li> </ol> </li> </ul> <h4>7. 嵌入式操作系统</h4> <ul> <li><strong>嵌入式系统</strong>：在各种设备、装置或系统中，完成特定功能的软硬件系统</li> <li><strong>嵌入式操作系统</strong>：运行在嵌入式系统环境中，对整个嵌入式系统及其所操作、控制的各种部件装置等资源进行统一协调、调度、指挥和控制的系统软件</li> </ul> <h3>5.2 Tanenbaum分类</h3> <ul> <li>大型机操作系统</li> <li>服务器操作系统</li> <li>多处理机操作系统</li> <li>个人计算机操作系统</li> <li>掌上计算机操作系统(移动计算机操作系统)</li> <li>嵌入式操作系统</li> <li>传感器节点操作系统</li> <li>实时操作系统</li> <li>智能卡操作系统</li> </ul> <h4>智能卡操作系统</h4> <ul> <li><strong>智能卡</strong>：一种包含有一块CPU芯片的信用卡</li> <li><strong>特点</strong>： <ul> <li>非常严格的运行能耗和存储空间的限制</li> <li>有些智能卡只有单项功能，如电子支付</li> </ul> </li> <li><strong>专用的操作系统</strong>： <ul> <li>有些智能卡是面向Java的，ROM中有Java虚拟机解释器</li> <li>Java小程序被下载到卡中并由JVM解释器解释</li> <li>有些卡可以同时处理多个Java小程序，需要多道程序调度</li> <li>资源管理和保护由卡上的操作系统处理</li> </ul> </li> <li><strong>通信方式</strong>： <ul> <li>在读写器与智能卡之间通过"命令-响应对"方式进行通信和控制</li> <li>读写器发出操作命令，智能卡接收命令</li> <li>操作系统对命令解释，完成命令的解密与校验</li> <li>操作系统调用相应程序进行数据处理，产生应答信息，加密后送给读写器</li> </ul> </li> </ul> <hr> <h2>6. 重点小结</h2> <h3>6.1 典型的国产操作系统</h3> <p>麒麟、鸿蒙、Openeuler、统信等</p> <h3>6.2 核心概念</h3> <ul> <li><strong>操作系统的概念</strong></li> <li><strong>理解操作系统的不同角度</strong></li> <li><strong>操作系统的主要特征</strong></li> <li><strong>典型的、历史上/当前有重要意义的操作系统</strong></li> <li><strong>重要的操作系统技术及相关技术</strong> <ul> <li>多道程序设计</li> <li>中断</li> <li>通道</li> <li>SPOOLing技术</li> </ul> </li> <li><strong>操作系统的分类</strong></li> </ul> <h3>6.3 重要历史操作系统</h3> <ul> <li><strong>OS/360</strong></li> <li><strong>MULTICS</strong></li> </ul> <h3>6.4 操作系统特征</h3> <ul> <li><strong>并发</strong></li> <li><strong>共享</strong></li> <li><strong>虚拟</strong></li> <li><strong>随机性</strong></li> </ul> <hr> <h2>7. 常见问题解答</h2> <h3>7.1 Buffer Cache的作用和工作原理</h3> <p>在UNIX操作系统中，文件子系统与块设备之间的Buffer Cache：</p> <ul> <li><strong>作用</strong>： <ul> <li>减少对物理设备的访问次数，提高I/O性能</li> <li>协调CPU与I/O设备之间的速度差异</li> <li>支持数据的读写缓冲，实现数据共享</li> </ul> </li> <li><strong>工作原理</strong>： <ul> <li>当进程请求读取数据时，系统首先检查Buffer Cache中是否有所需数据</li> <li>如果有 (命中) ，直接从Buffer Cache返回数据</li> <li>如果没有 (未命中) ，从物理设备读取数据到Buffer Cache，再返回给进程</li> <li>写操作时，数据先写入Buffer Cache，再由系统决定何时写回物理设备</li> </ul> </li> </ul> <h3>7.2 UNIX的名字来历 (猜测)</h3> <p>UNIX名字可能来源于MULTICS (Multiplexed Information and Computing Service) 的简化和双关语：</p> <ul> <li>MULTICS是一个复杂的分时系统</li> <li>UNIX (Uniplexed Information and Computing Service) 表示简化版的MULTICS</li> <li>也有说法是"UNIX"是"eUNuchs" (阉割版的MULTICS) 的变体</li> </ul> <h3>7.3 批处理操作系统的区别</h3> <ul> <li><strong>单道批处理</strong>：一次只能执行一个作业，作业按顺序依次执行，前一个作业完成后才能执行下一个</li> <li><strong>多道批处理</strong>：内存中同时存放多个作业，CPU在这些作业之间切换执行，提高了CPU利用率和系统吞吐量</li> </ul> <h3>7.4 SPOOLing技术的现状</h3> <p>SPOOLing技术并未过时，在现代计算机系统中仍有广泛应用：</p> <ul> <li><strong>打印系统</strong>：现代操作系统的打印队列管理</li> <li><strong>邮件系统</strong>：电子邮件的发送和接收过程</li> <li><strong>后台作业处理</strong>：批处理任务的调度和执行</li> <li><strong>数据库系统</strong>：事务处理和日志管理</li> </ul> <h3>7.5 传统分时系统在今天的意义</h3> <p>传统分时系统在今天仍有重要意义：</p> <ul> <li><strong>多用户支持</strong>：现代操作系统继承了分时系统的多用户并发访问能力</li> <li><strong>资源共享</strong>：分时思想是云计算、虚拟化等现代技术的基础</li> <li><strong>交互式计算</strong>：分时系统建立的交互式计算模式仍是现代系统的核心特性</li> <li><strong>公平调度</strong>：分时系统的时间片轮转调度思想仍被广泛应用</li> </ul> <h3>7.6 操作系统的主要作用和典型特征</h3> <p><strong>操作系统的主要作用</strong>：</p> <ul> <li>管理计算机硬件和软件资源</li> <li>为应用程序提供统一的服务接口</li> <li>实现人机交互，提供用户界面</li> <li>提高系统资源利用率</li> <li>保护系统安全和数据完整性</li> </ul> <p><strong>操作系统的典型特征</strong> (与其他软件相比) ：</p> <ul> <li><strong>并发性</strong>：能够同时运行多个程序</li> <li><strong>共享性</strong>：多个用户/程序共享系统资源</li> <li><strong>虚拟性</strong>：将物理资源抽象为逻辑资源</li> <li><strong>异步性</strong>：程序执行的结果与时间有关</li> <li><strong>持久性</strong>：操作系统常驻内存</li> <li><strong>特权性</strong>：拥有对硬件的直接控制权</li> <li><strong>复杂性</strong>：结构复杂，功能丰富</li> </ul>https://www.lyt0112.com/blog/crystal-zhhttps://www.lyt0112.com/blog/crystal-zh其实是魅力化学的课程论文Tue, 28 Jan 2025 15:07:00 GMT<p>import { Aside } from '@/components/user'</p> <p>本文为博主 2022 年秋季学期的 <a href="https://www.lyt0112.com/blog/course_review-zh#%E9%AD%85%E5%8A%9B%E5%8C%96%E5%AD%A6">魅力化学课程</a> 论文, 感觉很有纪念意义故发布.</p> <h2>一、前言</h2> <p>苏霍姆林斯基说："在人的心灵深处，都有一种根深蒂固的需要，就是希望自己是一个发现者， 研究者和探究者。" 每个人都有对新奇事物的求知欲，而作为一门历史悠久的学科， 化学以其百变的现象、 剔透的晶体、 丰富的物质等一系列独特而又直观的魅力吸引着一代又一代的学生。</p> <p>作为一门典型的实验学科，中学生们却只能在习题中做实验，进入实验室的机会可以说是少之又少， 而在对实验的兴趣和沉没题海的枯燥之间的矛盾便是中学家庭实验党产生的最好土壤。</p> <p>幸运又不幸，我曾是一名家庭实验党。在自己动手实现一些实验时，我满足了对化学的好奇心。例如亚甲基蓝和葡萄糖在空气作用下的还原氧化循环（蓝瓶子实验）或制作纯净物的晶体（本文主要介绍内容），这些实践让我对化学产生了更深的理解。</p> <p>而遗憾的是，首先实验区与生活区不能完全分离、废物处理不当、在缺乏适当安全防护的情况下进行危险实验（比如大剂量铝热实验、没有通风橱的情况下制取氯气），这些都存在潜在危险。同时也常常疏于记录实验过程，这也不是一个好习惯。更重要的是，关于家庭实验的意义，在现在对化学实验有了更深认识的当下，我或许会产生一些不同的看法。</p> <p>那段时间我主要进行纯净物晶体的制备，从最基础的五水合硫酸铜、十二水合硫酸铝钾，到硫酸铬钾、氯化钠、氯化钾、硫酸亚铁，再到铁氰化钾、硫酸镍铵、硫酸锰。随着经验的积累，我对溶液的析出结晶细节愈发熟悉，能够获得更为规则、晶莹剔透的晶体。</p> <p> 十二水合硫酸铝钾包裹的硫酸铬钾 </p> <p>最后由于时间久远，本文中的图片没有完全使用我自己拍摄的图片，使用了一些网络图片作为补充（将标明）。</p> <h2>二、一般的制作流程</h2> <p>制作晶体的方法多种多样，大体上分为两种，分别是液相结晶和熔融凝固结晶法。</p> <p>在家中进行晶体制作的条件比较简陋，因此一般采取水液相结晶的方法。</p> <p>熔融凝固结晶法一般用来制作金属晶体，比如铋和镓的晶体，需要较高的温度，并且某些物质还会受热分解，因此难度较高。</p> <p>其它溶剂液相结晶法可以用来制作在水中溶解度低的物质的晶体， 比如使用四氯化碳制作硫晶体、 无水乙醇制作碘晶体， 但是由于有机溶剂一般具有较大的毒性且挥发性较强，往往不采用这个方法制作。</p> <h3>（一）晶体类型选择</h3> <p>第一次制备晶体时的最佳选择是五水合硫酸铜（胆矾）。硫酸铜晶体析出的稳定性极强，制备难度极低。 硫酸铜溶解度高， 溶液稍有杂质或者过饱和也能长出明显的平行四边形晶体， 颜色亮蓝色鲜艳好看， 且毒性低。 同时它的晶体容易悬吊，适合使用悬吊法制做出极大的单晶。</p> <p>其次就是十二水合硫酸铝钾（明矾）和十二水合硫酸铬钾（铬矾），因为它们是类质同晶的， 也就是可以做它们的不同配比的混晶， 做出来的晶体为正六面体或者正八面体，形状规则好看。</p> <p> 体积较大的分层明矾铬钾 </p> <p>稍有难度的是氯化钠的晶体，虽然常用的食盐中绝大部分都是它，但是想要做一个大且透明的单晶是难上加难， 制作的时候一定不要使用食盐， 因为杂质与添加剂太多， 不会形成单晶。 氯化钠晶体的制作难度首先是它的溶解度较低， 想要冷却热饱和溶液制备晶种几乎不可能， 其次是容易产生碎晶， 也很难做出晶莹剔透的晶体。</p> <p>一般在制备的时候都会添加一些甘氨酸[^1] （8g/L） 作为添加剂以提高氯化钠晶体的透明度， 如果想要进一步提高晶体的透明度可以加入少量的硝酸铅[^2]（0.1g/L）。</p> <p> 氯化钠单晶 </p> <h3>（二）配置母液</h3> <p>首先应该配置饱和溶液。一般采用母液法，虽然理论上可以通过查询溶解度表， 再计算溶质与结晶水的质量来使溶液恰好饱和， 但是考虑到晶体制作的流水线连续性、 溶液复用性、 室温的波动以及溶解度表的不准确性， 使用一个烧杯存放母液作为缓冲往往可以得到更好的效果。</p> <p>首先需要准备一个容量较大的烧杯作为母液烧杯， 根据溶解度加入大致质量的溶质并等待一段时间， 如果烧杯底部仍有未溶解的溶质 （因为溶解结晶是动态平衡，因此多余的试剂往往会变成晶体"大饼"），就说明这杯溶液饱和了，我们将其作为母液，此时母液的上层清液便是饱和溶液。</p> <p> 烧杯底部的晶体"大饼"[^2] </p> <h3>（三）析晶方法</h3> <p>现在我们有了饱和溶液， 那么具体如何操作才能使晶体从水中析出呢？一般有两种方法，分别是冷却热饱和溶液法和常温蒸发结晶法。</p> <p>冷却热饱和溶液法适用于溶解度对温度变化敏感的溶质，比如硫酸铜。具体操作是对每 100 克水加入比当前温度溶解度多 20 克左右的溶质（加多了容易析出大饼） ， 搅拌加热至完全溶解， 将溶液立刻倒入结晶皿中并等待结晶，此时要注意在结晶皿上盖一张滤纸以防止灰尘落入结晶皿， 灰尘可能会造成溶液迅速析出大量碎晶；待温度下降溶液结晶后用镊子夹出品相较好的小晶体作为晶核/晶种， 注意一旦镊子进入溶液也会造成溶液迅速析出大量碎晶。 在拿出心仪的小晶种之后，将剩余液体与碎晶倒回母液烧杯。</p> <p>冷却热饱和溶液法由于溶解度下降的速率较快，往往用来制作大量小晶种，也就是以量取胜，难以制作单个的形状规则的大晶体。</p> <p> 冷却热硫酸铜溶液析晶[^3] </p> <p>常温蒸发结晶法适用于任何种类的溶质，只要取母液的上层清液，倒入结晶皿，放入小晶核（不放其实也可以），静置析晶即可。</p> <p>常温蒸发结晶法除了可以将晶种放在结晶皿底部，也可以用透明细鱼线（或许头发也可以） 将晶种悬挂在饱和溶液中， 这个方法的好处在于晶体底部不会被结晶皿底部限制而产生不自然的凹面，但是坏处是鱼线会留在晶体内部。</p> <p> 栓绳的胆矾晶体与悬吊法生长的明矾 </p> <p>最后在从溶液中拿出晶体后，一定要注意立刻将晶体表面的溶液擦干，因为表面的溶液由于于空气接触面积极大， 会迅速风干， 在晶体表面留下许多细小的杂晶，导致一段时间过后晶体表面变得粗糙。</p> <h3>（四）保存方法</h3> <p>在得到了这些漂亮的晶体之后我们显然不会把它们又放回母液中溶掉， 而是想把它们保存下来， 那么现在就要考虑如何保存晶体才能让保存时间长久还能好好地把玩晶体。</p> <p>另外如果晶体因为保存不慎表面被风化了一些， 可以通过将晶体放回饱和溶液几秒钟，直到表面的脱水白色部分变回到正常含结晶水的颜色。</p> <ol> <li>拍照保存</li> </ol> <p>拍照保存实在是保存时间最久的方法， 下图中的硫酸亚铁早已因为保存不当而丢失结晶水风化为白色粉末了，但是它的遗照仍然存放在我的电脑中。</p> <p> 硫酸亚铁（N 年之前） </p> <ol start="2"> <li>使用矿物标本盒</li> </ol> <p>顾名思义，这个方法往往用来展示固体标本而不是长时间存放，如果是易风化（含有结晶水的任何物质）、光解（三草酸合铁酸钾）的晶体不要使用这样的方法展示。</p> <p> 矿标盒里的铝钾铬钾混晶[^4] </p> <ol start="3"> <li>使用密封袋</li> </ol> <p>好处在于价格亲民，保存非常方便，对于普通的晶体如氯化钠，可以做到长期的保存。但如果稍微有一点难度，如会风化（硫酸铜）、吸湿（氢氧化钠）、光解（三草酸合铁酸钾）、热分解（高锰酸钾）、氧化（硫酸亚铁），只用密封袋保存的话，它们会迅速变质，因此往往将晶体用清漆包裹一层再放入密封袋。</p> <ol start="4"> <li>西林瓶+液体石蜡（石蜡油）</li> </ol> <p>能够较为长久地保存晶体，但是坏处在于石蜡油极其难以清除，如果需要使用晶体或者用其他方法保存晶体，表面的石蜡油就很难清理干净了。</p> <ol start="5"> <li>环氧树脂</li> </ol> <p>这个方法可以非常长久的保存晶体 （除了光解、 热分解的晶体） ， 方便把玩，不怕摔碎， 实在是保存晶体的上佳方式。 但是不建议与还原性物质一起使用， 可能会造成晶体的氧化变质，比如硫酸亚铁可能会氧化发黑[^5]。</p> <p> 环氧树脂里的铁氰化钾[^6] </p> <h2>三、 实验安全</h2> <h3>（一）选材安全</h3> <p>应当遵守法律法规，遵守《危险化学品安全管理条例》、《中华人民共和国治安管理处罚法》、 《中华人民共和国消防法》，不使用有毒有机溶剂结晶、不使用有毒性、致癌的药品，如重铬酸钾。</p> <h3>（二）过程安全</h3> <ol> <li>生活区与实验区必须完全分离， 生活区禁止存放化学试剂， 特别是禁止在冰箱中同时存放食物和化学试剂；试验区不得进食或使用厨具。</li> <li>戴手套， 尤其是使用重金属盐时， 不戴手套最常见的问题是镍离子导致皮肤过敏、重金属盐（如银离子）导致手掌蛋白质变色。</li> <li>不使用不规范、有风险的操作，如：直接加热烧杯、重复使用过滤纸，纱布及一切滤纸代用品，并且应逐步取消明火加热。</li> </ol> <h2>四、 环保要求</h2> <p>尤其需要注意的是废水排放需要遵循《污水综合排放标准》，排入下水道应遵循《污水排入城市下水道水质标准》[^7]，以铜为例，排入下水道的废液中总铜含量应小于 2mg/L。</p> <p>以硫酸铜为例给出晶体废液的可能处理方式：</p> <ol> <li>储存或放回母液中</li> <li>用于制备其他试剂，如斐林试剂</li> <li>蒸干回收硫酸铜</li> <li>硫化钠沉淀铜离子</li> <li>碱沉淀铜离子</li> <li>活泼金属置换铜</li> </ol> <h2>五、 总结</h2> <p>家庭制作纯净物晶体的出发点是为了满足对化学实验的好奇、 满足对美丽的化学晶体的喜爱。 仍然记得我做出来的第一个晶体是硫酸铜， 当我把热饱和溶液倒入结晶皿的时候内心非常激动， 甚至盖好了滤纸 （防止灰尘进入） 还是忍不住每隔一小会就揭开看一眼， 最后当我看到了清澈的蓝色溶液中出现了小小的， 但是清晰可见的平行四边形晶体的时候，内心的激动真的是无以言表。</p> <p>回到最开始提出的问题，家庭实验是否是有意义的，如果是在化学领域深耕多年的相关从业者， 他可能会说家庭实验毫无意义， 与学习相比是舍本逐末； 而如果是刚开始学习的小白（比如当年的我）可能会说这是兴趣与知识的桥梁。</p> <p>如果要由现在的我来评价，在对化学实验有了更理性的认识，收起所有仪器之后，我会说家庭实验可能并不是最理想的学习方式。如果我反思当时的经历，会发现实际上自己完全没有实验规划，只是看到了有趣的实验现象，就会想去尝试复现，完成后又想尝试下一个，因此实验的重点在于观察现象而不是实验前后的思考，这就使实验失去了其教育意义。</p> <p>有观点认为，几百年前的化学家通过随机实验发现了许多有意义的反应。然而，这种说法并不准确。事实上，化学家们是基于已有反应构建模型，通过模型预测其他反应的结果，再进行实验验证。这种假说演绎法具有科学思维的意义，与单纯追求实验效果的做法有本质区别。</p> <p>本文所述晶体均为亲身制备经历。限于篇幅，未能详述其他晶体的制备过程，如淡粉色的硫酸锰、淡黄色的亚铁氰化钾。正是这些晶体的美感促使我研究单晶的制备技术。时至今日，每一个制备的晶体仍历历在目，这或许正是化学的魅力所在。</p> <p>谨以此文总结我在中学阶段与化学的故事和对化学的热爱。</p> <hr> <p>[^1]: 翁贤芬. 大颗粒氯化钠的制备研究[J]. 盐业与化工, 2009.</p> <p>[^2]: 双色大饼，你值得拥有[EB/OL]. 百度贴吧. https://tieba.baidu.com/p/7821134717</p> <p>[^3]: 从零开始的晶体教程（3）[EB/OL]. 科创网. https://www.kechuang.org/t/88078</p> <p>[^4]: 百度贴吧[EB/OL]. https://tieba.baidu.com/p/7714718573</p> <p>[^5]: 从零开始的晶体教程（3.5）[EB/OL]. 科创网. https://www.kechuang.org/t/88081</p> <p>[^6]: 百度贴吧[EB/OL]. https://tieba.baidu.com/p/7714718573</p> <p>[^7]: GB/T 31962-2015, 污水排入城镇下水道水质标准[S]. http://www.wxbh.gov.cn/doc/2022/09/01/3743836.shtml</p>https://www.lyt0112.com/blog/compiler_principles_lab_note-zhhttps://www.lyt0112.com/blog/compiler_principles_lab_note-zhImplement a compiler that compiles SysY language to Koopa IR, finally to RISC-V assemblySun, 12 Jan 2025 02:15:00 GMT<p>import { Aside } from '@/components/user' import GithubCard from '@/components/advanced/GithubCard.astro'</p> <h2>Related Links</h2> <ol> <li> <p><a href="https://github.com/EmptyBlueBox/Compiler_Principles-2024Fall-PKU">编译原理资料仓库</a></p> </li> <li> <p>本文档中所有代码均在 <a href="https://github.com/EmptyBlueBox/Compiler_Principles_Lab-2024Fall-PKU">我的编译原理 Lab 仓库</a> 中开源, 欢迎大家参考.</p> </li> <li> <p><a href="https://pku-minic.github.io/online-doc/#/">实验文档</a></p> </li> <li> <p><a href="https://course.educg.net/">实验评测平台</a></p> </li> <li> <p><a href="https://gitlab.eduxiji.net/">实验代码上传平台: GitLab</a></p> </li> <li> <p><a href="https://arthals.ink/tags/%E7%BC%96%E8%AF%91%E5%8E%9F%E7%90%86">Arthals 的编译原理资料</a></p> </li> </ol> <ul> <li>记录编程过程中的思考和编码规范, 通过制定明确的原则来提高代码的可读性和可维护性, 例如寄存器和栈的管理策略.</li> <li>通过具体示例展示一些最佳实践, 致力于<strong>在代码抽象程度和可读性之间寻求平衡</strong>, 以实现逻辑简洁性和代码可理解性的统一.</li> <li>补充实验文档中未详细说明的问题及其解决方案, 为后续实验者提供参考.</li> </ul> <p>以下是一些小建议~</p> <ul> <li>一个较容易的完成 Lab 的方法是在写每一个 Lab <code>x</code> 的时候, 将我的 (或者别人的) Lab <code>x-1</code> 和 Lab <code>x</code> 的代码进行对比, 比如 <code>VSCode</code> 的 <code>compare selected</code> 功能, 然后在自己的 Lab <code>x-1</code> 的基础上写 Lab <code>x</code> 的代码 (而不是抄袭别人的 Lab <code>x</code> 的代码) , 这样能保证考虑到所有的逻辑, 大幅减少 debug 的时间, 还能锻炼自己阅读代码的能力 🌚.</li> <li>每一个 Level 的测试点在你实现正确的情况下都是可以全部通过的, 如果你没有通过说明你的逻辑存在问题, 不存在需要后面的特性才能解决前面测试点的情况.</li> <li>强烈建议大家在大四没有绩点压力的时候选这门课! <ul> <li>这样最后可以放掉 Lv9 不完成, 因为 Lv9 非常浪费时间并且占所有 Lab 的 <code>27%</code> 的分数, 也就是总评的 8 分, 如果你在绩点压力下完成所有 Lab 会浪费很多时间.</li> </ul> </li> </ul> <h2>Lv 0</h2> <h3>Prepare Environment</h3> <p>首先安装并运行 <a href="https://www.docker.com/">Docker</a> .</p> <p>拉取镜像:</p> <pre><code class="language-bash">docker pull maxxing/compiler-dev </code></pre> <p>使用镜像创建容器:</p> <pre><code class="language-bash">docker run -it --name compiler -v &#x3C;compiler_lab_path>:/root/compiler maxxing/compiler-dev bash </code></pre> <p>其中参数的含义:</p> <ul> <li><code>-it</code> 表示以交互模式运行容器.</li> <li><code>--name compiler</code> 表示将容器重命名为 <code>compiler</code>.</li> <li><code>-v &#x3C;compiler_lab_path>:/root/compiler</code> 表示将宿主机的编译 Lab 项目文件夹挂载到容器中.</li> <li><code>maxxing/compiler-dev</code> 表示使用 <code>maxxing</code> 提供的 <code>compiler-dev</code> 镜像.</li> <li><code>bash</code> 表示以 <code>bash</code> 为启动命令.</li> </ul> <p>博主的编译项目结构类似这样, 其中 <code>~/Documents/xxx/Lv7</code> 就是你的宿主机编译 Lab 项目文件夹:</p> <pre><code class="language-bash">Mac OS 1926-08-17 12:00:00 emptyblue ~/Documents/xxx/Lv7 ❯ tree . ├── CMakeLists.txt └── src ├── include │   ├── koopa.h │   ├── koopa.hpp │   ├── koopa_util.hpp │   ├── riscv.hpp │   └── riscv_util.hpp ├── koopa.cpp ├── koopa_util.cpp ├── main.cpp ├── riscv.cpp ├── riscv_util.cpp ├── sysy.l └── sysy.y 3 directories, 13 files </code></pre> <p>如果非 MacOS, 可以加入 <code>--cap-add=SYS_PTRACE --security-opt seccomp=unconfined</code> 表示添加 <code>SYS_PTRACE</code> 权限, 取消 seccomp 限制, 以方便使用 <code>LLDB</code> 在 Docker 中调试.</p> <p>但是我没有找到方法在 MacOS 上的 Docker 中运行 <code>LLDB</code>, 如果你找到了可以解决这个问题的办法, 可以在下面写一个评论!</p> <p>2024-12-23 Update:</p> <p>似乎助教的实验文档提及了如何调试: <a href="https://pku-minic.github.io/online-doc/#/misc-app-ref/environment?id=%E8%B0%83%E8%AF%95-risc-v-%E7%A8%8B%E5%BA%8F">调试 risc-v 程序</a></p> <p>每次需要进入容器时, 先启动容器, 再进入:</p> <pre><code class="language-bash">docker start compiler docker exec -it compiler bash </code></pre> <p>退出容器 (Control + D):</p> <pre><code class="language-bash">exit </code></pre> <p>查看所有容器:</p> <pre><code class="language-bash">docker ps -a </code></pre> <p>停止所有容器:</p> <pre><code class="language-bash">docker stop $(docker ps -aq) </code></pre> <p>删除 <code>compiler</code> 容器:</p> <pre><code class="language-bash">docker rm -f compiler </code></pre> <p>删除所有容器:</p> <pre><code class="language-bash">docker rm $(docker ps -aq) </code></pre> <h3>Compile and Test</h3> <p>请仔细阅读 <a href="https://pku-minic.github.io/online-doc/#/misc-app-ref/environment">实验环境使用说明</a> .</p> <p>使用 <code>cmake</code> 生成 Makefile 文件, 指定编译类型为 <code>Debug</code>:</p> <pre><code class="language-bash">cmake -DCMAKE_BUILD_TYPE=Debug -B build </code></pre> <p>使用 <code>cmake</code> 生成 Makefile 文件, 不指定编译类型:</p> <pre><code class="language-bash">cmake -B build </code></pre> <p>使用 <code>cmake</code> 编译:</p> <pre><code class="language-bash">cmake --build build </code></pre> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.koopa</code>:</p> <pre><code class="language-bash">./build/compiler -koopa debug/hello.c -o debug/hello.koopa </code></pre> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.S</code>:</p> <pre><code class="language-bash">./build/compiler -riscv debug/hello.c -o debug/hello.S </code></pre> <p>本地自动评测 <code>koopa</code>:</p> <pre><code class="language-bash">autotest -koopa -s lv&#x3C;lv_number> /root/compiler </code></pre> <p>本地自动评测 <code>riscv</code>:</p> <pre><code class="language-bash">autotest -riscv -s lv&#x3C;lv_number> /root/compiler </code></pre> <p>如果本地测试不通过, 可以把 <code>/opt/bin/testcases</code> 中的测试用例复制到当前路径进行查看调试.</p> <pre><code class="language-bash">cp -r /opt/bin/testcases . </code></pre> <p>如果想测试自己的测试用例, 可以将自己的测试用例所在的目录传给 <code>autotest</code> 命令, 比如:</p> <pre><code class="language-bash">autotest -t &#x3C;test_case_dir> /root/compiler </code></pre> <p>注意每一个 Test Case 包含两个名称相同的 <code>.c</code> 和 <code>.out</code> 文件, 其中 <code>.c</code> 是输入给编译器的代码, <code>.out</code> 是你的编译器应该返回的结果.</p> <h2>Lv 1</h2> <p>Lab 的第一个 checkpoint 要求大家完成编译器的基础逻辑结构搭建, 包括:</p> <ul> <li>词法分析器的逻辑</li> <li>语法分析器的逻辑</li> <li>简单的中间代码 <code>Koopa</code> 生成器</li> </ul> <p>我使用的是 CMake 作为构建系统, 采用了 <a href="https://github.com/pku-minic/sysy-cmake-template">基于 CMake 的 SysY 编译器项目模板</a> 的结构.</p> <p>可以先把<a href="https://pku-minic.github.io/online-doc/#/">实验文档</a>中 <code>Lv 1</code> 中给出的代码复制下来作为 <code>codebase</code> .</p> <h3>Lexer</h3> <p>我们只需要在 <code>src/sysy.l</code> 中写一段代码说明如何定义 Token 类型, 如何把读到的字符串转化为整数或者浮点数, 然后就可以使用 <code>flex</code> 读入 <code>src/sysy.l</code> 来生成词法分析器, 所以实际上不用自己写一个词法分析器.</p> <p><code>flex</code> 的输入文件的语法规则可以参考<a href="https://pku-minic.github.io/online-doc/#/lv1-main/lexer-parser">实验文档对应章节</a> .</p> <p>示例:</p> <pre><code class="language-asm">"int" { return INT; } "return" { return RETURN; } {Identifier} { yylval.str_val = new string(yytext); return IDENT; } {Decimal} { yylval.int_val = strtol(yytext, nullptr, 0); return INT_CONST; } </code></pre> <p>其中 <code>INT</code>, <code>RETURN</code>, <code>IDENT</code> 等返回值, 其实是 Bison 生成的固定枚举类型值, 就是一个整数.</p> <p>所以这段代码代表的含义为:</p> <ul> <li><code>"int"</code> 和 <code>"return"</code> 是正则表达式, 这就是告诉当匹配到这些字符串时, 返回给语法分析器 <code>INT</code> 和 <code>RETURN</code> 类型, 告诉语法分析器这是一个保留字.</li> <li><code>{Identifier}</code> 是上面定义好的正则表达式, 当这个表达式匹配到某个字符串时, 将这个字符串赋值给语法分析器定义的 <code>yylval.str_val</code> 变量, 然后返回给语法分析器 <code>IDENT</code> 类型, 告诉语法分析器这是一个标识符, 比如函数名, 语法分析器知道现在读取到了一个标识符, 就从 <code>yylval.str_val</code> 中取出这个字符串.</li> <li><code>{Decimal}</code> 是上面定义好的正则表达式, 当这个表达式匹配到某个字符串时, 将这个字符串赋值给语法分析器定义的 <code>yylval.int_val</code> 变量, 然后返回给语法分析器 <code>INT_CONST</code> 类型, 告诉语法分析器这是一个整数常量, 语法分析器知道现在读取到了一个整数常量, 就从 <code>yylval.int_val</code> 中取出这个整数.</li> </ul> <h3>Parser</h3> <p>我们只需要在 <code>src/sysy.y</code> 中写一段代码说明如何定义语法规则, 比如一个函数是如何由函数类型, 函数名, 变量声明列表和函数体组成的, 然后就可以使用 <code>bison</code> 读入 <code>src/sysy.y</code> 来生成语法分析器.</p> <p>规约示例:</p> <pre><code class="language-asm">FuncDef : FuncType IDENT '(' ')' Block { auto ast = new FuncDefAST(); ast->func_type = unique_ptr&#x3C;BaseAST>($1); ast->ident = *unique_ptr&#x3C;string>($2); ast->block = unique_ptr&#x3C;BaseAST>($5); $$ = ast; } </code></pre> <ul> <li>其中 <code>FuncDefAST</code> 等类是 <code>include/ast.hpp</code> 中由你定义好的, 其中包括了每个语法规则包含的语法单元, 比如 <code>FuncDef</code> 语法规则包含 <code>FuncType</code>, <code>IDENT</code>, <code>Block</code> 等语法单元, 语法分析器现在使用这些类来构造抽象语法树.</li> <li><code>$1</code> 是代表子语法单元的变量, 比如 <code>FuncDef</code> 语法规则的第一个子语法单元是 <code>FuncType</code>, 那么 <code>$1</code> 就代表 <code>FuncType</code>, 语法分析器递归地从 <code>FuncType</code> 继续规约, 注意这里的变量标号是从 1 开始的.</li> <li><code>$$ = ast;</code> 是告诉语法分析器, <code>FuncDef</code> 语法规则规约的结果是一个 <code>FuncDefAST</code> 类, 语法分析器现在知道 <code>FuncDef</code> 语法规则规约的结果 <code>FuncDefAST</code> 类中都是什么数据了.</li> </ul> <h3><code>Koopa IR</code> Generation</h3> <p>当语法分析器规约出抽象语法树后, 我们就可以遍历抽象语法树, 遇到叶子节点就 <code>print</code> , 遍历结束就生成了中间代码 <code>Koopa</code>.</p> <p>在 <code>main.cpp</code> 中定义编译器本身的 <code>main</code> 函数, 读入需要编译的源文件, 调用词法分析器和语法分析器, 得到放好数据的抽象语法树, 然后调用语法树类中定义好的 <code>print</code> 函数生成中间代码 <code>Koopa</code>.</p> <p>我的具体结构安排是:</p> <ul> <li>在 <code>main.cpp</code> 中定义编译器本身的 <code>main</code> 函数, 读入需要编译的源文件, 调用词法分析器和语法分析器, 得到放好数据的抽象语法树, 然后调用语法树类中定义好的 <code>print</code> 函数生成中间代码 <code>Koopa</code>.</li> <li>在 <code>include/ast.hpp</code> 中定义抽象语法树的节点类, 每个节点类中定义一个 <code>print</code> 函数, 用于生成中间代码 <code>Koopa</code> 或 Debug 信息.</li> <li>在 <code>ast.cpp</code> 中定义抽象语法树的各个节点类, 并实现 <code>print</code> 函数.</li> </ul> <h3>Incomplete Parts of the Codebase</h3> <p>在 handout 给出的 codebase 中, 词法分析器和语法分析器大部分已经写好了, 但是还有一些需要修改的地方:</p> <ul> <li>在 <code>src/sysy.y</code> 中, 需要加入 <code>include/ast.hpp</code> 的引用, 否则语法分析器会找不到你定义的抽象语法树的节点类, 就不能把数据写到你定义的抽象语法树中.</li> <li>在 <code>include/ast.hpp</code> 中, 需要定义示例代码中没有给出的抽象语法树的节点类, 并定义 <code>print</code> 函数.</li> <li>在 <code>ast.cpp</code> 中, 需要实现示例代码中没有实现的抽象语法树的各个节点类, 并实现 <code>print</code> 函数.</li> </ul> <p>确保在 <code>src/sysy.l</code> 中定义正确的 BlockComment 的正则表达式, 否则有一些测试点不通过.</p> <p>好的, 现在已经完成了编译器的基础逻辑结构搭建!</p> <h3>Compile and Test</h3> <p><strong>以下均默认你已经进入容器, 并且当前目录为编译 Lab 的一级目录.</strong></p> <p>使用 <code>cmake</code> 生成 Makefile 文件:</p> <pre><code class="language-bash">cmake -DCMAKE_BUILD_TYPE=Debug -B build </code></pre> <p>使用 <code>cmake</code> 编译:</p> <pre><code class="language-bash">cmake --build build </code></pre> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.koopa</code>:</p> <pre><code class="language-bash">./build/compiler -koopa debug/hello.c -o debug/hello.koopa </code></pre> <p>本地自动评测:</p> <pre><code class="language-bash">autotest -koopa -s lv1 /root/compiler </code></pre> <p>如果本地测试不通过, 可以把 <code>/opt/bin/testcases</code> 中的测试用例复制到当前路径进行查看调试.</p> <pre><code class="language-bash">cp -r /opt/bin/testcases . </code></pre> <h2>Lv 2</h2> <p>首先回顾一下编译器的三层结构:</p> <ul> <li><strong>前端</strong>: 通过词法分析和语法分析, 将源代码解析成抽象语法树 (abstract syntax tree, AST). 通过语义分析, 扫描抽象语法树, 检查其是否存在语义错误.</li> <li><strong>中端</strong>: 将抽象语法树转换为中间表示 (intermediate representation, IR), 并在此基础上完成一些机器无关优化.</li> <li><strong>后端</strong>: 将中间表示转换为目标平台的汇编代码, 并在此基础上完成一些机器相关优化.</li> </ul> <p>在 Lv 1 中已经完成了前端和中端, 现在来完成后端.</p> <p>虽说是完成后端, 但是实际上助教团队已经帮助实现好了能够处理 Koopa IR 的库, 我们只需要调用他们提供的库 (即调用 <code>koopa.h</code> 中定义的函数) 就可以完成后端的大部分实现了, 我们只需要自己实现 <code>RISC-V</code> 汇编代码的输出就可以了.</p> <p>具体如何调用, 参阅 <a href="https://pku-minic.github.io/online-doc/#/lv2-code-gen/processing-ir">实验文档</a> 把代码复制下来即可.</p> <p>最后的后端代码入口应该类似:</p> <pre><code class="language-cpp">#include "include/backend.hpp" int backend(const char *koopa_str) { // 解析字符串 str, 得到 Koopa IR 程序 koopa_program_t program; koopa_error_code_t ret = koopa_parse_from_string(koopa_str, &#x26;program); assert(ret == KOOPA_EC_SUCCESS); // 确保解析时没有出错 // 创建一个 raw program builder, 用来构建 raw program koopa_raw_program_builder_t builder = koopa_new_raw_program_builder(); // 将 Koopa IR 程序转换为 raw program koopa_raw_program_t raw = koopa_build_raw_program(builder, program); // 释放 Koopa IR 程序占用的内存 koopa_delete_program(program); // 处理 raw program visit(raw); // 处理完成, 释放 raw program builder 占用的内存 // 注意, raw program 中所有的指针指向的内存均为 raw program builder 的内存 // 所以不要在 raw program 处理完毕之前释放 builder koopa_delete_raw_program_builder(builder); return 0; } void visit(const koopa_raw_slice_t &#x26;slice) { // ... } void visit(const koopa_raw_program_t &#x26;program) { // ... } // ... </code></pre> <h3>Traverse the Abstract Syntax Tree</h3> <p>调用库之后我们就得到了以抽象语法树形式表示的 <code>RISC-V</code> 汇编代码, 现在需要 DFS 遍历这棵抽象语法树, 将其转换为字符串并输出, 我们选择使用函数递归的方式来遍历这棵抽象语法树, 具体如何遍历可以参考实验文档, 这里不再赘述, 但是有一些 high level 的 idea 可以帮助你理解这颗树上的各种助教定义的 type.</p> <p>这颗语法树的节点大致是 <code>program</code>, <code>function</code>, <code>basic_block</code>, <code>value</code>, 这些节点很多都包含同类型的东西, 比如一个程序有很多的函数, 一个函数有很多的基本块, 一个基本块有很多指令, 那么比如 <code>program</code> 这个节点的这一堆函数就会存在<strong>一个</strong> <code>koopa_raw_slice_t</code> 类型中, 所以对于一个 <code>program</code> 节点中的所有函数, 只需要对包含这些函数的这一个 <code>koopa_raw_slice_t</code> 调用一次 <code>visit</code> 函数即可, 如下所示, <code>visit</code> 函数会把这一堆东西逐个帮你访问.</p> <pre><code class="language-cpp">void visit(const koopa_raw_slice_t &#x26;slice) { for (size_t i = 0; i &#x3C; slice.len; ++i) { auto ptr = slice.buffer[i]; // 根据 slice 的 kind 决定将 ptr 视作何种元素 switch (slice.kind) { case KOOPA_RSIK_FUNCTION: // 访问函数 visit(reinterpret_cast&#x3C;koopa_raw_function_t>(ptr)); break; case KOOPA_RSIK_BASIC_BLOCK: // 访问基本块 visit(reinterpret_cast&#x3C;koopa_raw_basic_block_t>(ptr)); break; case KOOPA_RSIK_VALUE: // 访问指令 visit(reinterpret_cast&#x3C;koopa_raw_value_t>(ptr)); break; default: // 我们暂时不会遇到其他内容, 于是不对其做任何处理 assert(false); } } } </code></pre> <p>访问 <code>koopa_raw_value_t</code> 类型的函数大致如下所示, <code>koopa_raw_value_t</code> 类型是一个指针, 这个指针可以指向 <code>RISC-V</code> 汇编代码的一个值 (一条指令的结果可以代表这个指令, 所以一条指令也算一个值) .</p> <p>如果碰上代表一个指令, 就可能重复调用 <code>visit koopa_raw_value_t</code> 两次, 因为指令中包含值, 比如调用 <code>visit koopa_raw_value_t</code> 时发现这是一个返回指令, 就调用 <code>visit koopa_raw_return_t</code> , 返回值就会需要再调用一次 <code>visit koopa_raw_value_t</code>.</p> <pre><code class="language-cpp">void visit(const koopa_raw_value_t &#x26;value) { // 根据指令类型判断后续需要如何访问 const auto &#x26;kind = value->kind; switch (kind.tag) { case KOOPA_RVT_RETURN: // 访问 return 指令 visit(kind.data.ret); break; case KOOPA_RVT_INTEGER: // 访问 integer 指令 visit(kind.data.integer, value); break; // ... default: // 其他类型暂时遇不到 throw std::runtime_error("visit: invalid instruction"); } } </code></pre> <h3>Link Middleend and Backend</h3> <p>与此同时, 你还需要将你在 Lv 1 中输出的 <code>Koopa IR</code> 输入给后端, 在这里我推荐使用 <code>std::stringstream</code> 类型来存储 <code>Koopa IR</code>, 然后交给后端即可, 实现代码可以类似:</p> <pre><code class="language-cpp">std::ostringstream koopa_ir; // 用于存储 Koopa IR 的 stringstream // ... ast->print(&#x26;koopa_ir); // ... // inside print(): 你的中端代码将 Koopa IR 输出到 koopa_ir 中 // ... freopen(output, "w", stdout); // 将 stdout 重定向到 output 文件, output 是你的输出文件路径 backend(koopa_ir.str().c_str()); // 将 stringstream 转换为 C style string 后交给后端 // ... // inside backend(): 后端代码将 RISC-V 汇编代码输出到 stdout 中 // ... fclose(stdout); </code></pre> <p>这样写的优点包括:</p> <ul> <li>实现简洁明了.</li> <li>无需进行硬盘交互 (把 Koopa IR 输出到文件系统再从硬盘读取, 再交给后端), 这样实现之后 Koopa IR 的数据保存在内存中, 后端直接从内存中读取即可.</li> </ul> <h3>Compile and Test</h3> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.S</code>:</p> <pre><code class="language-bash">./build/compiler -riscv debug/hello.c -o debug/hello.S </code></pre> <p>本地自动评测:</p> <pre><code class="language-bash">autotest -riscv -s lv1 /root/compiler </code></pre> <h2>Lv 3</h2> <p>本章将在上一章的基础上, 实现一个能够处理表达式 (一元/二元) 的编译器.</p> <p>需要完成对抽象语法树和 <code>RISC-V</code> 汇编代码输出这两部分的修改.</p> <p>你的编译器将可以处理如下的 SysY 程序:</p> <pre><code class="language-cpp">int main() { return 1 + 2 * -3; } </code></pre> <p>需要完成对抽象语法树和 <code>RISC-V</code> 汇编代码输出这两部分的修改.</p> <h3>Lexer</h3> <p>修改 <code>src/sysy.l</code> 文件, 添加对运算符的识别, 比如 <code>!</code> 和 <code>-</code> 运算符.</p> <pre><code class="language-asm">/* 运算符 */ ExclusiveUnaryOp "!" MulOp [\*/%] AddOp [\+\-] RelOp ("&#x3C;"|">"|"&#x3C;="|">=") EqOp ("=="|"!=") AndOp "&#x26;&#x26;" OrOp "||" </code></pre> <p>这里我的逻辑是对每一种运算都定义一个正则表达式, 用来表达这个运算会使用的所有字符, 这样就不用在语法分析器中对每一个运算符都写一个规约规则了.</p> <p>但是有一个问题是单元运算符和二元加减运算符有两个符号是重叠的, 所以我选择使用 <code>ExclusiveUnaryOp</code> 来表示只有单元运算符使用的符号, <code>AddOp</code> 就代表着单元运算和二元加减运算共同使用的符号了.</p> <p>另外还要加入识别 token 之后如何返回给语法分析器, 类似 <code>Identifier</code> 和 <code>Decimal</code> 那样, 使用 <code>yylval</code> 来返回字符串给语法分析器.</p> <pre><code class="language-asm">{ExclusiveUnaryOp} { yylval.str_val = new string(yytext); return EXCLUSIVE_UNARY_OP; } </code></pre> <h3>Parser</h3> <p>修改 <code>src/sysy.y</code> 文件和 <code>include/ast.hpp</code> 文件, 添加对新的语法规则的规约.</p> <p>举例说明:</p> <pre><code class="language-asm">UnaryExp : PrimaryExp { auto ast = new UnaryExpAST(); ast->primary_exp = unique_ptr&#x3C;BaseAST>($1); $$ = ast; } | EXCLUSIVE_UNARY_OP UnaryExp { auto ast = new UnaryExpAST(); ast->op = *unique_ptr&#x3C;string>($1); ast->unary_exp = unique_ptr&#x3C;BaseAST>($2); $$ = ast; } | ADD_OP UnaryExp { auto ast = new UnaryExpAST(); ast->op = *unique_ptr&#x3C;string>($1); ast->unary_exp = unique_ptr&#x3C;BaseAST>($2); $$ = ast; } ; </code></pre> <p>对应如下的抽象语法树类:</p> <pre><code class="language-cpp">/** * @brief 一元表达式抽象语法树类. */ class UnaryExpAST : public BaseAST { public: std::optional&#x3C;std::unique_ptr&#x3C;BaseAST>> primary_exp; // 可选的基本表达式 std::optional&#x3C;std::string> op; // 可选的操作符 ("+", "-", "!") std::optional&#x3C;std::unique_ptr&#x3C;BaseAST>> unary_exp; // 可选的一元表达式 /** * @brief 打印抽象语法树. * @param[in] output_stream 输出流. * @return 打印操作的结果 */ Result print(std::stringstream &#x26;output_stream) const override; // 打印抽象语法树, 稍后解释这个返回类型的用处 }; </code></pre> <p>其中有两个实现细节:</p> <ol> <li><code>std::optional</code> <ol> <li>是 <strong>C++17</strong> 引入的类型, 你可能需要修改 <code>VSCode</code> 的编译器版本, 否则无法正常高亮显示.</li> <li>它用于表示一个可能存在也可能不存在的值, 如果值存在, 则可以使用 <code>value()</code> 方法获取该值, 如果值不存在, 则可以使用 <code>has_value()</code> 方法判断是否存在, 或者使用 <code>operator*</code> 获取该值, 用来判断在多个规约规则中具体选了那个规约规则.</li> <li>比如下面的规约规则有两个选择, 分别是 <code>PrimaryExp</code> 和 <code>UnaryOp UnaryExp</code>, 如果选择了 <code>PrimaryExp</code> 那么 <code>primary_exp</code> 就会存在, <code>op</code> 和 <code>unary_exp</code> 就不存在, 反之亦然.</li> </ol> </li> <li><code>print</code> 函数返回一个 <code>Result</code> 类型的变量, 稍后解释这个返回类型的用处.</li> </ol> <p>以上的代码代表着如下的规约规则:</p> <pre><code class="language-asm">UnaryExp ::= PrimaryExp | UnaryOp UnaryExp; UnaryOp ::= "+" | "-" | "!"; </code></pre> <p>其中使用了我们在对词法分析器作修改的时候定义的新 token 种类 <code>EXCLUSIVE_UNARY_OP</code> 和 <code>ADD_OP</code>.</p> <p>当然别忘了要在 <code>src/sysy.y</code> 文件中定义新的终结符和非终结符的类型.</p> <pre><code class="language-asm">// lexer 返回的所有 token 种类的声明, 终结符的类型为 str_val 和 int_val %token INT RETURN %token &#x3C;str_val> IDENT %token &#x3C;int_val> INT_CONST %token &#x3C;str_val> EXCLUSIVE_UNARY_OP MUL_OP ADD_OP REL_OP EQ_OP AND_OP OR_OP // Operators // 非终结符的类型定义 %type &#x3C;ast_val> FuncDef FuncType Block Stmt Exp UnaryExp PrimaryExp MulExp AddExp LOrExp LAndExp RelExp EqExp %type &#x3C;int_val> Number </code></pre> <h3><code>Koopa IR</code> Generation</h3> <p>修改 <code>ast.cpp</code> 文件, 添加对新的语法规则的 <code>print</code> 函数.</p> <p>在实现之前我们先来思考一个例子:</p> <pre><code class="language-cpp">int main() { return 6; } </code></pre> <p>这是之前的编译器可以处理的代码, 我们在调用 <code>RetAST</code> 的 <code>print</code> 函数时, 先输出 <code>ret </code> 然后调用 <code>NumberExpAST</code> 的 <code>print</code> 函数, 输出 <code>6</code>, 最后回到 <code>RetAST</code> 的 <code>print</code> 函数输出 <code>\n</code>, 就可以得到如下的 <code>Koopa IR</code> 代码:</p> <pre><code class="language-asm">fun @main(): i32 { %entry: ret 6 } </code></pre> <p>现在我们考虑这个例子:</p> <pre><code class="language-cpp">int main() { return -6; } </code></pre> <p>如果还是按照之前的逻辑, 先输出 <code>ret </code> 然后调用 <code>ExpAST</code> 的 <code>print</code> 函数, 就会出现问题, 因为我们还需要一个 <code>sub</code> 指令才能计算出 <code>-6</code>, 但是此时 <code>Koopa IR</code> 已经输出到文件中了, 我们无法在 <code>ret</code> 指令后面继续输出 <code>sub</code> 指令了.</p> <p>这是我们期望得到的 <code>Koopa IR</code> 代码:</p> <pre><code class="language-asm">fun @main(): i32 { %entry: %0 = sub 0, 6 ret %0 } </code></pre> <p>所以我们在进入任何一个 <code>print</code> 函数时, 不能先入为主地输出任何 <code>Koopa IR</code> 指令, 需要先调用这个抽象语法树的所有子变量的 <code>print</code> 函数, 等到它们把类似上文的 <code>sub</code> 指令输出完成之后再输出当前的 <code>Koopa IR</code> 指令.</p> <p>但是如果子变量的所有 <code>print</code> 函数都没有返回任何信息, 那么我们怎么知道这些子变量把计算结果储存到哪里了呢?</p> <p>比如 <code>RetAST</code> 的 <code>print</code> 函数, 当它调用完成 <code>ExpAST</code> 的 <code>print</code> 函数之后, 它怎么知道 <code>ExpAST</code> 的计算结果是储存在 <code>%0</code> 这个寄存器中了而不是 <code>%1</code> 或者其他寄存器中呢?</p> <p>我们不希望使用全局变量解决任何问题, 这样非常 dirty, 所以我们需要每一个 <code>print</code> 函数返回一个 <code>Result</code> 类型的变量, 告诉父变量这个子变量的计算结果储存在哪里, 以便父变量决定如何输出当前的 <code>Koopa IR</code> 指令.</p> <pre><code class="language-cpp">/** * @brief 用于存储计算结果的类, 可以是符号或立即数. * @note 如果当前函数会产生一个计算结果, 那么这个计算结果会存储在返回的 `Result` 类型的变量中 * @note 比如 `PrimaryExpAST` 的 `print` 函数, 当它是从数字规约而来时, 它的 `Result` 变量会被初始化为立即数, 返回 `Result(Result::Type::IMM, *number)` 这样一个变量 * @note 如果当前函数不会产生计算结果, 那么返回的 `Result` 变量会被初始化为立即数 0 * @date 2024-11-27 */ class Result { public: /** * @brief 当前计算值, 存储在 `%current_value_symbol_index` 符号中. * @date 2024-11-27 */ static int current_symbol_index; enum class Type { IMM, // 立即数 REG // 寄存器 }; Type type; // 结果的类型 int val; // 结果的值 // 默认构造函数, 初始化为立即数 0, 没有用到它的地方 Result() : type(Type::IMM), val(0) {} // 带有指定类型的构造函数, 主要用来初始化寄存器 Result(Type type) : type(type), val(0) { if (type == Type::REG) { val = ++current_symbol_index; } } // 带有指定类型和值的构造函数, 主要用来初始化立即数 Result(Type type, int val) : type(type), val(val) { if (type == Type::REG) { val = ++current_symbol_index; } } // 重载 &#x3C;&#x3C; friend std::ostream &#x26;operator&#x3C;&#x3C;(std::ostream &#x26;os, const Result &#x26;result) { os &#x3C;&#x3C; (result.type == Result::Type::REG ? "%" : "") &#x3C;&#x3C; result.val; return os; } }; </code></pre> <p><code>Result</code> 类中有一个静态变量 <code>current_symbol_index</code>, 这个变量用于给每一个计算结果分配一个唯一的寄存器. 当 <code>Result</code> 类被初始化为立即数时, 这个变量不会被用到, 而当 <code>Result</code> 类被初始化为寄存器时, 这个变量会被用来给计算结果分配一个唯一的寄存器, 然后这个 <code>current_symbol_index</code> 的值会加一.</p> <p>同时为了方便输出寄存器和立即数, 我们重载了 <code>&#x3C;&#x3C;</code> 操作符.</p> <pre><code class="language-cpp">Result UnaryExpAST::print(std::stringstream &#x26;output_stream) const { if (primary_exp &#x26;&#x26; !op &#x26;&#x26; !unary_exp) { return (*primary_exp)->print(output_stream); } else if (!primary_exp &#x26;&#x26; op &#x26;&#x26; unary_exp) { Result unary_result = (*unary_exp)->print(output_stream); Result result = Result(Result::Type::REG); if (*op == "+") { output_stream &#x3C;&#x3C; "\t" &#x3C;&#x3C; result &#x3C;&#x3C; " = add 0, " &#x3C;&#x3C; unary_result &#x3C;&#x3C; "\n"; } else if (*op == "-") { output_stream &#x3C;&#x3C; "\t" &#x3C;&#x3C; result &#x3C;&#x3C; " = sub 0, " &#x3C;&#x3C; unary_result &#x3C;&#x3C; "\n"; } else if (*op == "!") { output_stream &#x3C;&#x3C; "\t" &#x3C;&#x3C; result &#x3C;&#x3C; " = eq 0, " &#x3C;&#x3C; unary_result &#x3C;&#x3C; "\n"; } else { throw std::runtime_error("UnaryExpAST::print: invalid unary operator"); } return result; } else { throw std::runtime_error("UnaryExpAST::print: invalid unary expression"); } } </code></pre> <p>这样看起来就很清晰了.</p> <ol> <li>当 <code>UnaryExpAST</code> 的 <code>print</code> 函数被调用时, 如果它选择了 <code>UnaryExp ::= PrimaryExp</code> 这条规约规则, 那么它就会调用 <code>PrimaryExpAST</code> 的 <code>print</code> 函数</li> <li>此时 <code>UnaryExpAST</code> 并没有做任何计算, 所以直接返回 <code>PrimaryExpAST</code> 的计算结果即可.</li> <li>如果它选择了 <code>UnaryExp ::= UnaryOp UnaryExp</code> 这条规约规则, 就需要根据 <code>UnaryOp</code> 的值输出相应的 <code>Koopa IR</code> 指令, 运算的结果需要使用一个新的寄存器来储存, 所以构造一个新的 <code>Result(Result::Type::REG)</code> 变量, 并返回这个变量.</li> <li>最后如果出现任何例外情况, 直接抛出异常, 这样是很好的防御型编程操作实践.</li> </ol> <h3><code>RISC-V</code> Assembly Code Generation</h3> <p>在这一部分你需要修改 <code>include/backend.hpp</code> 和 <code>src/backend.cpp</code> 文件, 完成新的语法规则的 <code>print</code> 函数来输出 <code>RISC-V</code> 汇编代码.</p> <p>这部分的难点在于如何分配寄存器, 储存在内存中的 <code>RISC-V</code> 汇编代码是没有进行寄存器分配的.</p> <p>比如一个加法运算, 你只知道左操作数和右操作数是两个表达式, 但是你并不知道这两个表达式的结果分别在哪个寄存器当中, 内存中的汇编代码也不提供具体的寄存器编号, 所以你需要在输出的同时为每一行运算都分配一个寄存器来保存运算的结果, 并且不能覆盖之前刚计算完还没用过的寄存器.</p> <p>寄存器分配问题是一个 NPC 问题, 但是很好的一点是 Lv3 的测试样例中不会出现需要寄存器复用的情况, 所以我们可以使用贪心算法来解决这个问题.</p> <p>首先仔细观察一个例子:</p> <pre><code class="language-cpp">int main() { return 1 + 2 * -3; } </code></pre> <p>可以得到如下 <code>RISC-V</code> 汇编代码:</p> <pre><code class="language-asm"> .text .globl main main: li t0, 2 li t1, 3 mul t1, t0, t1 li t2, 1 add t2, t1, t2 mv a0, t2 ret </code></pre> <p>可以发现当前<strong>每一行汇编代码的计算结果都只会被使用一次</strong>, 如果把这个汇编代码修改为:</p> <pre><code class="language-asm"> .text .globl main main: li t0, 2 li t1, 3 mul t0, t0, t1 li t1, 1 add t0, t0, t1 mv a0, t0 ret </code></pre> <p>不会有任何问题.</p> <h3><code>RISC-V</code> Register Manager</h3> <p>为了方便管理寄存器, 我设计了一个 <code>RegisterManager</code> 类, 这个类可以设置一个寄存器为可以覆盖, 判断一个值是否占用了一个寄存器, 给一个值分配一个寄存器, 输出某个值对应的寄存器名称.</p> <p>所有计算结果, 包括一个表达式, 一个立即数, 都是跟一个 <code>koopa_raw_value_t</code> 类型的指针一一对应的, 所以我们可以使用 <code>koopa_raw_value_t</code> 类型的指针来作为寄存器管理器中的键值, 这样就可以方便地找到一个值对应的寄存器名称.</p> <pre><code class="language-cpp">/** * @brief 寄存器管理器, 可以设置一个寄存器为可以覆盖, 判断一个值是否占用了一个寄存器, 给一个值分配一个寄存器, 输出某个值对应的寄存器名称 */ class RegisterManager { private: // 值到寄存器名称的映射 std::unordered_map&#x3C;koopa_raw_value_t, std::string> _value_to_reg_string; // 存储当前所有寄存器是否可能会再次被利用, 比如将立即数转移给 a0 寄存器, 我们现在就认为 a0 寄存器被占用了, 但是如果 a0 寄存器之后被调用了, 这个立即数被使用过了, 那么 a0 寄存器就会被标记为不被占用, 因为到目前为止我们认为每一个结果只被使用一次 std::unordered_map&#x3C;std::string, bool> _reg_is_used; /** * @brief 设置一个值对应哪个寄存器, 内部函数不被外部调用 * @param[in] value 值 * @param[in] reg_string 寄存器名称 */ void _set_value_to_reg_string(const koopa_raw_value_t &#x26;value, const std::string &#x26;reg_string); public: /** * @brief 构造函数, 初始化所有寄存器为未占用 */ RegisterManager() { // 初始化所有寄存器为未占用 for (int i = 0; i &#x3C;= 6; ++i) { _reg_is_used["t" + std::to_string(i)] = false; } for (int i = 0; i &#x3C;= 7; ++i) { _reg_is_used["a" + std::to_string(i)] = false; } } /** * @brief 设置一个值对应的寄存器为未占用, 当一个值被使用过之后, 我们将它占用的寄存器设置为未占用, 因为我们认为每一个结果只被使用一次 * @param[in] value 值 */ void set_reg_free(const koopa_raw_value_t &#x26;value); /** * @brief 判断一个值是否已经分配了寄存器 * @param[in] value 值 * @return 是否已经分配了寄存器 */ bool exist(const koopa_raw_value_t &#x26;value); /** * @brief 给一个值分配一个寄存器, 自动选择一个未被占用的寄存器 * @note x0 是一个特殊的寄存器, 它的值恒为 0, 且向它写入的任何数据都会被丢弃, t0 到 t6 寄存器, 以及 a0 到 a7 寄存器可以用来存放临时值 * @param[in] value 值 * @param[in] is_zero 如果是立即数, 那么是否是立即数 0 */ void allocate_reg(const koopa_raw_value_t &#x26;value, bool is_zero = false); /** * @brief 找出这个值占用哪个寄存器, 用于输出 RISC-V 汇编代码 * @param[in] value 值 * @return 寄存器名称 */ std::string value_to_reg_string(const koopa_raw_value_t &#x26;value); }; </code></pre> <h3><code>RISC-V</code> Assembly Code Output</h3> <p>为了方便维护 <code>RegisterManager</code> 类, 我选择将 <code>koopa_raw_value_t</code> 类型的指针也传给 <code>koopa_raw_integer_t</code> 和 <code>koopa_raw_binary_t</code> 的 <code>visit</code> 函数, 这样在这两个函数中就可以调用 <code>RegisterManager</code> 类的方法来管理寄存器了.</p> <pre><code class="language-cpp">// 访问 koopa_raw_value_t void visit(const koopa_raw_value_t &#x26;value) { const auto &#x26;kind = value->kind; switch (kind.tag) { case KOOPA_RVT_RETURN: visit(kind.data.ret); break; case KOOPA_RVT_INTEGER: visit(kind.data.integer, value); break; case KOOPA_RVT_BINARY: visit(kind.data.binary, value); break; default: throw std::runtime_error("visit: invalid instruction"); } } // 访问 return 指令 void visit(const koopa_raw_return_t &#x26;ret) { // 根据 ret 的 value 类型判断后续需要如何访问 if (ret.value) { // 特判如果是立即数, 则直接赋值给 a0 寄存器, 跳过访问 value 的过程 if (ret.value->kind.tag == KOOPA_RVT_INTEGER) { std::cout &#x3C;&#x3C; "\tli a0, " &#x3C;&#x3C; ret.value->kind.data.integer.value &#x3C;&#x3C; std::endl; } // 否则, 访问这个值, 然后把这个值存储在的寄存器名称移动给 a0 寄存器, 注意不是 li else { bool is_allocated = register_manager.exist(ret.value); if (!is_allocated) { visit(ret.value); } std::cout &#x3C;&#x3C; "\tmv a0, " &#x3C;&#x3C; register_manager.value_to_reg_string(ret.value) &#x3C;&#x3C; std::endl; } } // 如果 ret 的 value 为空, 则直接赋值 0 给 a0 寄存器, 然后返回 else { std::cout &#x3C;&#x3C; "\tli a0, 0" &#x3C;&#x3C; std::endl; } std::cout &#x3C;&#x3C; "\tret" &#x3C;&#x3C; std::endl; } // 访问 integer void visit(const koopa_raw_integer_t &#x26;integer, const koopa_raw_value_t &#x26;value) { if (integer.value == 0) { register_manager.allocate_reg(value, true); } else { register_manager.allocate_reg(value); std::cout &#x3C;&#x3C; "\tli " &#x3C;&#x3C; register_manager.value_to_reg_string(value) &#x3C;&#x3C; ", " &#x3C;&#x3C; integer.value &#x3C;&#x3C; std::endl; } } // 访问 binary 指令 void visit(const koopa_raw_binary_t &#x26;binary, const koopa_raw_value_t &#x26;value) { // lhs 和 rhs 是否已经分配过寄存器, 如果没分配过, 则需要先访问 lhs 和 rhs, 访问过程中会分配寄存器, 注意 ricsv 不能直接操作立即数, 必须先加载到寄存器中! bool lhs_is_allocated = register_manager.exist(binary.lhs); if (!lhs_is_allocated) { visit(binary.lhs); } bool rhs_is_allocated = register_manager.exist(binary.rhs); if (!rhs_is_allocated) { visit(binary.rhs); } // 我们认为每个结果仅使用一次, 所以可以设置两个子结果的寄存器可以被覆盖了. // 比如将立即数转移给 a0 寄存器, 我们现在就认为 a0 寄存器被占用了, 但是如果 a0 寄存器之后被调用了, 这个立即数被使用过了, 那么 a0 寄存器就会被标记为不被占用, 因为到目前为止我们认为每一个结果只被使用一次 register_manager.set_reg_free(binary.lhs); register_manager.set_reg_free(binary.rhs); register_manager.allocate_reg(value); // 获取当前结果, lhs 和 rhs 对应的寄存器名称 std::string cur = register_manager.value_to_reg_string(value); std::string lhs = register_manager.value_to_reg_string(binary.lhs); std::string rhs = register_manager.value_to_reg_string(binary.rhs); // 根据二元运算符的类型进行处理 switch (binary.op) { case KOOPA_RBO_EQ: std::cout &#x3C;&#x3C; "\txor " &#x3C;&#x3C; cur &#x3C;&#x3C; ", " &#x3C;&#x3C; lhs &#x3C;&#x3C; ", " &#x3C;&#x3C; rhs &#x3C;&#x3C; std::endl; std::cout &#x3C;&#x3C; "\tseqz " &#x3C;&#x3C; cur &#x3C;&#x3C; ", " &#x3C;&#x3C; cur &#x3C;&#x3C; std::endl; break; case KOOPA_RBO_NOT_EQ: std::cout &#x3C;&#x3C; "\txor " &#x3C;&#x3C; cur &#x3C;&#x3C; ", " &#x3C;&#x3C; lhs &#x3C;&#x3C; ", " &#x3C;&#x3C; rhs &#x3C;&#x3C; std::endl; std::cout &#x3C;&#x3C; "\tsnez " &#x3C;&#x3C; cur &#x3C;&#x3C; ", " &#x3C;&#x3C; cur &#x3C;&#x3C; std::endl; break; // ... default: throw std::runtime_error("visit: invalid binary operator"); } } </code></pre> <p>如果无法通过全部 Lv3 的测试样例, 可以检查如下几个问题:</p> <ul> <li>把数据从寄存器移动到寄存器时, 使用的是 <code>mv</code> 指令, 而不是 <code>li</code> 指令.</li> <li>访问 <code>return</code> 指令时, 在访问 <code>ret.value</code> 之前有没有检查它是否已经分配了寄存器, 否则可能造成同一个运算被输出多次.</li> <li>还有一个测试样例, 可以检查你的寄存器是否会溢出:</li> </ul> <pre><code class="language-cpp">int main() { return 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0 + 0 * 0; } </code></pre> <h3>Compile and Test</h3> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.koopa</code>:</p> <pre><code class="language-bash">./build/compiler -koopa debug/hello.c -o debug/hello.koopa </code></pre> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.S</code>:</p> <pre><code class="language-bash">./build/compiler -riscv debug/hello.c -o debug/hello.S </code></pre> <p>本地自动评测 <code>koopa</code>:</p> <pre><code class="language-bash">autotest -koopa -s lv3 /root/compiler </code></pre> <p>本地自动评测 <code>riscv</code>:</p> <pre><code class="language-bash">autotest -riscv -s lv3 /root/compiler </code></pre> <h2>Lv 4</h2> <p>本节需要让你的编译器可以处理变量的声明和定义, 用例如下:</p> <pre><code class="language-cpp">int main() { const int x = 233 * 4; int y = 10; y = y + x / 2; return y; } </code></pre> <p>整体来讲, 有如下几个重点:</p> <ol> <li><code>koopa</code> 部分需要增加符号表来管理变量.</li> <li><code>koopa</code> 部分需要完成 <code>const</code> 变量的编译期求值.</li> <li><code>riscv</code> 部分在处理不同条 <code>koopa</code> 指令间, 只需要维护栈帧.</li> <li><code>riscv</code> 部分在处理同一条 <code>koopa</code> 指令时, 需要维护寄存器.</li> </ol> <h3><code>Koopa</code> Symbol Table</h3> <p>如果是<strong>常量定义</strong>, 比如 <code>int x = 233;</code>, 它不需要 <code>koopa</code> 指令来完成.</p> <p>你只需要在符号表中记录 <code>@x</code> 这个变量和 <code>233</code> 这个立即数, 当其他命令调用变量 <code>x</code> 时, 比如 <code>y = x;</code>, 从符号表中找到 <code>@x</code> 这个变量对应的数值, 然后直接使用 <code>store 233, @y</code> 指令把 <code>@x</code> 这个变量的值加载到寄存器中给这个指令用.</p> <p>如果是<strong>变量定义</strong>, 比如 <code>int y = x + 1;</code>, 它需要若干 <code>koopa</code> 指令来完成 (假设 <code>x</code> 不是常量, 需要从内存中加载):</p> <pre><code class="language-asm">%0 = load @x add %0, 1 @y = alloc i32 store %0, @y </code></pre> <p>你需要在符号表中记录 <code>@y</code> 这个变量, 当其他命令调用变量 <code>y</code> 时, 检查符号表中是否有 <code>@y</code> 这个变量, 如果有, 则使用 <code>%0 = load @y</code> 指令把 <code>@y</code> 这个变量的值加载到寄存器中给这个指令用.</p> <p>综上所述:</p> <p>符号表的 <code>key</code> 就是 <code>@</code> 开头的内存名, <code>value</code> 是 <code>i32</code> 类型的立即数 (常量定义) 或什么都没有 (变量定义, 但是如果你想保持一致性也可以把 <code>%</code> 开头的寄存器名存下来, 在上面这个例子中是 <code>%0</code> ; 不过在多层嵌套的块中, 我们可以把这个变量处在的定义域的层级用 <code>value</code> 来传递, 具体可以参考 Lv5 的实现).</p> <p>符号和符号表</p> <pre><code class="language-cpp">/** * @brief 符号 * @date 2024-12-22 */ class Symbol { public: enum class Type { VAR, VAL }; Type type; int val; Symbol() : type(Type::VAL), val(0) {} Symbol(Type type, int val) : type(type), val(val) {} }; /** * @brief 符号表 * @date 2024-12-22 */ class SymbolTable { private: std::unordered_map&#x3C;std::string, Symbol> symbol_table; bool is_returned = false; public: void create(const std::string &#x26;name, Symbol symbol); bool exist(const std::string &#x26;name); }; </code></pre> <p>在常量的定义中维护符号表:</p> <pre><code class="language-cpp">Result ConstDefAST::print(std::stringstream &#x26;output_stream) const { if (symbol_table.exist(const_symbol)) // 如果符号表中已经存在这个符号, 则抛出错误 { throw std::runtime_error("ConstDefAST::print: const identifier already exists"); } Result value_result = const_init_val->print(output_stream); // 计算常量表达式的值 symbol_table.create(const_symbol, Symbol(Symbol::Type::VAL, value_result.val)); // 将常量表达式的值存入符号表 return Result(); // 返回空结果, 为什么不返回调用 print 的返回值? 因为我们的先验知识 (语义规范) 告诉我们, 声明和定义语句不会返回任何值 } </code></pre> <h3><code>Koopa</code> Const Variable Compile-time Computation</h3> <pre><code class="language-cpp">int main() { const int x = 1 + 1; return x; } </code></pre> <p>这样一个返回常量的代码, 我们直接返回 <code>2</code> 即可:</p> <pre><code class="language-asm">fun @main(): i32 { %entry: ret 2 } </code></pre> <p>可以看到 <code>1 + 1</code> 在编译期就被求值为 <code>2</code> 了, 那么如何完成 <code>const</code> 变量的编译期求值呢?</p> <p>我们只需要在访问每一个计算节点, 比如 <code>AddExpAST::print</code> 的时候判断它的左右操作数是不是都是立即数, 如果是立即数就返回计算完的立即数, 如果不是立即数才需要 <code>%1 = add %0, 1</code> 这样的计算指令.</p> <pre><code class="language-cpp">Result AddExpAST::print(std::stringstream &#x26;output_stream) const { if (!add_exp &#x26;&#x26; !op &#x26;&#x26; mul_exp) { return (*mul_exp)->print(output_stream); } else if (add_exp &#x26;&#x26; op &#x26;&#x26; mul_exp) { Result result_left = (*add_exp)->print(output_stream); Result result_right = (*mul_exp)->print(output_stream); if (result_left.type == Result::Type::IMM &#x26;&#x26; result_right.type == Result::Type::IMM) { if (*op == "+") { return Result(Result::Type::IMM, result_left.val + result_right.val); } else if (*op == "-") { return Result(Result::Type::IMM, result_left.val - result_right.val); } else { throw std::runtime_error("AddExpAST::print: invalid add operator when both operands are immediate"); } } else { Result result = Result(Result::Type::REG); if (*op == "+") { output_stream &#x3C;&#x3C; "\t" &#x3C;&#x3C; result &#x3C;&#x3C; " = add " &#x3C;&#x3C; result_left &#x3C;&#x3C; ", " &#x3C;&#x3C; result_right &#x3C;&#x3C; "\n"; } else if (*op == "-") { output_stream &#x3C;&#x3C; "\t" &#x3C;&#x3C; result &#x3C;&#x3C; " = sub " &#x3C;&#x3C; result_left &#x3C;&#x3C; ", " &#x3C;&#x3C; result_right &#x3C;&#x3C; "\n"; } else { throw std::runtime_error("AddExpAST::print: invalid add operator when one of the operands is not immediate"); } return result; } } else { throw std::runtime_error("AddExpAST::print: invalid add expression"); } } </code></pre> <p>可以看出, 如果 <code>AddExpAST::print</code> 的左右操作数都是立即数, 那么 <code>AddExpAST::print</code> 的返回值就是立即数, 否则就是寄存器.</p> <p>这样我们避免了已经知道左右操作数的真实数值的情况下依然生成 <code>add</code> 指令, 从而实现了编译期求值, 同时这是一个递归的过程, 所以仅需要修改很少的代码就可以实现.</p> <h3><code>RISC-V</code> Stack Frame</h3> <p>在处理不同条 <code>koopa</code> 指令间只需要维护栈帧而不需要维护寄存器, 具体来讲, 在使用到 <code>@x</code> 或 <code>%1</code> 等<strong>所有</strong> <code>koopa</code> 变量和内存时维护栈帧.</p> <p><code>@x</code> 存在栈帧上是没有问题的, 毕竟 <code>koopa</code> 就是这么做的.</p> <p>但是 <code>%1</code> 这样的 <code>koopa</code> 寄存器应该存在哪里呢? 我们为了简化寄存器分配, 因此将 <code>koopa</code> 的所有寄存器计算出来之后, 也存在 <code>riscv</code> 的栈帧上, 如果这个 <code>%1</code> 之后被使用了, 就从栈帧中找到 <code>%1</code> 对应的内存即可.</p> <p>可以看下面的例子, <code>%2 = load @y</code> 计算出来了 <code>%2</code> 的值, 我们的操作是把它存在了 <code>sp + 12</code> 这个位置, 然后 <code>ret %2</code> 的时候从 <code>sp + 12</code> 这个位置取出 <code>%2</code> 的值, 从而在不同 <code>koopa</code> 指令间通过栈帧传递信息, 完全不使用寄存器.</p> <pre><code class="language-asm"> .text .globl main main: addi sp, sp, -16 # store 10, @y li t0, 10 sw t0, 0(sp) # %0 = load @y lw t0, 0(sp) sw t0, 4(sp) # %1 = add %0, 466 lw t0, 4(sp) li t1, 466 add t0, t0, t1 sw t0, 8(sp) # store %1, @y lw t0, 8(sp) sw t0, 0(sp) # %2 = load @y lw t0, 0(sp) sw t0, 12(sp) # ret %2 lw a0, 12(sp) addi sp, sp, 16 ret </code></pre> <p>我使用了 <code>ContextManager</code> 来管理栈帧和寄存器, 这是从 <code>Lv3</code> 的 <code>RegisterManager</code> 加入了栈帧的管理器得到的.</p> <p>所有代码共用一个 <code>ContextManager</code>, 每一个函数在进入的时候单开一个 <code>StackManager</code>.</p> <p>具体来讲:</p> <pre><code class="language-cpp">/** * @brief 寄存器和所有函数的栈管理器, 是全局共用的, 可以维护值和寄存器的关系, 可以维护一个值和这个值对应的函数的栈信息 * @author Yutong Liang * @date 2024-11-28 */ class ContextManager { private: // 值到寄存器名称的映射 std::unordered_map&#x3C;koopa_raw_value_t, std::string> _value_to_reg_string; // 存储当前所有寄存器是否有不能被覆盖的值 std::unordered_map&#x3C;std::string, bool> _reg_is_used; /** * @brief 设置一个值对应哪个寄存器, 内部函数不被外部调用 * @param[in] value 值 * @param[in] reg_string 寄存器名称 * @author Yutong Liang * @date 2024-11-28 */ void _set_value_to_reg_string(const koopa_raw_value_t &#x26;value, const std::string &#x26;reg_string); // 函数名到这个函数的 StackManager 的映射 std::unordered_map&#x3C;std::string, StackManager> _function_name_to_stack_manager; // 当前正在处理的函数的函数名 std::string current_function_name; }; /** * @brief 单个函数的栈管理器, 是一个函数使用的, 可以维护值 (比如 `@x`, `%1`) 和栈地址的关系 * @author Yutong Liang * @date 2024-12-22 */ class StackManager { private: // 栈帧大小, 初始化的时候确定的, 单位是字节 int stack_size; // 栈帧当前使用情况, 初始化时0, 直到增长为 stack_size 为止, 单位是字节 int stack_used_byte; // 值到栈地址的映射, 栈地址的表示方法是 "sp + offset" 中的 int offset std::unordered_map&#x3C;koopa_raw_value_t, int> value_to_stack_offset; }; </code></pre> <h3><code>RISC-V</code> Register Allocation</h3> <p>不同 <code>koopa</code> 代码之间共享栈帧但是寄存器不互相影响, 同一行 <code>koopa</code> 代码之间才可能产生寄存器的影响, 每一条 <code>koopa</code> 指令使用自己的寄存器然后释放自己的寄存器.</p> <p>这是因为每一行 <code>koopa</code> 代码只会使用 <code>@x</code>, <code>%1</code>, <code>1</code> 这样的值, 而这些值在 RISC-V 中要么在内存中, 要么就是立即数, 所以<strong>任意两个 <code>koopa</code> 指令之间是不会产生寄存器复用的</strong>.</p> <p>有了这个原则, 我们在实现的时候就可以安心地使用寄存器了.</p> <p>在访问 <code>koopa_raw_value_t</code> 的时候, 只访问对应 <code>koopa</code> 指令的抽象语法树, 不对应的不访问, 比如立即数就不要访问, 因为这样安排逻辑清晰, 保证了寄存器使用的解耦, 两个 <code>visit</code> 函数之间没有寄存器依赖关系, 同时 <code>switch</code> 中每一个 <code>visit</code> 函数都会使用后释放自己的寄存器.</p> <pre><code class="language-cpp">// 访问指令 void visit(const koopa_raw_value_t &#x26;value) { const auto &#x26;kind = value->kind; switch (kind.tag) { case KOOPA_RVT_RETURN: // 访问 return 指令 visit(kind.data.ret); break; case KOOPA_RVT_BINARY: // 访问 binary 计算指令 visit(kind.data.binary, value); break; case KOOPA_RVT_ALLOC: // 访问 alloc 指令, 分配内存是实际存在的指令, 但是汇编语言的内存分配是直接用栈指针管理的, 所以不需要显式的内存分配, 可以忽略 koopa 的 alloc 指令 // 比如 @x = alloc i32 这样一个指令, 如果只有这个指令本身, 并不需要做任何操作也能保证 RISC-V 的正确性 // 只有在使用了 @x 的时候, 比如 store 10, @x 这样的指令, 才需要设定 @x 的栈地址, 所以 alloc 指令可以忽略 break; case KOOPA_RVT_LOAD: // 访问 load 指令 visit(kind.data.load, value); break; case KOOPA_RVT_STORE: // 访问 store 指令 visit(kind.data.store, value); break; default: // 其他类型暂时遇不到 throw std::runtime_error("visit: invalid instruction"); } } </code></pre> <p>比如 <code>%1 = add %0, 1</code> 这样的指令, 只访问 <code>add</code> 指令, 在访问 <code>add</code> 的时候不调用 <code>visit( 立即数 1 )</code> , 参考如下 7-17 行代码, 而是直接将 <code>1</code> 加载到寄存器中, 因为立即数不是 <code>koopa</code> 指令, 如果访问了就违反了我们最开始的原则了.</p> <pre><code class="language-cpp">// 访问 binary 指令 void visit(const koopa_raw_binary_t &#x26;binary, const koopa_raw_value_t &#x26;value) { // 判断 lhs 是立即数还是内存, 如果是立即数就 li, 否则就 lw context_manager.allocate_reg(binary.lhs); std::string lhs = context_manager.value_to_reg_string(binary.lhs); if (binary.lhs->kind.tag == KOOPA_RVT_INTEGER) // 这里不要调用 visit( 立即数 1 ), 因为这不是一个 koopa 指令 { riscv_printer.li(lhs, binary.lhs->kind.data.integer.value); } else { // 当前函数的 StackManager StackManager &#x26;stack_manager = context_manager.get_current_function_stack_manager(); // 从栈中加载数据到寄存器 riscv_printer.lw(lhs, "sp", stack_manager.get_value_stack_offset(binary.lhs), context_manager); } // 判断 rhs 是立即数还是内存, 如果是立即数就 li, 否则就 lw context_manager.allocate_reg(binary.rhs); std::string rhs = context_manager.value_to_reg_string(binary.rhs); if (binary.rhs->kind.tag == KOOPA_RVT_INTEGER) { riscv_printer.li(rhs, binary.rhs->kind.data.integer.value); } else { // 当前函数的 StackManager StackManager &#x26;stack_manager = context_manager.get_current_function_stack_manager(); // 从栈中加载数据到寄存器 riscv_printer.lw(rhs, "sp", stack_manager.get_value_stack_offset(binary.rhs), context_manager); } // 给结果分配一个寄存器, 分配之前可以先释放掉 lhs 和 rhs 对应的寄存器, 因为他们相当于已经加载进来了, 一会使用的时候可以覆盖, 比如 add t0, t0, t1 context_manager.set_reg_free(binary.lhs); context_manager.set_reg_free(binary.rhs); context_manager.allocate_reg(value); std::string cur = context_manager.value_to_reg_string(value); // 根据二元运算符的类型进行处理 switch (binary.op) { case KOOPA_RBO_EQ: riscv_printer.xor_(cur, lhs, rhs); riscv_printer.seqz(cur, cur); break; // ... default: throw std::runtime_error("visit: invalid binary operator"); } // 当前函数的 StackManager StackManager &#x26;stack_manager = context_manager.get_current_function_stack_manager(); // 把结果存回栈中 stack_manager.save_value_to_stack(value); riscv_printer.sw(cur, "sp", stack_manager.get_value_stack_offset(value), context_manager); // 当前结果所在的寄存器已经被使用过了, 释放 context_manager.set_reg_free(value); } </code></pre> <h3>Compile and Test</h3> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.koopa</code>:</p> <pre><code class="language-bash">./build/compiler -koopa debug/hello.c -o debug/hello.koopa </code></pre> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.S</code>:</p> <pre><code class="language-bash">./build/compiler -riscv debug/hello.c -o debug/hello.S </code></pre> <p>本地自动评测 <code>koopa</code>:</p> <pre><code class="language-bash">autotest -koopa -s lv4 /root/compiler </code></pre> <p>本地自动评测 <code>riscv</code>:</p> <pre><code class="language-bash">autotest -riscv -s lv4 /root/compiler </code></pre> <h2>Lv5</h2> <p>这是一个非常简单的 Level 呀, 只需要在 Lv4 的基础上将一个 <code>SymbolTable</code> 变为多个就可以了.</p> <h3>Multiple Symbol Table</h3> <p>Lv4 中的 <code>SymbolTable</code> :</p> <pre><code class="language-cpp">class SymbolTable { private: std::unordered_map&#x3C;std::string, Symbol> symbol_table; bool is_returned = false; public: // CRUD ... }; </code></pre> <p>Lv5 中的 <code>SymbolTable</code> :</p> <pre><code class="language-cpp">class SymbolTable { private: std::vector&#x3C;std::unordered_map&#x3C;std::string, Symbol>> symbol_table; // 每进入一个块, 就创建一个新的符号表, 块包括函数的大括号和语句块的大括号 bool is_returned = false; public: // 每进入一个块, 就创建一个新的符号表, 块包括函数的大括号和语句块的大括号 void new_symbol_table_hierarchy(); // 每离开一个块, 就删除一个符号表 void delete_symbol_table_hierarchy(); // CRUD ... }; </code></pre> <p>区别在于我们把 <code>SymbolTable</code> 从单个变为多个, 构建为一个栈, 每进入一个块, 就创建一个新的符号表, 每离开一个块, 就删除一个符号表.</p> <p>同时我们需要修改内存的存储位置, 因为不同层的定义域可能使用同一个变量名 (例子如下), 此时应该从内向外找到最近的变量名然后使用这一层的内存地址.</p> <pre><code class="language-asm">fun @main(): i32 { %entry: @a_1 = alloc i32 store 1, @a_1 store 2, @a_1 @a_2 = alloc i32 store 3, @a_2 %0 = load @a_1 ret %0 } </code></pre> <h3>Naming Same Symbol From Different Scope</h3> <p>那么具体应该如何命名呢? 我们恰巧可以使用这个变量处于的 <code>vector</code> 的 <code>index</code> 来命名, 比如第一个 <code>@a</code> 处于 <code>symbol_table[0]</code> 中, 那么我们就把访问第一层中的 <code>@a</code> 的内存地址表示为 <code>@a_1</code>, 第二个 <code>@a</code> 处于 <code>symbol_table[1]</code> 中, 那么我们就把访问第二层中的 <code>@a</code> 的内存地址表示为 <code>@a_2</code>.</p> <p>具体实现可以参考:</p> <pre><code class="language-cpp">class Symbol { public: enum class Type { VAR, VAL }; Type type; int val; // 如果 type 是 VAL, 那么 val 是立即数的数值; 如果 type 是 VAR, 那么 val 是变量的层级, 比如 `a = 2;` 如果在符号表中在层级 1 找到这个符号, 那么就会返回 1, 得到 @a_1 Symbol() : type(Type::VAL), val(0) {} Symbol(Type type, int val) : type(type), val(val) {} }; Symbol SymbolTable::read(const std::string &#x26;name) { for (int i = symbol_table.size() - 1; i >= 0; --i) { if (symbol_table[i].find(name) != symbol_table[i].end()) { Symbol symbol = symbol_table[i].at(name); if (symbol.type == Symbol::Type::VAL) { return symbol; // 如果是常量, 直接返回常量的值 } else if (symbol.type == Symbol::Type::VAR) { return Symbol(Symbol::Type::VAR, i + 1); // 如果是变量, 返回变量所在的 SymbolTable 的 index } else { throw std::runtime_error("SymbolTable::read: invalid symbol type"); } } } throw std::runtime_error("SymbolTable::read: identifier does not exist"); } </code></pre> <p>如果是 <code>Symbol::Type::VAR</code> , 我们可以正好使用 <code>Symbol::val</code> 来表示它处于的 <code>symbol_table</code> 的 <code>index</code> , 毕竟这个 <code>Symbol</code> 初始化的时候 <code>Symbol::val</code> 就是没用的, 可以参考如下的初始化代码和它的 Context:</p> <pre><code class="language-cpp">Result VarDefAST::print(std::stringstream &#x26;output_stream) const { if (var_init_val) { Result value_result = (*var_init_val)->print(output_stream); symbol_table.insert_symbol(var_symbol, Symbol(Symbol::Type::VAR, value_result.val)); std::string symbol_name = var_symbol; std::string suffix = std::to_string(symbol_table.read(symbol_name).val); std::string symbol_name_with_suffix = symbol_name + "_" + suffix; output_stream &#x3C;&#x3C; "\t@" &#x3C;&#x3C; symbol_name_with_suffix &#x3C;&#x3C; " = alloc i32\n"; output_stream &#x3C;&#x3C; "\tstore " &#x3C;&#x3C; value_result &#x3C;&#x3C; ", @" &#x3C;&#x3C; symbol_name_with_suffix &#x3C;&#x3C; "\n"; } else { symbol_table.insert_symbol(var_symbol, Symbol(Symbol::Type::VAR, 0)); std::string symbol_name = var_symbol; std::string suffix = std::to_string(symbol_table.read(symbol_name).val); std::string symbol_name_with_suffix = symbol_name + "_" + suffix; output_stream &#x3C;&#x3C; "\t@" &#x3C;&#x3C; symbol_name_with_suffix &#x3C;&#x3C; " = alloc i32\n"; } return Result(); } </code></pre> <p>其中第六行中用 <code>value_result.val</code> 初始化了这个 <code>Symbol</code> , 但是实际上这个值是 <code>koopa</code> 寄存器的名称, 我们并不需要保存这个某个内存和它用了某个寄存器来初始化的关系, 所以我们可以用 <code>symbol_table</code> 的 <code>index</code> 来覆盖这个值, 没有影响.</p> <p>最后 <code>RISC-V</code> 部分不需要修改, 因为 <code>koopa</code> 代码的可用指令没有修改.</p> <h3>Compile and Test</h3> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.koopa</code>:</p> <pre><code class="language-bash">./build/compiler -koopa debug/hello.c -o debug/hello.koopa </code></pre> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.S</code>:</p> <pre><code class="language-bash">./build/compiler -riscv debug/hello.c -o debug/hello.S </code></pre> <p>本地自动评测 <code>koopa</code>:</p> <pre><code class="language-bash">autotest -koopa -s lv5 /root/compiler </code></pre> <p>本地自动评测 <code>riscv</code>:</p> <pre><code class="language-bash">autotest -riscv -s lv5 /root/compiler </code></pre> <h2>Lv6</h2> <p>这部分我们需要完成 <code>if</code> 语句的编译, 示例如下:</p> <pre><code class="language-cpp">int main() { int a = 1; if (a == 2 || a == 3) { return 0; } else { return a + 1; } } </code></pre> <p>有如下几个重点:</p> <ol> <li>生成 <code>Koopa</code> 中间代码时解决分支语句在语法分析的时候产生的移入/归约冲突.</li> <li>生成 <code>Koopa</code> 中间代码时多 <code>if</code> 的编号问题.</li> <li>生成 <code>Koopa</code> 中间代码时解决控制流提前结束的问题.</li> <li>生成 <code>Koopa</code> 中间代码时解决同一层级多次分配相同名称的内存的问题.</li> <li>生成 <code>Koopa</code> 中间代码时逻辑运算短路求值的特性.</li> <li>生成 <code>RISC-V</code> 汇编代码时添加两条 <code>RISC-V</code> 指令.</li> <li>生成 <code>RISC-V</code> 汇编代码时容易出现的 bug 和解决方法, 主要是 12 位立即数溢出的问题.</li> </ol> <h3>Shift/Reduce Conflict</h3> <p><code>If</code> 相关的语法规则如下:</p> <pre><code class="language-bash">Stmt ::= "if" "(" Exp ")" Stmt ["else" Stmt] </code></pre> <p>对于移入/归约冲突的原因分析可以参考 <a href="https://pku-minic.github.io/online-doc/#/lv6-if/if-else">Lv6 的 Lab 文档</a>, 这里不再赘述.</p> <p>为了避免这样的问题, <code>SysY</code> 的语义规定了 <code>else</code> 必须和最近的 <code>if</code> 进行匹配, 助教在这里提示拆分可以解决问题, 那么具体怎么做呢?</p> <p>一个重要的观察是, 如果一个 <code>if ...</code> 语句在语法分析后跟随了一个 <code>else ...</code> 语句, 那么这个 <code>if ...</code> 语句内部中所有可能出现的 <code>if ...</code> 语句都必须是跟随 <code>else ...</code> 语句的, 否则就和 <code>SysY</code> 的语义规定冲突了.</p> <p>因此我们可以将原有的语法规则修改为:</p> <pre><code class="language-bash">Stmt ::= "if" "(" Exp ")" Stmt | "if" "(" Exp ")" StmtWithElse "else" Stmt StmtWithElse ::= "if" "(" Exp ")" StmtWithElse "else" StmtWithElse </code></pre> <p>这样就可以解决移入/归约冲突的问题了.</p> <p>在 Parser 中的参考实现:</p> <pre><code class="language-cpp">/* ast.hpp */ class StmtAST : public BaseAST { public: enum class StmtType { Assign, Expression, Block, Return, If }; StmtType stmt_type; std::optional&#x3C;std::unique_ptr&#x3C;BaseAST>> lval; // 语句中的左值 std::optional&#x3C;std::unique_ptr&#x3C;BaseAST>> exp; // 语句中的表达式 std::optional&#x3C;std::unique_ptr&#x3C;BaseAST>> block; // 语句中的基本块, 其实是另一个用大括号包裹的语句块 std::optional&#x3C;std::unique_ptr&#x3C;BaseAST>> inside_if_stmt; // if ... 中的语句块 std::optional&#x3C;std::unique_ptr&#x3C;BaseAST>> inside_else_stmt; // else ... 中的语句块 Result print(std::stringstream &#x26;output_stream) const override; }; /* sysy.y */ Stmt // Assign, Expression, Block, Return ... | IF '(' Exp ')' Stmt { // ... } | IF '(' Exp ')' StmtWithElse ELSE Stmt { // ... } ; StmtWithElse // Assign, Expression, Block, Return ... | IF '(' Exp ')' StmtWithElse ELSE StmtWithElse { // ... } ; </code></pre> <p>为什么我把 <code>StmtWithElse</code> 和 <code>Stmt</code> 的语法规则分开写, 重复写了一遍 <code>Stmt</code> 中的其它内容呢?</p> <p>因为对于 <code>Stmt</code> 来说, 无法在规约的时候传递一个参数说明这个 <code>Stmt</code> 是有 <code>else ...</code> 语句的, 还是没有 <code>else ...</code> 语句的, 所以需要新开一个语法规则. 同时我又不想大幅修改 <code>Stmt</code> 原始的语法规则, 想要保持前后的一致性, 所以只能复制一遍 <code>Stmt</code> 中的其它语法规则到 <code>StmtWithElse</code> 中了.</p> <h3>Multiple If Statement</h3> <p>不同的 <code>if</code> 语句都有自己的 <code>%then</code>, <code>%else</code> 和 <code>%end</code> 标签, 所以需要一个计数器来区分不同的 <code>if</code> 语句, 这个标签只要遇见一次 <code>if ...</code> 语句就加一, 这样就可以区分不同的 <code>if</code> 语句了.</p> <p>具体的输出代码可以参考:</p> <pre><code class="language-cpp">/* koopa.cpp */ koopa_context_manager.total_if_else_statement_count++; // 每遇见一次 if ... 语句, 就加一 std::string then_label = "%then_" + std::to_string(koopa_context_manager.total_if_else_statement_count); std::string else_label = "%else_" + std::to_string(koopa_context_manager.total_if_else_statement_count); std::string end_label = "%end_" + std::to_string(koopa_context_manager.total_if_else_statement_count); Result exp_result = (*exp)->print(output_stream); output_stream &#x3C;&#x3C; "\tbr " &#x3C;&#x3C; exp_result &#x3C;&#x3C; ", " &#x3C;&#x3C; then_label &#x3C;&#x3C; ", " &#x3C;&#x3C; (inside_else_stmt ? else_label : end_label) &#x3C;&#x3C; std::endl; </code></pre> <h3>Handle Control Flow Early End</h3> <p>先来看一个例子:</p> <pre><code class="language-cpp">int main() { if (0) { return 1; } else { return 2; } } </code></pre> <p>如果我们 naive 地实现 <code>if</code> 语句的 <code>koopa</code> 输出, 比如这样:</p> <pre><code class="language-cpp">/* koopa.cpp */ Result StmtAST::print(std::stringstream &#x26;output_stream) const { if (stmt_type == StmtType::Assign) { // ... } else if (stmt_type == StmtType::Return) { // ... } else if (stmt_type == StmtType::Expression) { // ... } else if (stmt_type == StmtType::Block) { // ... } else if (stmt_type == StmtType::If) { koopa_context_manager.total_if_else_statement_count++; std::string then_label = "%then_" + std::to_string(koopa_context_manager.total_if_else_statement_count); std::string else_label = "%else_" + std::to_string(koopa_context_manager.total_if_else_statement_count); std::string end_label = "%end_" + std::to_string(koopa_context_manager.total_if_else_statement_count); // 计算表达式, 根据表达式结果跳转到不同的分支 Result exp_result = (*exp)->print(output_stream); output_stream &#x3C;&#x3C; "\tbr " &#x3C;&#x3C; exp_result &#x3C;&#x3C; ", " &#x3C;&#x3C; then_label &#x3C;&#x3C; ", " &#x3C;&#x3C; (inside_else_stmt ? else_label : end_label) &#x3C;&#x3C; std::endl; // 进入 if 语句块 output_stream &#x3C;&#x3C; then_label &#x3C;&#x3C; ":" &#x3C;&#x3C; std::endl; Result result_if = (*inside_if_stmt)->print(output_stream); output_stream &#x3C;&#x3C; "\tjump " &#x3C;&#x3C; end_label &#x3C;&#x3C; std::endl; // else 语句块 Result result_else = Result(); if (inside_else_stmt) { output_stream &#x3C;&#x3C; else_label &#x3C;&#x3C; ":" &#x3C;&#x3C; std::endl; result_else = (*inside_else_stmt)->print(output_stream); output_stream &#x3C;&#x3C; "\tjump " &#x3C;&#x3C; end_label &#x3C;&#x3C; std::endl; } Result result = Result(); return result; } else { throw std::runtime_error("StmtAST::print: invalid statement"); } } </code></pre> <p>首先回忆基本块的定义:</p> <blockquote> <p>基本块 (basic block) 是编译领域的一个很常见的概念, 它指的是一系列指令的集合, 基本块满足:</p> <ul> <li>只有一个入口点: 所有基本块中的指令如果要执行跳转, 只能跳到某个基本块的开头, 而不能跳到中间.</li> <li>只有一个出口点: 基本块中, 只有最后一条指令能进行控制流的转移, 也就是跳到其他基本块, 或者从函数中返回 (执行 return 操作). 基本块的存在可以简化很多编译过程中需要进行的分析, 所以 Koopa IR 要求函数中的指令必须预先按照基本块分类. 同时, Koopa IR 约定, 函数的第一个基本块为函数的入口基本块, 也就是执行函数时, 首先会执行第一个基本块中的指令.</li> </ul> </blockquote> <p>那么我们可能会得到这样的 <code>koopa</code> 代码, 注意其中的 <code>%then_1</code> 和 <code>%else_1</code> 在返回后存在跳转到 <code>%end_1</code> 的指令, 这和基本块的定义 (只有最后一条指令能进行控制流的转移) 冲突了, 从而会造成编译器后端的错误.</p> <pre><code class="language-asm">fun @main(): i32 { %entry: br 0, %then_1, %else_1 %then_1: ret 1 jump %end_1 %else_1: ret 2 jump %end_1 %end_1: ret 0 } </code></pre> <p>所以我们需要在输出 <code>if</code> 内部的 <code>jump</code> 前判断改控制流是否提前被 <code>ret</code> 打断了, 如果被打断了就不输出 <code>jump</code> 了.</p> <p>一个非常直观的想法是在每一个 <code>print</code> 函数的输出 <code>Result</code> 中加入一个 <code>bool</code> 变量, 表示这个语句以及其嵌套的语句内是否被 <code>ret</code> 语句显式地返回了, 然后根据这个变量来决定是否输出 <code>jump</code> 指令, 同时还可以提前停止输出, 提高代码运行效率.</p> <pre><code class="language-cpp">/* koopa.cpp */ Result StmtAST::print(std::stringstream &#x26;output_stream) const { if (stmt_type == StmtType::Assign) { // ... } else if (stmt_type == StmtType::Return) { if (!lval &#x26;&#x26; exp &#x26;&#x26; !block) { Result result = (*exp)->print(output_stream); output_stream &#x3C;&#x3C; "\tret " &#x3C;&#x3C; result &#x3C;&#x3C; "\n"; result.control_flow_returned = true; // 如果语句返回了, 就设置该控制流返回 return result; } else if (!lval &#x26;&#x26; !exp &#x26;&#x26; !block) { output_stream &#x3C;&#x3C; "\tret\n"; Result result = Result(); result.control_flow_returned = true; // 如果语句返回了, 就设置该控制流返回 return result; } else { throw std::runtime_error("StmtAST::print: invalid return statement"); } } else if (stmt_type == StmtType::Expression) { // ... } else if (stmt_type == StmtType::Block) { if (!lval &#x26;&#x26; !exp &#x26;&#x26; block) { Result result = (*block)->print(output_stream); return result; } else { throw std::runtime_error("StmtAST::print: invalid block statement"); } } else if (stmt_type == StmtType::If) { koopa_context_manager.total_if_else_statement_count++; std::string then_label = "%then_" + std::to_string(koopa_context_manager.total_if_else_statement_count); std::string else_label = "%else_" + std::to_string(koopa_context_manager.total_if_else_statement_count); std::string end_label = "%end_" + std::to_string(koopa_context_manager.total_if_else_statement_count); Result exp_result = (*exp)->print(output_stream); if (!inside_if_stmt &#x26;&#x26; !inside_else_stmt) { throw std::runtime_error("StmtAST::print: invalid if statement, there's no if"); } output_stream &#x3C;&#x3C; "\tbr " &#x3C;&#x3C; exp_result &#x3C;&#x3C; ", " &#x3C;&#x3C; then_label &#x3C;&#x3C; ", " &#x3C;&#x3C; (inside_else_stmt ? else_label : end_label) &#x3C;&#x3C; std::endl; // if 语句块 output_stream &#x3C;&#x3C; then_label &#x3C;&#x3C; ":" &#x3C;&#x3C; std::endl; Result result_if = (*inside_if_stmt)->print(output_stream); // 如果 if 语句块显式的返回了, 就不要跳转了, 否则输出这样的 koopa 代码是错误的: // fun @main(): i32 { // %entry: // br 0, %then_1, %else_1 // %then_1: // ret 1 // jump %end_1 // %else_1: // ret 2 // jump %end_1 // %end_1: // } if (!result_if.control_flow_returned) { output_stream &#x3C;&#x3C; "\tjump " &#x3C;&#x3C; end_label &#x3C;&#x3C; std::endl; } // else 语句块 Result result_else = Result(); if (inside_else_stmt) { output_stream &#x3C;&#x3C; else_label &#x3C;&#x3C; ":" &#x3C;&#x3C; std::endl; result_else = (*inside_else_stmt)->print(output_stream); // 如果 else 语句块显式的返回了, 就不要跳转了 if (!result_else.control_flow_returned) { output_stream &#x3C;&#x3C; "\tjump " &#x3C;&#x3C; end_label &#x3C;&#x3C; std::endl; } } // 如果 if 语句块和 else 语句块都返回了, 则注明整个 if ... else ... 语句块返回了 // 但是为了避免这样的空 %end , 如果已经结束了就不输出 %end 了 // fun @main(): i32 { // %entry: // br 0, %then_1, %else_1 // %then_1: // ret 1 // %else_1: // ret 2 // %end_1: // } Result result = Result(); if (!result_if.control_flow_returned || !result_else.control_flow_returned) { output_stream &#x3C;&#x3C; end_label &#x3C;&#x3C; ":" &#x3C;&#x3C; std::endl; } else { result.control_flow_returned = true; // 如果是 if ... else ... 语句, 则 if ... 和 else ... 语句块都返回了才设置整体函数返回 } return result; } else { throw std::runtime_error("StmtAST::print: invalid statement"); } } </code></pre> <p>最后给 <code>FuncDefAST</code> 的 <code>print</code> 函数加上控制流返回的判断, 如果 <code>block</code> 没有显式的 <code>ret</code> 指令, 则补上一个 <code>ret 0</code>.</p> <pre><code class="language-cpp">/* koopa.cpp */ Result FuncDefAST::print(std::stringstream &#x26;output_stream) const { output_stream &#x3C;&#x3C; "fun @" &#x3C;&#x3C; ident &#x3C;&#x3C; "(): "; func_type->print(output_stream); output_stream &#x3C;&#x3C; " {" &#x3C;&#x3C; std::endl; output_stream &#x3C;&#x3C; "%entry:" &#x3C;&#x3C; std::endl; Result result = block->print(output_stream); // 如果 block 没有显式的 ret 指令, 则补上一个 ret 0 if (!result.control_flow_returned) { output_stream &#x3C;&#x3C; "\tret 0" &#x3C;&#x3C; std::endl; } output_stream &#x3C;&#x3C; "}" &#x3C;&#x3C; std::endl; return result; } </code></pre> <h3>Handle Same Variable Name in Same Level</h3> <p>一个例子:</p> <pre><code class="language-cpp">int main() { { int a = 2; } { int a = 3; } return 0; } </code></pre> <p>如果按照我们之前的处理方式, 会得出这样的 <code>koopa</code> 代码:</p> <pre><code class="language-asm">fun @main(): i32 { %entry: @a_2 = alloc i32 store 2, @a_2 @a_2 = alloc i32 sstore 3, @a_2 ret 0 } </code></pre> <p>这下就出问题了, 因为 <code>@a_2</code> 被分配了两次. 但是这件事情很好处理, 只要维护一个 <code>std::map&#x3C;std::pair&#x3C;std::string, int>, int></code> 来记录每个变量名在每个层级中是否已经分配了, 然后每次分配变量的时候, 先检查这个变量名是否已经存在, 如果存在就使用这个变量的地址, 否则就分配一个新的地址.</p> <pre><code class="language-cpp">/* koopa_util.hpp */ class KoopaContextManager { private: // ... // 用于判断当前符号是否在当前下标被分配, 比如 @a_1 在 symbol_tables[0] 中被分配, 那么 is_symbol_allocated_in_this_level[std::make_pair("a", 1)] == true std::map&#x3C;std::pair&#x3C;std::string, int>, bool> _is_symbol_allocated_in_this_level; public: // ... }; /* koopa.cpp */ Result VarDefAST::print(std::stringstream &#x26;output_stream) const { if (var_init_val) { Result value_result = (*var_init_val)->print(output_stream); koopa_context_manager.insert_symbol(var_symbol, Symbol(Symbol::Type::VAR, value_result.val)); std::string symbol_name = var_symbol; std::string suffix = std::to_string(koopa_context_manager.name_to_symbol(symbol_name).val); std::string symbol_name_with_suffix = symbol_name + "_" + suffix; // 如果这个变量名在当前层级中没有被分配过, 则分配一个新的地址 if (!koopa_context_manager.is_symbol_allocated_in_this_level(symbol_name)) { output_stream &#x3C;&#x3C; "\t@" &#x3C;&#x3C; symbol_name_with_suffix &#x3C;&#x3C; " = alloc i32\n"; } koopa_context_manager.set_symbol_allocated_in_this_level(symbol_name); output_stream &#x3C;&#x3C; "\tstore " &#x3C;&#x3C; value_result &#x3C;&#x3C; ", @" &#x3C;&#x3C; symbol_name_with_suffix &#x3C;&#x3C; "\n"; } else { koopa_context_manager.insert_symbol(var_symbol, Symbol(Symbol::Type::VAR, 0)); std::string symbol_name = var_symbol; std::string suffix = std::to_string(koopa_context_manager.name_to_symbol(symbol_name).val); std::string symbol_name_with_suffix = symbol_name + "_" + suffix; // 如果这个变量名在当前层级中没有被分配过, 则分配一个新的地址 if (!koopa_context_manager.is_symbol_allocated_in_this_level(symbol_name)) { output_stream &#x3C;&#x3C; "\t@" &#x3C;&#x3C; symbol_name_with_suffix &#x3C;&#x3C; " = alloc i32\n"; } koopa_context_manager.set_symbol_allocated_in_this_level(symbol_name); } return Result(); } </code></pre> <h3>Short-circuit Evaluation of Logical Expressions</h3> <p>编译器对逻辑运算, 比如 <code>||</code> 实际上是做了如下操作:</p> <pre><code class="language-cpp">int result = 1; if (lhs == 0) { result = rhs != 0; } </code></pre> <p>这样当 <code>lhs == 1</code> 时, 编译器会直接返回 <code>result</code>, 而不会计算 <code>rhs</code> 的值.</p> <p>在具体实现的时候你可以对 <code>lhs</code> 的返回值进行判断, 如果是立即数就不要使用跳转指令, 这样可能会造成常量表达式的求值失败.</p> <p>如果编译期无法确定是否可以短路求值, 我们需要使用内存来保存逻辑表达式的结果. 假设第一个操作数存在了 <code>%1</code> 这个寄存器中, 编译期我们不知道第二个操作数 <code>%2</code> 是否存在, 所以无法返回 <code>or</code> 表达式整体的答案存在哪里了, 所以需要结果存在内存中以保证可以修改.</p> <p>一个短路求值示例如下:</p> <pre><code class="language-cpp">int main() { int x = 1; int y = 0; return x || y; } </code></pre> <p>对应的 <code>koopa</code> 代码如下:</p> <pre><code class="language-asm">fun @main(): i32 { %entry: @x_1 = alloc i32 store 1, @x_1 @y_1 = alloc i32 store 0, @y_1 %0 = load @x_1 %1 = ne %0, 0 @or_result_in_memory_1 = alloc i32 store %1, @or_result_in_memory_1 br %1, %or_end_1, %or_second_operator_1 %or_second_operator_1: %2 = load @y_1 %3 = ne %2, 0 %4 = or %1, %3 store %4, @or_result_in_memory_1 jump %or_end_1 %or_end_1: %5 = load @or_result_in_memory_1 ret %5 } </code></pre> <p>其中我们可以看到最后返回的 <code>%5</code> 是 <code>@or_result_in_memory_1</code> 这个内存地址中的值, 这个内存地址中保存的值有可能来源于 <code>%1</code> 这个寄存器, 对应 <code>lhs</code> 的值, 也有可能来源于 <code>%4</code> 这个寄存器, 对应 <code>rhs</code> 的值. 为了避免不知道返回 <code>%1</code> 还是 <code>%4</code> 的情况, 我们使用内存来保存结果, 最后从内存中读取结果到 <code>%5</code> 中即可.</p> <p>一个可能的实现方式如下:</p> <pre><code class="language-cpp">/* koopa.cpp */ Result LOrExpAST::print(std::stringstream &#x26;output_stream) const { if (!left_or_exp &#x26;&#x26; !op &#x26;&#x26; left_and_exp) { return (*left_and_exp)->print(output_stream); } else if (left_or_exp &#x26;&#x26; op &#x26;&#x26; left_and_exp) { Result result_left = (*left_or_exp)->print(output_stream); if (result_left.type == Result::Type::IMM &#x26;&#x26; result_left.val != 0) // 立即数非 0 { return Result(Result::Type::IMM, 1); } else if (result_left.type == Result::Type::IMM &#x26;&#x26; result_left.val == 0) // 立即数 0 { Result result_right = (*left_and_exp)->print(output_stream); if (result_right.type == Result::Type::IMM) { return Result(Result::Type::IMM, 0 || result_right.val); } else { Result temp = Result(Result::Type::REG); output_stream &#x3C;&#x3C; "\t" &#x3C;&#x3C; temp &#x3C;&#x3C; " = ne " &#x3C;&#x3C; result_right &#x3C;&#x3C; ", 0\n"; return temp; } } else if (result_left.type == Result::Type::REG) // 如果是寄存器, 不能在编译期完成短路求值, 就需要跳转来完成短路求值, 如果判断寄存器是 0 直接跳转到 or_end_label { // 每进入一个需要用分支跳转语句达成短路求值的 || 语句, 就设置一个跳转标签 koopa_context_manager.total_or_statement_count++; // 设置跳转标签 std::string or_second_operator_label = "%or_second_operator_" + std::to_string(koopa_context_manager.total_or_statement_count); std::string or_end_label = "%or_end_" + std::to_string(koopa_context_manager.total_or_statement_count); // 假设第一个操作数存在了 %1 这个寄存器中, 编译期不知道第二个操作数 %2 是否存在, 所以无法返回 or 表达式整体的答案存在哪里了, 所以需要结果存在内存中以保证可以修改 std::string or_result_in_memory = "@or_result_in_memory_" + std::to_string(koopa_context_manager.total_or_statement_count); // 如果第一个操作数是 0, 则跳转到 or_second_operator_label 看看第二个操作数是否是 0, 否则跳转到 or_end_label Result temp_1 = Result(Result::Type::REG); output_stream &#x3C;&#x3C; "\t" &#x3C;&#x3C; temp_1 &#x3C;&#x3C; " = ne " &#x3C;&#x3C; result_left &#x3C;&#x3C; ", 0\n"; output_stream &#x3C;&#x3C; "\t" &#x3C;&#x3C; or_result_in_memory &#x3C;&#x3C; " = alloc i32\n"; output_stream &#x3C;&#x3C; "\tstore " &#x3C;&#x3C; temp_1 &#x3C;&#x3C; ", " &#x3C;&#x3C; or_result_in_memory &#x3C;&#x3C; "\n"; output_stream &#x3C;&#x3C; "\tbr " &#x3C;&#x3C; temp_1 &#x3C;&#x3C; ", " &#x3C;&#x3C; or_end_label &#x3C;&#x3C; ", " &#x3C;&#x3C; or_second_operator_label &#x3C;&#x3C; "\n"; // 输出没有短路求值的控制流 label output_stream &#x3C;&#x3C; or_second_operator_label &#x3C;&#x3C; ":" &#x3C;&#x3C; std::endl; // 计算第二个操作数 Result result_right = (*left_and_exp)->print(output_stream); Result temp_2 = Result(Result::Type::REG); Result temp_3 = Result(Result::Type::REG); output_stream &#x3C;&#x3C; "\t" &#x3C;&#x3C; temp_2 &#x3C;&#x3C; " = ne " &#x3C;&#x3C; result_right &#x3C;&#x3C; ", 0\n"; output_stream &#x3C;&#x3C; "\t" &#x3C;&#x3C; temp_3 &#x3C;&#x3C; " = or " &#x3C;&#x3C; temp_1 &#x3C;&#x3C; ", " &#x3C;&#x3C; temp_2 &#x3C;&#x3C; "\n"; output_stream &#x3C;&#x3C; "\tstore " &#x3C;&#x3C; temp_3 &#x3C;&#x3C; ", " &#x3C;&#x3C; or_result_in_memory &#x3C;&#x3C; "\n"; output_stream &#x3C;&#x3C; "\tjump " &#x3C;&#x3C; or_end_label &#x3C;&#x3C; "\n"; // 输出短路求值之后的控制流合并 label output_stream &#x3C;&#x3C; or_end_label &#x3C;&#x3C; ":" &#x3C;&#x3C; std::endl; // 把结果从内存中读取到寄存器中 Result result = Result(Result::Type::REG); output_stream &#x3C;&#x3C; "\t" &#x3C;&#x3C; result &#x3C;&#x3C; " = load " &#x3C;&#x3C; or_result_in_memory &#x3C;&#x3C; "\n"; return result; } else { throw std::runtime_error("LOrExpAST::print: invalid first operand of logical OR expression"); } } else { throw std::runtime_error("LOrExpAST::print: invalid logical OR expression"); } } </code></pre> <h3>Generate RISC-V Branch Code</h3> <p>在完成了 <code>koopa</code> 的生成后, 我们就可以开始生成 <code>RISC-V</code> 的汇编代码了.</p> <p>具体来讲只需要实现 <code>bnez</code> 和 <code>j</code> 这两个 <code>RISC-V</code> 指令的生成以满足 <code>br</code> 和 <code>jump</code> 这两个 <code>koopa</code> 指令的生成即可, 难度不大.</p> <pre><code class="language-cpp">/* riscv.cpp */ // 访问 branch 指令, 这个指令的输入是立即数或内存, 所以需要判断 branch.cond->kind.tag void visit(const koopa_raw_branch_t &#x26;branch, const koopa_raw_value_t &#x26;value) { // 当前函数的 StackManager StackManager &#x26;stack_manager = riscv_context_manager.get_current_function_stack_manager(); // 给中间结果分配一个寄存器 riscv_context_manager.allocate_reg(value); std::string temp_reg_name = riscv_context_manager.value_to_reg_string(value); // 使用立即数或从栈中加载数据到寄存器 if (branch.cond->kind.tag == KOOPA_RVT_INTEGER) { riscv_printer.li(temp_reg_name, branch.cond->kind.data.integer.value); } else { riscv_printer.lw(temp_reg_name, "sp", stack_manager.get_value_stack_offset(branch.cond), riscv_context_manager); } // 访问 branch 指令 riscv_printer.bnez(temp_reg_name, branch.true_bb->name + 1); riscv_printer.jump(branch.false_bb->name + 1); // 当前操作数所在的寄存器已经被使用过了, 释放 riscv_context_manager.set_reg_free(value); } // 访问 jump 指令 void visit(const koopa_raw_jump_t &#x26;jump) { // 访问 jump 指令 riscv_printer.jump(jump.target->name + 1); } </code></pre> <h3>Handle Immediate Number Overflow</h3> <p>但是在这里, <code>Lv6</code> 的 <code>RISC-V</code> 的所有测试点中有一个叫做 <code>logical1</code> 的测试点比较特殊, 它测试了 <code>lw</code>, <code>sw</code> 和 <code>addi</code> 这三个指令中立即数的范围.</p> <p>非常奇怪的是这个立即数溢出的问题在 <a href="https://pku-minic.github.io/online-doc/#/lv4-const-n-var/var-n-assign">Lv4.2. 变量和赋值</a> 中第一次提到, 但是到了 <code>Lv6</code> 的 <code>RISC-V</code> 生成部分才第一次被测试, 并且这个测试点的名字非常具有误导性, 让人以为是逻辑运算的测试点, 实际上错误出在 <code>RISC-V</code> 的立即数范围上...</p> <p>回忆 <code>RISC-V</code> 的指令格式, 立即数范围为十二位整数, 即 <code>-2048</code> 到 <code>2047</code>, 所以这三个指令一旦遇到立即数超过这个范围的指令就需要进行额外的处理, 以 <code>lw</code> 为例:</p> <pre><code class="language-cpp">void RISCVPrinter::lw(const std::string &#x26;rd, const std::string &#x26;base, const int &#x26;bias, RISCVContextManager &#x26;context_manager) { // 检查偏移量是否在 12 位立即数范围内 if (bias >= -2048 &#x26;&#x26; bias &#x3C; 2048) { std::cout &#x3C;&#x3C; "\tlw " &#x3C;&#x3C; rd &#x3C;&#x3C; ", " &#x3C;&#x3C; bias &#x3C;&#x3C; "(" &#x3C;&#x3C; base &#x3C;&#x3C; ")" &#x3C;&#x3C; std::endl; } else { std::string reg = context_manager.new_temp_reg(); li(reg, bias); add(reg, reg, base); std::cout &#x3C;&#x3C; "\tlw " &#x3C;&#x3C; rd &#x3C;&#x3C; ", " &#x3C;&#x3C; "(" &#x3C;&#x3C; reg &#x3C;&#x3C; ")" &#x3C;&#x3C; std::endl; } } </code></pre> <p>并且注意指令格式是 <code>lw rd, bias(base)</code>, 其中 <code>bias</code> 是<strong>立即数不是寄存器</strong>, 所以 <code>%0 = load @x</code> 指令 (其中 <code>@x</code> 在栈偏移量为 2048 的地方) 应该写成:</p> <pre><code class="language-asm">li t1, 2048 add t1, t1, sp lw t0, (t1) </code></pre> <p>而不是:</p> <pre><code class="language-asm">li t1, 2048 lw t0, t1(sp) </code></pre> <h3>Compile and Test</h3> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.koopa</code>:</p> <pre><code class="language-bash">./build/compiler -koopa debug/hello.c -o debug/hello.koopa </code></pre> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.S</code>:</p> <pre><code class="language-bash">./build/compiler -riscv debug/hello.c -o debug/hello.S </code></pre> <p>本地自动评测 <code>koopa</code>:</p> <pre><code class="language-bash">autotest -koopa -s lv6 /root/compiler </code></pre> <p>本地自动评测 <code>riscv</code>:</p> <pre><code class="language-bash">autotest -riscv -s lv6 /root/compiler </code></pre> <h2>Lv7</h2> <p>这个 Level 需要实现 <code>while</code> 和它配套的 <code>break</code> 和 <code>continue</code> 语句.</p> <p>这个 Level 的测试点中我有两个 WA 的测试点, 分别是 <code>12_break1</code> 和 <code>14_summary1</code> . 如果您有关于 <code>Lv7</code> 的任何 corner case 的测试点, 欢迎和我交流!</p> <p>Update 2025-01-06: 问题出在控制流分析出错. 我之前认为如果在 <code>while</code> 语句块中有 <code>return</code> 语句, 那么 <code>while</code> 语句也告诉上一层控制流返回了, 但是实际上这个 <code>while</code> 语句可能根本不会进去, 是否进入 <code>while</code> 语句块取决于运行时条件, 所以无论 <code>while</code> 语句块中是否存在 <code>return</code> 语句, 都应该告诉上一层控制流还没有返回.</p> <h3><code>While</code> Statement</h3> <p><code>while</code> 语句的语法如下:</p> <pre><code class="language-bash">Stmt ::= "while" "(" Exp ")" Stmt; </code></pre> <p>和 <code>if</code> 语句类似, 不再赘述.</p> <h3><code>Break</code> and <code>Continue</code> Statement</h3> <p><code>break</code> 和 <code>continue</code> 语句的语法如下:</p> <pre><code class="language-bash">Stmt ::= "break;"; | "continue;"; </code></pre> <p>主要的难点在于如何正确获取跳转的目标, 因为跳转的目标标签是在访问 <code>while</code> 语句时定义的, 当你访问 <code>break</code> 或 <code>continue</code> 语句时, 需要获取 <code>while</code> 语句的跳转目标标签.</p> <p>我们采用栈的方式获取跳转的目标标签, 当进入 <code>while</code> 语句时, 把当前的 <code>while</code> 语句的序号压入栈中, 当访问 <code>break</code> 或 <code>continue</code> 语句时, 从栈中读取当前的栈顶序号, 然后生成跳转指令.</p> <pre><code class="language-cpp">else if (stmt_type == StmtType::Break) { if (koopa_context_manager.while_statement_stack.empty()) { throw std::runtime_error("StmtAST::print: invalid break statement, not in a while statement"); } int current_while_statement_count = koopa_context_manager.while_statement_stack.top(); std::string while_end_label = "%while_end_" + std::to_string(current_while_statement_count); output_stream &#x3C;&#x3C; "\tjump " &#x3C;&#x3C; while_end_label &#x3C;&#x3C; "\n"; Result result = Result(); result.control_flow_while_interrupted = true; return result; } </code></pre> <h3>Compile and Test</h3> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.koopa</code>:</p> <pre><code class="language-bash">./build/compiler -koopa debug/hello.c -o debug/hello.koopa </code></pre> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.S</code>:</p> <pre><code class="language-bash">./build/compiler -riscv debug/hello.c -o debug/hello.S </code></pre> <p>本地自动评测 <code>koopa</code>:</p> <pre><code class="language-bash">autotest -koopa -s lv7 /root/compiler </code></pre> <p>本地自动评测 <code>riscv</code>:</p> <pre><code class="language-bash">autotest -riscv -s lv7 /root/compiler </code></pre> <h2>Lv8</h2> <p>这一章节需要实现一个能够处理函数 (包括 SysY 库函数) 和全局变量的编译器.</p> <p>示例函数如下:</p> <pre><code class="language-c"> int var; int func(int x) { var = var + x; return var; } int main() { // putint 和 putch 都是 SysY 库函数 // SysY 要求库函数不声明就可以使用 putint(func(1)); var = var * 10; putint(func(2)); putch(10); return var; } </code></pre> <h3>Some Simple Advice</h3> <ol> <li>中间代码生成部分只需要注意重新 <code>load</code> 函数参数, 这样可以为目标代码的生成省一些事, 具体来讲, 如果这样做了之后只有 <code>load</code> 指令可能收到 <code>KOOPA_RVT_GLOBAL_ALLOC</code> 这个代表函数参数的 <code>tag</code>, 其他函数不用修改.</li> <li>在进入一个新函数后, 要在顶部保存 <code>ra</code> 寄存器, 在退出函数后恢复 <code>ra</code> 寄存器, 所以栈大小要多加一, 多分配一条 store 指令来存储 ra 寄存器, ra 是调用者保存寄存器, 调用者把它的 ra 存在每个栈帧的最上面, 调用函数之前修改这个寄存器为 call 的下一条指令, 然后进入下一个函数, 代表调用者的下一条指令.</li> <li>在栈上存变量的时候, 要注意把栈顶的留给函数参数的位置空出来, 不要存储局部变量, 否则可能造成函数参数对局部变量的覆盖.</li> <li>在调用完函数后, 需要检测 <code>value->ty->tag == KOOPA_RTT_UNIT</code> 这个条件, 如果为真, 则函数没有返回值, 不需要生成 <code>return</code> 指令, 否则需要.</li> </ol> <h3>Compile and Test</h3> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.koopa</code>:</p> <pre><code class="language-bash">./build/compiler -koopa debug/hello.c -o debug/hello.koopa </code></pre> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.S</code>:</p> <pre><code class="language-bash">./build/compiler -riscv debug/hello.c -o debug/hello.S </code></pre> <p>本地自动评测 <code>koopa</code>:</p> <pre><code class="language-bash">autotest -koopa -s lv8 /root/compiler </code></pre> <p>本地自动评测 <code>riscv</code>:</p> <pre><code class="language-bash">autotest -riscv -s lv8 /root/compiler </code></pre> <h2>Lv9</h2> <p>终于知道为什么说编译原理比 ICS 的任务量多了...</p> <p>建议在没有绩点压力的大四选这门课就可以不用写 Lv9 了, 因为 Lv9 非常浪费时间并且占所有 Lab 的 27% 的分数, 也就是总评的 8 分, 如果在绩点压力下完成所有 Lab 会浪费很多时间.</p> <p>引流到 <a href="https://arthals.ink/tags/%E7%BC%96%E8%AF%91%E5%8E%9F%E7%90%86/">Arthals 的编译原理相关博客</a> , 里面有更多关于编译原理课程和 Lab 的笔记, 相信他会把 Lv9 的 Lab 讲的更清楚.</p> <h3>Compile and Test</h3> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.koopa</code>:</p> <pre><code class="language-bash">./build/compiler -koopa debug/hello.c -o debug/hello.koopa </code></pre> <p>运行编译器, 把 <code>debug/hello.c</code> 编译为 <code>debug/hello.S</code>:</p> <pre><code class="language-bash">./build/compiler -riscv debug/hello.c -o debug/hello.S </code></pre> <p>本地自动评测 <code>koopa</code>:</p> <pre><code class="language-bash">autotest -koopa -s lv9 /root/compiler </code></pre> <p>本地自动评测 <code>riscv</code>:</p> <pre><code class="language-bash">autotest -riscv -s lv9 /root/compiler </code></pre> <h2>Summary</h2> <p>这门课的 Lab 任务量很大, 但是思维难度实际上不大, 助教哥哥的文档写的还是比较清楚的, 只建议大四同学选这门课, 否则完成 Lab 的压力会很大.</p> <p>谢谢大家!</p> <p>Yutong Liang</p> <p>2025-01-12</p>https://www.lyt0112.com/blog/lalaland_competition-zhhttps://www.lyt0112.com/blog/lalaland_competition-zhWCA Competition @ Los Angeles, 一些新朋友, 个人 WCA 记录Sun, 01 Sep 2024 20:00:01 GMT<p>记录一下 La La Land 2024 的比赛经历</p> <p>上次比赛是五年前的天津赛, 这次正好在斯坦福做暑研, 也想去洛杉矶玩, 顺路比赛</p> <h2>出发</h2> <p>早上十点半就前往比赛场馆, 准备签到 (还得是希尔顿, 报名费 $70 也太贵了)</p> <p> 签到处 </p> <p>然后我们在休息区等待 WCA Delegate 讲解比赛事项和如何当裁判</p> <p> 准备开始比赛! </p> <p>甚至还有人在卖自己烤的有魔方图案的饼干, 坐在我旁边的大哥 <a href="https://www.worldcubeassociation.org/persons/2019HOIN01">Preston Hoing (2019HOIN01)</a> 买了两个送了我一个, 保存下来留作纪念</p> <p> 你是哪块儿小饼干 </p> <h2>比赛过程</h2> <p>这是一次 24 小时比赛, 也就是说 24 小时比赛不间断, 如果参加的比赛比较多 (比如我), 那就需要通宵, 事实上我也确实通宵了</p> <p>对这边的空调温度表示尊敬, 下次再也不穿短裤了...</p> <p>半夜冻的全身发抖, 每一把结束都需要去卫生间用热水洗手保持良好的状态</p> <p> 时间表 </p> <p>这次比赛总共参加了九个项目, 选两个有趣的项目讲讲</p> <h3>3x3</h3> <p>入魔 7 年, 前 3 年进步 5 秒, 后 4 年进步 5 秒...</p> <p>这次比赛刷新了单次和平均的个人记录, 单次还进了 10s, 平时练习的时候可能 20 把能有一把 sub10, 有点小激动</p> <p> SUB 10 </p> <p>下次比赛一定要做到平均 SUB 10 !</p> <h3>Pyraminx</h3> <p>不知道为什么我用的普通四棱往往会取得较高的名次, 这次在第二轮手感比较好, 刷新了单次和平均的个人纪录, 同时还进入了决赛</p> <p> Pyraminx Final </p> <p>可能是因为通宵太累了, 决赛发挥不好, 但是还是很开心能进决赛</p> <p> Pyraminx Grades </p> <h2>Interesting Things</h2> <h3>Clock WR</h3> <p>第一次见证世界纪录的诞生, <a href="https://www.worldcubeassociation.org/persons/2021DUNA01">Brendyn Dunagan (2021DUNA01)</a> 以 1.973s 刷新了 Clock 的单次世界纪录</p> <p> Clock WR </p> <p>还跟他合影留念了, 祝贺他 Nice Record!</p> <p> </p> <h3>国内外比赛区别</h3> <p>最开始我以为国外比赛和中国比赛流程是一样的, 但是实际上还是有比较多区别的</p> <p>中国比赛: Judge 负责拿走你的魔方, 在打乱区让打乱员打乱, 然后拿回到刚才的比赛台上, 每个人的五把结束之前是不会离开座位的</p> <p>国外比赛: 先提交魔方, 打乱完成后 Runner 把你的魔方放到一个有裁判的闲置比赛台上, 叫你的名字, 去这个比赛台完成复原, Judge 记录成绩, 结束之后你需要离开比赛台回到备赛区, Runner 把魔方送回打乱区, 等待下一次在另一个比赛台叫你的名字, 所以你需要在五个比赛台上完成五把</p> <p> 提交魔方 </p> <p>国外这样效率比较高, 因为不存在闲置的比赛台, 选手等待打乱的时候不会占用比赛台</p> <p>另外国内外裁判员和打乱员不同, 国外的裁判员都是选手, 每个人在一个比赛组的同时也会被分配到一个裁判组, 此时你需要找到一个空闲的裁判位置去当裁判</p> <p> 我在当裁判 </p> <p>当然裁判员的数量是过饱和的, 因为一个项目你只需要比 5 把, 但是需要裁判所有来到这个比赛桌的人, 大概 50 把, 所以也可以选择在轮到你的时候摆烂不去当裁判</p> <p>但是如果有很多人都摆烂, 不去当裁判, 就会造成缺少裁判的情况, WCA Delegate 就会在麦克风大叫, 找人来当裁判, 尤其是半夜的时候很多小朋友都去睡觉了, 甚至只有一个人来当裁判</p> <p> 裁判的码表⏱️ </p> <p>然而中国的裁判都是问卷报名制, 比赛之前从各种群发问卷招募裁判, 这样就能保证裁判是充足的, 但是坏处就是需要花精力去招募</p> <h2>People &#x26; Friends</h2> <p><a href="https://www.worldcubeassociation.org/persons/2019HOIN01">Preston Hoing (2019HOIN01)</a> 是我到了比赛场地第一个遇见的人, 他有点话唠, 跟我很热情地聊天, 还讲到了他上次魔表遇到的一个很好的打乱.</p> <p>他是这次比赛全项目的选手, 24小时的全项目对他来说真的累, 但是他还是坚持到了最后, 完成了他的第一次五盲, 还进了三盲决赛, 佩服. 不过忘了和他合影了, 有点遗憾.</p> <p>然后我坐到了一个小朋友和他爸爸旁边, 从巴西来的很可爱的小朋友: <a href="https://www.worldcubeassociation.org/persons/2024REIN02">Benjamin Dias Reino (2024REIN02)</a></p> <p> With Benjamin and His Dad </p> <p>然后来了另两个小朋友, 是 Benjamin 在上一场比赛认识的, 两兄弟中的弟弟参加比赛 <a href="https://www.worldcubeassociation.org/persons/2024SEMI01">Ren Davis Semien (2024SEMI01)</a></p> <p> </p> <p>后来这个桌子上又来了一个洛杉矶本地高中生 <a href="https://www.worldcubeassociation.org/persons/2022LEAV02">Kierran Leavitt (2022LEAV02)</a>, 他自述在学习开飞机, 包括滑翔机和有动力飞机, 还挺好玩</p> <p> </p> <p>在三阶第一轮最后一把遇见了一个中国裁判员, <a href="https://www.worldcubeassociation.org/persons/2023SHAO01">Tianshuo Shao (2023SHAO01)</a> 如果不是他我可能需要说一天英语了, 脑子要烧了</p> <p>后来在比赛间隙他开车带我在洛杉矶游览, 晚上还去了 Santa Monica 海滩和码头, 好多大麻味</p> <p> Santa Monica Beach </p> <p>忘了合照, 过两天补上</p> <p>Update on Oct 28, 2024: 才想起来补合影</p> <p> 和 Tianshuo 在 SacCubing XVIII 2024 @ Sacremento </p> <h2>Epilogue</h2> <p>随便放一些图片</p> <p> 比赛之前 </p> <p> 在阳台练习的人 </p> <p> 酒店大阳台的景色, 对面停车场花了我和 Tianshuo $30</p> <p> 开进死胡同 </p> <p> 又开进死胡同 </p> <p> 半夜大家在庆祝 12 点 </p> <p> 希尔顿酒店的泳池 </p> <p> With Benjamin </p> <p> Santa Monica 码头 </p> <p> 在 Santa Monica 码头上钓鱼的人</p>https://www.lyt0112.com/blog/lalaland_competition-enhttps://www.lyt0112.com/blog/lalaland_competition-enWCA Competition @ Los Angeles, met new friends and broke my personal WCA record.Sun, 01 Sep 2024 20:00:00 GMT<p>The competition experience of La La Land 2024</p> <p>The last competition was the Tianjin competition five years ago.</p> <h2>Set out</h2> <p>Heading to the competition venue at 10:30 in the morning to sign in (So Hilton, the registration fee of $70 is too expensive).</p> <p> Sign-in desk </p> <p>Then we waited in the rest area for the WCA Delegate to explain the competition matters and how to be a judge.</p> <p> Get ready to start the competition! </p> <p>Some people were even selling cookies they baked with Rubik's Cube patterns. The guy sitting next to me, <a href="https://www.worldcubeassociation.org/persons/2019HOIN01">Preston Hoing (2019HOIN01)</a>, bought two and gave me one as a souvenir.</p> <p> Little Biscuit </p> <h2>Comp process</h2> <p>This is a 24-hour race, which means the race is continuous for 24 hours. If you participate in many events (like me), you will need to stay up all night. In fact, I did stay up all night.</p> <p>Respect the air conditioning temperature here, I will never wear shorts in a 24h comp again...</p> <p>Shivering all over in the mid-night, I need to go to the bathroom to wash my hands with hot water to maintain a good condition.</p> <p> Timetable </p> <p>A total of nine events participated in this competition, choose two interesting events to talk about.</p> <h3>3x3</h3> <p>Cubing for 7 years, improved by 5 seconds in the first 3 years, improved by 5 seconds in the last 4 years...</p> <p>This competition broke the single and average personal records, with a single time Sub10. During regular practice, there might be one sub-10 out of 20 attempts, so I'm a bit excited.</p> <p> SUB 10 </p> <p>Next time, make a resolution to average SUB 10!</p> <h3>Pyraminx</h3> <p>I don't know why I often achieve higher rankings with the regular 4-sided, this time I felt good in the second round, broke my personal records for single and average, and also made it to the finals.</p> <p> Pyraminx Final </p> <p>It might be because I was too tired from staying up all night, I didn't perform well in the finals, but I'm still very happy to have made it to the finals.</p> <p> Pyraminx Grades </p> <h2>Interesting Things</h2> <h3>Clock WR</h3> <p>Witnessing the birth of a world record for the first time, <a href="https://www.worldcubeassociation.org/persons/2021DUNA01">Brendyn Dunagan (2021DUNA01)</a> set a new single world record for Clock with a time of 1.973 seconds.</p> <p> Clock WR: 1.973s </p> <p>Took a photo with him, congratulated him Nice Record!</p> <p> </p> <h3>Differences between China and US competitions</h3> <p>At first, I thought that the process of foreign competitions was the same as that of Chinese competitions, but actually, there are quite a few differences.</p> <p>In Chinese competitions, the Judge is responsible for taking your cube, having it scrambled by the scrambler in the scrambling area, and then bringing it back to the competition table. Each person will not leave their seat until all five attempts are finished.</p> <p>In US competitions, you first submit your cube. After scrambling is completed, a Runner will place your cube on an idle competition table and call your name. You go to this competition table to complete the solve. The Judge records your result. After finishing one solve, you need to leave the competition table and return to the waiting area. The Runner will take your cube back to the scrambling area to wait for the next time your name is called at another competition table. So, you need to complete five solves on five different competition tables.</p> <p> Submit Rubik's Cube </p> <p>It seems that the efficiency is higher abroad because there are no idle competition tables, and the tables are not occupied during shuffling.</p> <p>In addition, judges and scramblers are different. US judges are all players. When each person is assigned to a competition group, they are also assigned to another judge group. During the competition of this group, you need to find a free judge position to act as a judge.</p> <p> I'm a Judge </p> <p>Of course, the number of judges is oversaturated, because for one event you only need to judge 5 matches, but you need to judge all the people who come to this competition table, which may require judging about 50 matches, so you can also choose to slack off and not go when it's your turn to judge.</p> <p>However, many people are unwilling to be a judge, which often results in a lack of referees. The WCA Delegate has to shout into the microphone to find people to be judges, especially late at night when many kids have gone to bed, and sometimes there's only one person acting as a judge.</p> <p> The judge's stopwatch ⏱️ </p> <p>However, judges in China are recruited through a questionnaire registration system. Before the competition, referees are recruited by sending out questionnaires in various groups. This ensures that there are enough referees, but the downside is that it requires effort to recruit them.</p> <h2>People &#x26; Friends</h2> <p><a href="https://www.worldcubeassociation.org/persons/2019HOIN01">Preston Hoing (2019HOIN01)</a> was the first person I met at the competition venue. He is a bit of a chatterbox and chatted with me very enthusiastically, even mentioning a good scramble he encountered last time with the magic clock.</p> <p>He is a participant in all events of this competition. The 24-hour all-event challenge was really exhausting for him, but he still persevered until the end, completed his first five-blind, and even made it to the three-blind finals. Impressive. However, I forgot to take a photo with him, which is a bit regrettable.</p> <p>Then I sat next to a little boy and his father, a very cute little boy from Brazil: <a href="https://www.worldcubeassociation.org/persons/2024REIN02">Benjamin Dias Reino (2024REIN02)</a></p> <p> With Benjamin and His Dad </p> <p>Then two other kids came, whom Benjamin met in the last competition. The younger brother of the two brothers participated in the competition <a href="https://www.worldcubeassociation.org/persons/2024SEMI01">Ren Davis Semien (2024SEMI01)</a></p> <p> </p> <p>Later, a local high school student from Los Angeles <a href="https://www.worldcubeassociation.org/persons/2022LEAV02">Kierran Leavitt (2022LEAV02)</a> joined the table. He mentioned that he is learning to fly planes, including gliders and powered aircraft, which is quite fun.</p> <p> </p> <p>In the last match of the first round of the third stage, I met a Chinese judge, <a href="https://www.worldcubeassociation.org/persons/2023SHAO01">Tianshuo Shao (2023SHAO01)</a>. If it weren't for him, I might have had to speak English all day, my brain would have burned out.</p> <p>Later, during the break in the game, he drove me around Los Angeles. In the evening, we went to Santa Monica Beach and Pier, and there was a strong smell of marijuana.</p> <p> Santa Monica Beach </p> <p>Forgot to take a group photo, will make up for it in a couple of days.</p> <p>Update on Oct 28, 2024: Just remembered to put the photo here</p> <p> With Tianshuo at SacCubing XVIII 2024 @ Sacremento </p> <h2>Epilogue</h2> <p>Put some pictures</p> <p> Before the match </p> <p> The person practicing on the balcony </p> <p> The view from the hotel's large balcony, the parking lot across the street cost Tianshuo and me $30 </p> <p> Drive into a dead end </p> <p> Drove into a dead end again </p> <p> Everyone was celebrating at midnight </p> <p> The pool at the Hilton Hotel </p> <p> With Benjamin </p> <p> Santa Monica Pier </p> <p> People fishing on the Santa Monica Pier </p>https://www.lyt0112.com/blog/dw3-zhhttps://www.lyt0112.com/blog/dw3-zhWe are all different people all through our lives and that's okay, you've got to keep moving so long as you remember all the people that you used to be.Fri, 23 Aug 2024 20:00:01 GMT<h2>Start of the Journey</h2> <p>依然清晰的记得 2014 年夏天的那天晚上, <a href="https://tieba.baidu.com/p/3250946750">贴吧的置顶帖</a>里我看到了从来没见过的一集 Doctor Who, 一个从未见过的眉毛特别浓密的老头和 Clara 从 TARDIS 里出来, 我还以为是 Jenna Coleman 出演的另一部电视剧 (当时还没看到博士之日里面的眉毛或者博士之时里面的重生), 后来发现那是刚刚首播的 S08E01.</p> <p>最初了解到 Doctor Who 是因为这是老师上课放的众多科幻剧集中的一个 (BTW 我现在和他依然有联系, 他说现在上课放神秘小镇了, DW 有的时候比较恐怖), 后来在他的帮助下我找到了贴吧上面的资源追剧, 那一天我注册了贴吧账号, 第八季也恰巧在那一天开播, 如果点进我的<a href="https://tieba.baidu.com/home/main?id=tb.1.f7667468.skxWSalCb6g2De4ISKeFxw&#x26;fr=userbar">贴吧主页</a>会发现我恰好是十年吧龄.</p> <h2>Back to the Beginning</h2> <p>S08E01 首播十年的晚上重温了这一集, 每一句台词都是那么的熟悉, 好像一位老朋友再次和我娓娓道来我们刚认识时候他讲过的故事, 我知道他的会说的每一句话, 每一个梗和脸上的每一个表情, 甚至有的时候会突然有一种既视感, 让我感觉好像想起来了十年之前的情感. 比如 Clara 在餐厅地下被博士 '抛弃' 的时候, 一种陌生和绝望的感觉突然涌上心头, 似乎和曾经的我共享了同一个感情... 虽然是一样的剧集, 但是切身体会到 <code>所以兴怀，其致一也</code> 的感觉是真的非常奇妙.</p> <p>P.S. 这一集中 Vastra 夫人说的 "Well then, here we go again." 是 Brigadier 曾经在第三任博士重生为第四任博士的时候说过的话, 拥有这样长时间尺度的回忆和致敬也是我喜欢 DW 的一个非常重要的原因, 因为我同样是一个不喜欢结束的人, 就好像撕掉书的最后一页.</p> <p>这一集真的很好地刻画了博士重生之后的迷茫和脆弱, 他是一个充满活力的人, 但也感到害怕和孤独. 12 在翻译恐龙的咆哮声的时候或许真的是在表达自己的恐惧, 在这样的借物喻人之下, 博士对恐龙的安全保证是那么的脆弱, 让他那么的愧疚, 这和小 10 在庞贝火山爆发的时候有一些相似性, 但是不同却在于 12 最终没有救下恐龙但是 10 却救下了庞贝商人.</p> <p> You will be home again! </p> <p>Clara 对刚刚重生的 12 比较疏离却又非常担心他, 她还没有准备好接受博士突然变成了一个看起来完全陌生的形象, 以至于用一种非常有攻击性的语气和 Vastra 夫人对线, 但是最终还是在小 11 的最后电话之后慢慢接受了 12, 但是 12 对自己身份的追寻依然刚刚开始.</p> <p> How dare you! </p> <h2>How does it feel?</h2> <p>最开始我非常向往 Doctor 的旅行, 作为 Doctor 或者 Companion 是宇宙中最酷的工作了, 我想几乎每一个 Whovian 都曾经幻想过和 Doctor 一起旅行会是什么样的, 也正是这样的好奇心驱使着我们对 DW 的热爱.</p> <p>后来渐渐长大, 我逐渐理解了剧集中人物的感情和 Doctor 的价值观, 那样的好奇心和责任, <code>Never cruel, never cowardly; never give up, never give in</code>, 我一直非常喜欢这句话, 希望每一个人都能够坚持自己的信念.</p> <p>当然, 作为一个设定上寿命极长的角色, 唯一的 Time Lord, 拥有这样强大的能力和智慧, 如何约束自己的行为, 我想这个命题在 Clara 离去的三集中做出了充分的探讨.</p> <p><code>Face the Raven</code>, <code>Heaven Sent</code> 和 <code>Hell Bent</code> 这三集作为季末的整体, 讲述当 Doctor 失去了至亲之人后会做出怎样的选择, 甚至会为了复仇而放弃自己的原则, 选择修改时间, 但是最后依然不能阻止事情的发生, 或许对于每一个人也是一样的, 当一个人面对极端的情况, 往往会下意识地否认, 试图扭转状况, 只不过这里的 Doctor 可以操纵时间, 但是依然无法让 Clara 逃避自己的命运.</p> <p> 听说这个画的背面也有写字 "I'm in 12", 但是 Doctor 不忍心把它转过来... </p> <p>如果说学校的教育是知识的传授, 那么我相信 DW 一定在我的价值观中占有一席之地, 好奇心和冒险精神, 如何面对困难, 以及对于人性的探讨, 在这些普世价值和命题上的探讨导致 Doctor Who 对我的影响真的很大, 也让我想去亲自 <code>see the world</code>, 并且很多时候问一下自己: <code>What would The Doctor do?</code> 或许就能得到一个很好的答案.</p> <h2>Words</h2> <p>DW 里面真的有很多我很喜欢的台词, 有一些非常有名, 这里列举一些我比较喜欢的:</p> <ul> <li>One day, I shall come back. Yes, I shall come back. Until then, there must be no regrets, no tears, no anxieties. Just go forward in all your beliefs, and prove to me that I am not mistaken in mine.</li> <li>I burned up a sun just to say goodbye.</li> <li>Never cruel, never cowardly; never give up, never give in.</li> <li>Goodness is not goodness that seeks advantage. Good is good in the final hour, in the deepest pit without hope, without witness, without reward. Virtue is only virtue in extremis.</li> <li>It all just disappears doesn't it? Everything you are, gone in a moment like breath on a mirror. Any moment now, he’s a coming, (Clara: Who's coming?) The Doctor. (Clara: But you are, you are the doctor.) And I always will be. But times change and so must I. We all change, when you think about it. We are all different people all through our lives and that's okay, that's good, you've got to keep moving so long as you remember all the people that you used to be. I will not forget one line of this, not one day, I swear. I will always remember when The Doctor was me.</li> </ul> <p>推荐几个粉丝混剪:</p> <ul> <li><a href="https://www.bilibili.com/video/BV1Tx411P746">B站 - Are You The One</a> <ul> <li>这首歌绝了, 完美契合 Doctor 的形象, 我通过这个混剪爱上了这首歌, 剪辑也非常到位.</li> </ul> </li> <li><a href="https://youtu.be/7li5eZ3JZbA?si=TDZun38jWCOf7z9Q">YouTube - The First Question - 50th Anniversary Trailer</a> <ul> <li>50 周年的混剪, 12 年之前的视频了, 但是到现在也不过时, 尤其是台词的选取和配合, 以及音乐的选择都非常到位.</li> </ul> </li> <li><a href="https://youtu.be/-CdJUYWkrR0?si=bmuiay9TYl3zI1zF">YouTube - The First Question - 60th Anniversary Edition</a> <ul> <li>60 周年的混剪, 上一个视频的十年后重制版, 也是非常的精彩.</li> <li>这个视频 B 站还没有搬运, 因此我联系上作者取得了转载授权.</li> <li>B 站搬运: <a href="https://www.bilibili.com/video/BV1unW1e8EwR/?share_source=copy_web&#x26;vd_source=715b7965ee40cd347a349e6161f34dfc">B站 - The First Question - 60th Anniversary Edition</a></li> </ul> </li> </ul> <h2>Epilogue</h2> <p>用这篇文章简单聊了聊和 DW 的故事, 但是有更多的 delicate 的情感很难用文字表达出来, 很多剧集真的是百看不厌, 最喜欢的一集还是 <code>Heaven Sent</code>.</p> <p>但是我真的很希望下一季的 DW 能够在剧情上多下下功夫, S14/新新版S1 的最后一集有点难绷... 相关吐槽欢迎前往 <a href="https://www.lyt0112.com/blog/dw2">[DW] 幽默RTD, 幽默S14E08</a> 观看.</p> <p>每个博士重生都不只是博士追寻新身份的过程，也是观众接受新博士的过程, 12 的首集通过女伴的感情变化来慢慢表达了这个过程. 其实观众接纳新博士本身也是接纳新自己的过程, 在现实中同样代表了我们愿不愿意勇敢地开始一个新的人生阶段, 愿不愿意在这个过程中舍弃原先拥有东西, 即便这个东西是好的, 我们珍爱的.</p> <p>就像这句话一样: <code>So long as you remember all the people that you used to be</code> 在人生前进的路上只要我们记得曾经的那些美好, 就没有浪费那些时光. 十年之前的我又怎能想象到现在的我是什么样的呢, 但是只要记住这十年来 DW 带来的感动 (或者 CC 的垃圾剧情) 就足够了.</p> <p> The Doctors </p> <p>我和 DW 的下个十年会怎么样呢? Nobody knows, 但是我会一直期待下一集 Doctor Who 的!</p> <p>如果你也是 Whovian, 欢迎在评论区分享你和 DW 的故事或者你最喜欢的台词 / 剧集.</p> <p>After all, that's how the all started!</p> <h2>Credits</h2> <ul> <li><a href="https://www.facebook.com/DoctorWho/posts/pfbid04btj2pTSrWnJXfoMMJQ8rWiHKuz9H9P21QN7Hamwei3sNv6HkL7V8tiS3v8UetFXl">Doctor Who Facebook - Flashpoint, final episode of the Dalek Invasion of Earth</a></li> <li><a href="https://youtu.be/YWfpn6k79pQ?si=eBJH5Zyb2dzMLj_F">Doctor Who Clips - The Five Doctors</a></li> <li><a href="https://en.wikipedia.org/wiki/Doctor_Who_series_8">Wiki - DW S8</a></li> <li><a href="https://en.wikipedia.org/wiki/Doctor_Who_series_9">Wiki - DW S9</a></li> <li><a href="https://youtu.be/7L9cUG3BxN0?si=3b19mIGhbglNDfWz">YouTube - The Subtle Brilliance Of Doctor Who's Most Divisive Finale</a></li> <li><a href="https://youtu.be/7li5eZ3JZbA?si=TDZun38jWCOf7z9Q">YouTube - Doctor Who: The First Question - 50th Anniversary Trailer</a></li> <li><a href="https://youtu.be/-CdJUYWkrR0?si=bmuiay9TYl3zI1zF">YouTube - Doctor Who: The First Question - 60th Anniversary Edition</a></li> <li><a href="https://www.bilibili.com/video/BV1Tx411P746">Bilibili - Are You The One</a></li> </ul>https://www.lyt0112.com/blog/dw3-enhttps://www.lyt0112.com/blog/dw3-enWe are all different people all through our lives and that's okay, you've got to keep moving so long as you remember all the people that you used to be.Fri, 23 Aug 2024 20:00:00 GMT<h2>Start of the Journey</h2> <p>I still clearly remember that night in the summer of 2014, in the <a href="https://tieba.baidu.com/p/3250946750">pinned post</a>, I saw an episode of Doctor Who that I had never seen before. An old man with particularly thick eyebrows and Clara came out of the TARDIS. I thought it was another TV series starring Jenna Coleman (at that time, I hadn't seen the eyebrows in "The Day of the Doctor" or the regeneration in "The Time of the Doctor"). Later, I realized it was the just-premiered S08E01.</p> <p>The first time I learned about Doctor Who was because it was one of the many sci-fi series that the teacher played in class. Later, with his help, I found resources to follow the series.</p> <h2>Back to the Beginning</h2> <p>Rewatched this S08E01 episode on the night of its ten-year premiere, every line of dialogue is so familiar, like an old friend recounting the stories he told me when we first met. I know every word he will say, every joke, and every expression on his face.</p> <p>Sometimes, I even get a sense of déjà vu, making me feel like I remember the emotions from ten years ago. For example, when Clara was 'abandoned' by the Doctor in the restaurant basement, a feeling of unfamiliarity and despair suddenly surged in my heart, as if I shared the same emotion with my past self... Although it's the same episode, the personal experience of "so the feelings are the same" is truly very wonderful.</p> <p>P.S. In this episode, what Mrs. Vastra said, "Well then, here we go again," was something Brigadier once said when the Third Doctor regenerated into the Fourth Doctor. Having such long-term memories and tributes is one of the very important reasons why I like DW, because I am also someone who doesn't like endings, just like tearing out the last page of a book.</p> <p>This episode really well portrays the Doctor's confusion and vulnerability after his regeneration. He is a person full of energy, but also feels fear and loneliness. When translating the dinosaur's roar, he might really be expressing his own fear. Under such a metaphor, the Doctor's assurance of the dinosaur's safety is so fragile, making him feel so guilty. This is somewhat similar to the situation with the Tenth Doctor during the eruption of Mount Vesuvius, but the difference is that the Twelfth Doctor ultimately did not save the dinosaur, whereas the Tenth Doctor saved the Pompeii merchant.</p> <p> You will be home again! </p> <p>Clara is somewhat distant from the newly regenerated 12 but is very worried about him. She is not yet ready to accept that the Doctor has suddenly turned into a completely unfamiliar appearance, to the point of using a very aggressive tone with Madam Vastra. However, she eventually starts to accept 12 after the final call from 11, but 12's quest for his own identity has just begun.</p> <p> How dare you! </p> <h2>How does it feel?</h2> <p>At first, I was very eager for the Doctor's travels. Being a Doctor or a Companion is the coolest job in the universe. I think almost every Whovian has fantasized about what it would be like to travel with the Doctor, and it is this curiosity that drives our love for DW.</p> <p>As I grew up, I gradually understood the emotions of the characters in the series and the values of the Doctor, such curiosity and responsibility, "Never cruel, never cowardly; never give up, never give in." I have always liked this phrase very much and hope that everyone can stick to their beliefs.</p> <p>Of course, as a character with an extremely long lifespan, the only Time Lord, possessing such powerful abilities and wisdom, how to restrain one's behavior, I think this proposition was fully explored in the three episodes where Clara left.</p> <p><code>Face the Raven</code>, <code>Heaven Sent</code>, and <code>Hell Bent</code> as a whole for the season finale, tell the story of what choices the Doctor will make after losing a loved one, even to the point of abandoning his principles for revenge and choosing to alter time. However, in the end, he still cannot prevent things from happening. Perhaps it is the same for everyone; when faced with extreme situations, people often subconsciously deny and try to reverse the situation. But here, even though the Doctor can manipulate time, he still cannot let Clara escape her fate.</p> <p> I heard that there is also writing on the back of this painting saying "I'm in 12", but the Doctor couldn't bear to turn it over... </p> <p>If the education at school is the transmission of knowledge, then I believe DW definitely holds a place in my values. Curiosity and adventurous spirit, how to face difficulties, and the exploration of human nature. The discussion on these values and propositions has led Doctor Who to have a significant impact on me, making me want to personally <code>see the world</code>, and often ask myself: <code>What would The Doctor do?</code> Perhaps I can get a very good answer.</p> <h2>Words</h2> <p>There are really many lines in DW that I like, some of which are very famous. Here are some that I particularly like:</p> <ul> <li>One day, I shall come back. Yes, I shall come back. Until then, there must be no regrets, no tears, no anxieties. Just go forward in all your beliefs, and prove to me that I am not mistaken in mine.</li> <li>I burned up a sun just to say goodbye.</li> <li>Never cruel, never cowardly; never give up, never give in.</li> <li>Goodness is not goodness that seeks advantage. Good is good in the final hour, in the deepest pit without hope, without witness, without reward. Virtue is only virtue in extremis.</li> <li>It all just disappears doesn't it? Everything you are, gone in a moment like breath on a mirror. Any moment now, he’s a coming, (Clara: Who's coming?) The Doctor. (Clara: But you are, you are the doctor.) And I always will be. But times change and so must I. We all change, when you think about it. We are all different people all through our lives and that's okay, that's good, you've got to keep moving so long as you remember all the people that you used to be. I will not forget one line of this, not one day, I swear. I will always remember when The Doctor was me.</li> </ul> <p>Recommend some videos:</p> <ul> <li><a href="https://www.bilibili.com/video/BV1Tx411P746">Bilibili - Are You The One</a> <ul> <li>This song is amazing, perfectly fitting the image of the Doctor. I fell in love with this song through this mashup, and the editing is also very well done.</li> </ul> </li> <li><a href="https://youtu.be/7li5eZ3JZbA?si=TDZun38jWCOf7z9Q">YouTube - The First Question - 50th Anniversary Trailer</a> <ul> <li>The 50th anniversary mashup, a video from 12 years ago, but still not outdated, especially the selection and coordination of lines, as well as the choice of music, are all very well done.</li> </ul> </li> <li><a href="https://youtu.be/-CdJUYWkrR0?si=bmuiay9TYl3zI1zF">YouTube - The First Question - 60th Anniversary Edition</a> <ul> <li>A 60th-anniversary mashup, a remastered version of the previous video from ten years ago, is also very exciting.</li> <li>This video has not been uploaded to Bilibili yet, so I contacted the author and obtained permission to repost it.</li> <li>Bilibili repost: <a href="https://www.bilibili.com/video/BV1unW1e8EwR/?share_source=copy_web&#x26;vd_source=715b7965ee40cd347a349e6161f34dfc">Bilibili - The First Question - 60th Anniversary Edition</a></li> </ul> </li> </ul> <h2>Epilogue</h2> <p>This article briefly talks about the story with DW, but there are more delicate emotions that are hard to express in words. Many episodes are really worth watching repeatedly, and my favorite episode is still <code>Heaven Sent</code>.</p> <p>However, I really hope that the next season of DW can put more effort into the plot. The last episode of S14/New Version S1 is a bit hard to endure... Related discussions are welcome to visit <a href="https://www.lyt0112.com/blog/dw2">[DW] 幽默RTD, 幽默S14E08</a> to watch.</p> <p>Every Doctor's regeneration is not just a process of the Doctor seeking a new identity, but also a process for the audience to accept the new Doctor. The first episode of 12 slowly expresses this process through the emotional changes of the companion. In fact, the audience's acceptance of the new Doctor is also a process of accepting a new self, which in reality represents whether we are willing to bravely start a new stage of life, and whether we are willing to give up things we previously had, even if those things are good and cherished by us.</p> <p>Just like this sentence: <code>So long as you remember all the people that you used to be</code> As long as we remember those beautiful moments on the road of life, we haven't wasted that time. How could I have imagined what I would be like ten years ago, but as long as I remember the emotions brought by DW (or the bad plot from CC) over the past ten years, it's enough.</p> <p> The Doctors </p> <p>What will the next decade be like for me and DW? Nobody knows, but I will always look forward to the next episode of Doctor Who!</p> <p>If you are also a Whovian, feel free to share your stories with DW or your favorite lines/episodes in the comments.</p> <p>After all, that's how the all started!</p> <h2>Credits</h2> <ul> <li><a href="https://www.facebook.com/DoctorWho/posts/pfbid04btj2pTSrWnJXfoMMJQ8rWiHKuz9H9P21QN7Hamwei3sNv6HkL7V8tiS3v8UetFXl">Doctor Who Facebook - Flashpoint, final episode of the Dalek Invasion of Earth</a></li> <li><a href="https://youtu.be/YWfpn6k79pQ?si=eBJH5Zyb2dzMLj_F">Doctor Who Clips - The Five Doctors</a></li> <li><a href="https://en.wikipedia.org/wiki/Doctor_Who_series_8">Wiki - DW S8</a></li> <li><a href="https://en.wikipedia.org/wiki/Doctor_Who_series_9">Wiki - DW S9</a></li> <li><a href="https://youtu.be/7L9cUG3BxN0?si=3b19mIGhbglNDfWz">YouTube - The Subtle Brilliance Of Doctor Who's Most Divisive Finale</a></li> <li><a href="https://youtu.be/7li5eZ3JZbA?si=TDZun38jWCOf7z9Q">YouTube - Doctor Who: The First Question - 50th Anniversary Trailer</a></li> <li><a href="https://youtu.be/-CdJUYWkrR0?si=bmuiay9TYl3zI1zF">YouTube - Doctor Who: The First Question - 60th Anniversary Edition</a></li> <li><a href="https://www.bilibili.com/video/BV1Tx411P746">Bilibili - Are You The One</a></li> </ul>https://www.lyt0112.com/blog/sq1-zhhttps://www.lyt0112.com/blog/sq1-zhSQ-1 魔方的最初级解法, 即使比较初级, 仍然较为复杂Tue, 06 Aug 2024 00:23:21 GMT<h2>魔方介绍</h2> <p>Square-1 (以前称为Cube 21和Back to Square One) 是一个两极类可变形魔方. 它的解法非常独特, 因为上下两层的块是可以通过上下层的转换变换顺序的, 所以不存在角块和棱块之说, 上层可以有10个块, 而底层只有6个块.</p> <p>该魔方由 Karel Hršel 和 Vojtech Kopský 于1990年发明.</p> <p>它是WCA官方项目，最快解法由来自美国的 Ryan Pilat 保持 (3.41秒).</p> <h2>记号表示</h2> <p>顶（底）层在图片的左（右）侧, 所有图均为俯视图.</p> <p>拿 SQ1 让赤道（中层）的前面的左侧为短边. 不要整体旋转 SQ1, 左手始终握住赤道的短边.</p> <p>| 记号 | 含义 | | ------------------ | ----------------------------------------------------- | | $\pm x \pm y$ | 转 U 层 $(\pm 30x)^\circ$ 并转 D 层 $(\pm 30y)^\circ$ | | $n, \underline{n}$ | $n0, 0n$ | | $U, D$ | $3, \underline{3}$ | | $M2$ | 1/-1-1/01 |</p> <h2>复原步骤</h2> <h3>复原形状</h3> <p>所有复形的最后都是要转化成风筝-风筝, 可以做 4 个连角后化成扇贝-风筝；也可以先做 3 个连角并放在 DL，再做 3 个并放在 DR 后化为 8-星形或 71-星形.</p> <p> 复原形状 </p> <p>推荐初学者采用后一种方式, 先把所有 60 度角块放在底层组成一个星星, 就可以套用公式啦. 当你理解了公式的原理后, 你可以尝试脱离公式, 用自己的思考解决, 类似 F2L.</p> <p> 六角星公式 </p> <h3>角块色相</h3> <p>这一步比较简单, 逻辑上类似四阶魔方的中心块复原.</p> <p> 角块色相 </p> <h3>棱块色相</h3> <p>单棱交换就是背公式了, 但是双棱交换可以试试这个公式然后理解这个转换机的工作流程.</p> <p> 棱块色相 </p> <h3>角块顺序</h3> <p>两个比较简单可以理解的公式.</p> <p> 角块顺序 </p> <p>其他情况: 顶层和底层肯定有颜色在同一个面上相同的角块, 把这个面放在左或右侧后做 /U'/UD/D'/ , 变成上图中第一种情况.</p> <h3>棱块顺序</h3> <p>这里的相邻棱交换也是需要背公式, 但是对棱交换也可以试试这个公式然后理解这个转换机的工作流程.</p> <p> 棱块顺序 </p> <h3>奇偶校验</h3> <p>最逆天的公式...</p> <p> 奇偶校验 </p> <h3>赤道翻转</h3> <p>如果最后出现中层位置错误的情况, 可以用这个公式解决.</p> <p> 赤道翻转 </p> <h2>Credit</h2> <ol> <li><a href="https://ruwix.com/twisty-puzzles/square-1-back-to-square-one/">Ruwix: Twisty Puzzle Wiki - Square-1</a></li> <li><a href="https://www.cuberoot.me/sq-beginner-lars/">Cube Root - Square-1</a></li> </ol>https://www.lyt0112.com/blog/sq1-enhttps://www.lyt0112.com/blog/sq1-enSQ-1 cube's most basic solution, even though relatively basic, is still quite complicated.Tue, 06 Aug 2024 00:23:20 GMT<h2>Intoduction to SQ-1</h2> <p>The Square-1 (previously called as Cube 21 and Back to Square One) is a shape-shifting three-layered twisty puzzle. Its solution is very unique because the kite-shaped corners and the triangular edges are indistinguishable to the puzzle's inner mechanism, meaning that corners can be swapped with edges and therefore it's possible to have 10 pieces in the upper layer while only 6 in the bottom.</p> <p>The puzzle was invented in 1990 by Karel Hršel and Vojtech Kopský.</p> <p>It's an official WCA competition event, the fastest solution being held by Ryan Pilat from USA (3.41 seconds).</p> <h2>Notation</h2> <p>The top (bottom) layer is on the left (right) side of the image, all images are top views.</p> <p>Take SQ1 and let the left side of the front of the equator (middle layer) be the short edge. Do not rotate SQ1 as a whole, always hold the short edge of the equator with your left hand.</p> <p>| Notation | Meaning | | ------------------ | ------------------------------------------------------------------------------ | | $\pm x \pm y$ | Rotate U layer for $(\pm 30x)^\circ$ AND rotate D layer for $(\pm 30y)^\circ$ | | $n, \underline{n}$ | $n0, 0n$ | | $U, D$ | $3, \underline{3}$ | | $M2$ | 1/-1-1/01 |</p> <h2>Steps</h2> <h3>Cubeshape</h3> <p>The end of any cubeshape is to transform into Kite-Kite. One can make 4 paired corners then transform to Scallop-Kite. Or make and place 3 paired corners in DL, then 3 more in DR, and then transform into 8-Star or 71-Star.</p> <p> Cubeshape </p> <p>It is recommended for beginners to use the latter method. First, place all the 60-degree angle pieces on the bottom layer to form a star, then you can apply the formula. Once you understand the principle of the formula, you can try to solve it without the formula, using your own thinking, similar to F2L.</p> <p> Hexagram formula </p> <h3>Corner Orientation</h3> <p>This step is relatively simple, logically similar to the restoration of the center piece of a 4x4 Rubik's Cube.</p> <p> Corner Orientation </p> <h3>Edge Orientation</h3> <p>Single edge exchange is about memorizing the formula, but for double edge exchange, you can try this formula and understand the workflow of this commutator.</p> <p> Edge Orientation </p> <h3>Corner Permutation</h3> <p>Two relatively simple and understandable formulas.</p> <p> Corner Permutation </p> <p>Other situations: There are definitely corner pieces with the same color on the same face for the top and bottom layer. After placing this face on the left or right side, perform /U'/UD/D'/ to turn it into the first situation in the above diagram.</p> <h3>Edge Permutation</h3> <p>The adjacent edge swap here also requires memorizing the formula, but for opposite edge swaps, you can also try this formula and understand the workflow of this commutator.</p> <p> Edge Permutation </p> <h3>Parity</h3> <p>The most complicated formula...</p> <p> Parity </p> <h3>Equator Flip</h3> <p>If there is an error in the equator (middle layer) position at the end, you can use this formula to solve it.</p> <p> Equator Flip </p> <h2>Credit</h2> <ol> <li><a href="https://ruwix.com/twisty-puzzles/square-1-back-to-square-one/">Ruwix: Twisty Puzzle Wiki - Square-1</a></li> <li><a href="https://www.cuberoot.me/sq-beginner-lars/">Cube Root - Square-1</a></li> </ol>https://www.lyt0112.com/blog/sf_triphttps://www.lyt0112.com/blog/sf_tripFirst Caltrain Journey, Berkeley, San Francisco.Mon, 22 Jul 2024 17:44:14 GMT<h2>First Caltrain Journey</h2> <p>I was quite curious before boarding the Caltrain for my first experience with public transportation in the US. Purchasing a ticket or acquiring a Clipper card turned out to be straightforward - you can buy a ticket at any station or download a digital card via the Clipper App.</p> <p>Upon arriving at the Caltrain station, I immediately noticed the contrast with Chinese high-speed railway stations. Caltrain stations are considerably more open; you don't have to swipe your Clipper card or show your train ticket to access the platform. Although it's possible to board the train without paying, conductors periodically check for valid tickets.</p> <p>Caltrain features double-decker trains equipped with one or two bike cars. The first level is dedicated to cyclists, making it extremely bike-friendly. As for seating, the second level offers two configurations: a single-seat arrangement with an open view to the lower level, and standard seats accompanied by tables.</p> <p>I took the Caltrain from California Ave Station to SF Station and back, departing at 7:48AM and returning at 8:57PM on Saturday.</p> <p>I generally love its convenience, but it's a bit slow, taking more than 1 hour for a 60km trip.</p> <h2>Berkeley</h2> <p>I took an Uber to Berkeley and enjoyed a brief hour-long tour, wandering around.</p> <h2>San Francisco</h2> <h3>Lunch</h3> <p>In-N-Out Burger!</p> <h3>Exploring and Vintage Shops</h3> <p>Be cautious of coyotes!</p> <p>Enjoy exploring the beautiful mountainous terrain and have fun.</p> <p>{/* In a perfume shop we met a active puppy.</p> <p>Also, purchased chocolates worth $130.</p> <p>A book from 1911</p> <h3>Dinner</h3> <p>Very good location and scene! It's called <code>Crab House</code> at Pier 39.</p> <p>There were people celebrating a birthday there, and we encountered two birthday parties!</p> <p>{/* */}</p> <h3>Golden Gate Bridge</h3> <p>I took some fantastic photos!</p> <p>It was extremely windy and cold, so please dress more warmly!</p> <h2>Home</h2> <p>It was very cold at the SF Caltrain Station before I boarded the train at 9 PM.</p> <p>After arriving at California Ave Station at 10PM, I found it convenient that I had parked my bike next to the platform that morning.</p>https://www.lyt0112.com/blog/clock-zhhttps://www.lyt0112.com/blog/clock-zh7simul flip Method for Rubik's ClockTue, 25 Jun 2024 08:15:04 GMT<h2>基础介绍和还原</h2> <p>这个视频说得又短又清楚: <a href="https://www.bilibili.com/video/BV1pb4y177r4/?p=2&#x26;share_source=copy_web&#x26;vd_source=715b7965ee40cd347a349e6161f34dfc">魔表基础还原教程</a> .</p> <h2>7simul flip</h2> <p>其实本来是想写 <a href="https://www.bilibili.com/video/BV13f421D7uw/?share_source=copy_web&#x26;vd_source=715b7965ee40cd347a349e6161f34dfc">Tommy's 7simul Method</a> 的, 但是正当我要写的时候发现了同一个 UP 刚刚发布了更好的新方法.</p> <h3>观察记录</h3> <p>如果是 Tommy's 7simul Method , 可以将每一个表盘看作一个数字, 每一个箭头看作两个数字之间的向量, 这样更加直观.</p> <p>以如下打乱为例:</p> <p><code>UR3- DR4- DL1- UL2- U1+ R4+ D2- L3- ALL1+ y2 U3- R1- D4- L4+ ALL1+ DR DL UL</code></p> <p>假设面对着你的那一面用大写字母, 背面用小写字母, 读码的时候翻面都使用 <code>x2</code> 上下翻面, 而不是打乱时候的左右翻面, 数字字母编码可以用自己喜好的方式.</p> <p>这个例子使用打乱的时候朝上的那一面作为正面</p> <p>| 步骤 | 描述 | 数值大小 | 编码 | | ---- | ------------------------------------ | -------- | ---- | | 1 | $(R\rightarrow D)+(l\rightarrow ul)$ | 6 | 6 | | 2 | $u\rightarrow c$ | -3 | C | | 3 | $l\rightarrow u$ | -5 | E | | 4 | $(r\rightarrow d)+(L\rightarrow UL)$ | -3 | C | | 5 | $U\rightarrow C$ | 5 | 5 | | 6 | $L\rightarrow U$ | 4 | 4 |</p> <h3>操作</h3> <p>假设面向你的四根立柱分别是 <code>UL</code>, <code>UR</code>, <code>DR</code>, <code>DL</code> , 以下说明的都是哪些立柱突出.</p> <p>| 步骤 | 立柱突出 | <code>UL</code> 轮拧多少 | <code>UR</code> 轮拧多少 | | ---- | ---------------- | --------------------------------------- | ------------------------- | | 1 | <code>UL</code>, <code>DR</code>, <code>DL</code> | 步骤 1 的编码 | 步骤 2 的编码 | | 2 | <code>UL</code>, <code>DL</code> | 对齐 <code>D</code> 和 <code>R</code> 表盘 | 步骤 3 的编码 | | 3 | <code>UL</code> | 对齐 <code>C</code> 和 <code>D&#x26;R</code> 表盘 | 对齐 <code>DR</code> 和 <code>D&#x26;R</code> 表盘 | | 4 | <code>x2</code> 翻面 | <code>x2</code> 翻面 | <code>x2</code> 翻面 | | 5 | <code>UL</code>, <code>DR</code>, <code>DL</code> | 步骤 4 的编码 | 步骤 5 的编码 | | 6 | <code>UL</code>, <code>DL</code> | 对齐 <code>D</code> 和 <code>R</code> 表盘 | 步骤 6 的编码 | | 7 | <code>UL</code> | 对齐左上的四个表盘和 <code>D&#x26;R</code> 表盘 | 对齐 <code>DR</code> 和 <code>D&#x26;R</code> 表盘 | | 8 | <code>UL</code>, <code>DR</code> | 除了 <code>DL</code>, <code>UR</code> , 让其余表盘对齐十二点 | <code>DL</code>, <code>UR</code> 表盘对齐十二点 |</p> <h2>Credits</h2> <ol> <li><a href="https://www.bilibili.com/video/BV17S421d7K2/?share_source=copy_web&#x26;vd_source=715b7965ee40cd347a349e6161f34dfc">不喜欢D轮？来学7simul flip吧</a></li> <li><a href="https://www.bilibili.com/video/BV13f421D7uw/?share_source=copy_web&#x26;vd_source=715b7965ee40cd347a349e6161f34dfc">零基础带你学会魔表7simul法（Tommy版）</a></li> <li><a href="https://www.bilibili.com/video/BV1pb4y177r4/?p=2&#x26;share_source=copy_web&#x26;vd_source=715b7965ee40cd347a349e6161f34dfc">魔表基础还原教程</a></li> </ol>https://www.lyt0112.com/blog/clock-enhttps://www.lyt0112.com/blog/clock-en7simul flip Method for Rubik's ClockTue, 25 Jun 2024 08:15:03 GMT<h2>7simul flip</h2> <h3>Observation</h3> <p>For example, with the following shuffle:</p> <p><code>UR3- DR4- DL1- UL2- U1+ R4+ D2- L3- ALL1+ y2 U3- R1- D4- L4+ ALL1+ DR DL UL</code></p> <p>Assume the side facing you uses uppercase letters, the back side uses lowercase letters, and when reading the code, flip it using <code>x2</code> (flip up and down), not the left-right flip used during scrambling. You can use your preferred method for number and letter encoding.</p> <p>This example uses the side facing up during scrambling as the front.</p> <p>| Steps | Description | Numerical value | Encoding | | ----- | ------------------------------------ | --------------- | -------- | | 1 | $(R\rightarrow D)+(l\rightarrow ul)$ | 6 | 6 | | 2 | $u\rightarrow c$ | -3 | C | | 3 | $l\rightarrow u$ | -5 | E | | 4 | $(r\rightarrow d)+(L\rightarrow UL)$ | -3 | C | | 5 | $U\rightarrow C$ | 5 | 5 | | 6 | $L\rightarrow U$ | 4 | 4 |</p> <h3>Operation</h3> <p>Assuming the four pillars facing you are <code>UL</code>, <code>UR</code>, <code>DR</code>, <code>DL</code>, the following descriptions indicate which pillars are protruding.</p> <p>| Steps | Protruding column | How many steps <code>UL</code> turns | How many steps <code>UR</code> turns | | ----- | ----------------- | ---------------------------------------------------------------------- | ----------------------------------------- | | 1 | <code>UL</code>, <code>DR</code>, <code>DL</code> | Encoding of Step 1 | Encoding of step 2 | | 2 | <code>UL</code>, <code>DL</code> | Align <code>D</code> and <code>R</code> dials | Encoding of Step 3 | | 3 | <code>UL</code> | Align <code>C</code> and <code>D&#x26;R</code> dials | Align <code>DR</code> and <code>D&#x26;R</code> dials | | 4 | <code>x2</code> Flip over | <code>x2</code> Flip over | <code>x2</code> Flip over | | 5 | <code>UL</code>, <code>DR</code>, <code>DL</code> | Encoding of step 4 | Encoding of step 5 | | 6 | <code>UL</code>, <code>DL</code> | Align <code>D</code> and <code>R</code> dials | Encoding of step 6 | | 7 | <code>UL</code> | Align the top-left four dials and the <code>D&#x26;R</code> dial. | Align <code>DR</code> and <code>D&#x26;R</code> dials | | 8 | <code>UL</code>, <code>DR</code> | Except for <code>DL</code> and <code>UR</code>, align the remaining dials to twelve o'clock. | <code>DL</code>, <code>UR</code> dial aligned to twelve o'clock |</p> <h2>Credits</h2> <ol> <li><a href="https://www.bilibili.com/video/BV17S421d7K2/?share_source=copy_web&#x26;vd_source=715b7965ee40cd347a349e6161f34dfc">不喜欢D轮？来学7simul flip吧</a></li> <li><a href="https://www.bilibili.com/video/BV13f421D7uw/?share_source=copy_web&#x26;vd_source=715b7965ee40cd347a349e6161f34dfc">零基础带你学会魔表7simul法（Tommy版）</a></li> <li><a href="https://www.bilibili.com/video/BV1pb4y177r4/?p=2&#x26;share_source=copy_web&#x26;vd_source=715b7965ee40cd347a349e6161f34dfc">魔表基础还原教程</a></li> </ol>https://www.lyt0112.com/blog/skewb-zhhttps://www.lyt0112.com/blog/skewb-zh斜转魔方控心法教程, 包括FL, LL, 侧面中心还原Sun, 23 Jun 2024 08:20:21 GMT<h2>斜转复原方法整体概览</h2> <h3>普通SH叠加法 (LBL Method)</h3> <p>这部分的详细教程可以参考 <a href="https://www.gancube.com/zh/gancube-tutorials-skewb/">Gan's Skewb tutorial</a></p> <h3>控心法 (Optimized LBL Method)</h3> <p>顶面控心: 在普通SH叠加法的基础上, 完成顶角的同时把顶面中心归位.</p> <p>多向控心: 在顶面空心的基础上, 避免出现四心换, 或者跳过三心换. 其实多向控心并不一定要控顶面中心, 当你可以两个对位侧面中心归位时, 剩下的顶多也就是一个包含顶面的三心换.</p> <h3>二步法 (L2L Method)</h3> <p>二步法是更高级的方法, 但是有些case的解法不如叠加, 比如 zbll 中有的小鱼情况的 zbll 还不如直接做OP.</p> <p>叠加二步法 (L2L, Last Two Layers): 完成底面后, 至多需要五个S或H即可还原斜转魔方, 记住每种情况所对应的SH叠加和其中的转体, 一气呵成还原魔方. 总共 134 个公式, 可以参考 <a href="https://www.cuberoot.me/skewb-l2l-by-learning-order/">Skewb L2L Method</a></p> <p>NS法: 对叠加二步法的补充, 叠加二步法中, 当出现需要四个或者五个SH叠加才能完成的情况时, 继续使用叠加二步法步骤太多, 耗时太长, 于是产生NS法对叠加二步法中繁琐的情况发明了新的公式进行补充.</p> <p>KK法: 和NS法一样, 不过不好用, 渐渐被淘汰了.</p> <h3>全预判</h3> <p>推演出还原一面后出现的情况, 然后通过二步法还原斜转魔方, 中间不需要任何停顿和思考.</p> <h2>记号说明</h2> <h3>Basic notations</h3> <p>转动方式和三阶相同, 看向哪个面的时候对那个面做顺时针旋转就是那个角的记号 (没有撇) .</p> <h3>H&#x26;S notations</h3> <p>S (Sledge) 和 H (Hedge) 的名字最开始起源于三阶的术语, 但是在三阶中逐渐淘汰却被发现在 Skewb 上很合适, 于是被发扬光大</p> <h2>控心法教程</h2> <h3>FL (First Layer)</h3> <p>这一步需要复原底层角块和底层中心.</p> <p>总的来说跟三阶的底层十字一样, 需要多多练习, 在你更熟悉Skewb是如何旋转后, 这一步将轻易完成.</p> <p>不过在最初几次复原中, 对于最后一个角你或许会碰上麻烦. 很有可能的是你为了做这个角却破坏了一个已经好了的, 这时有两种情况可用公式处理</p> <h3>LL (Last Layer)</h3> <p>这一步需要同时复原顶层角块和顶层中心.</p> <p>总计十种小情况, 公式如下.</p> <h3>Side Centers</h3> <p>这一步需要复原侧面的中心块, 和初级方法相同.</p> <h2>Credits</h2> <ol> <li><a href="https://www.cuberoot.me/">Cube Root</a></li> <li>李宗阳 <a href="https://www.bilibili.com/video/BV1Tp4y1e74q/">控心法</a></li> <li><a href="https://www.gancube.com/zh/gancube-tutorials-skewb/">Gan's Skewb tutorial</a></li> <li><a href="https://zhuanlan.zhihu.com/p/421944291">斜转魔方: Skewb速拧法</a></li> </ol>https://www.lyt0112.com/blog/skewb-enhttps://www.lyt0112.com/blog/skewb-enSkewb Optimized LBL Method, including FL, LL, side center restorationSun, 23 Jun 2024 08:20:20 GMT<h2>Overview</h2> <h3>LBL Method</h3> <p>The detailed tutorial for this part can be referred to <a href="https://www.gancube.com/zh/gancube-tutorials-skewb/">Gan's Skewb tutorial</a></p> <h3>Optimized LBL Method</h3> <p>Optimized LBL Method: Based on the LBL Method, complete the top corners while returning the top face center to its position.</p> <p>Multi-directional LBL Method: Based on Optimized LBL Method, avoid four-central-block swaps or skip three-central-block swaps. In fact, Multi-directional LBL Method does not necessarily require controlling the top surface center. When you can align two side centers, the remaining will at most be a three-central-block swap involving the top surface.</p> <h3>L2L Method</h3> <p>The two-step method is a more advanced method, but in some cases, the solution is not as good as LBL Method. For example, in some OLL cases in ZBLL, it is better to directly do OLL itself.</p> <p>L2L, Last Two Layers: After completing the bottom face, at most five S or H moves are needed to restore the skewb. Remember the SH combinations and the rotations corresponding to each situation, and restore the cube in one go. A total of 134 formulas can be referenced. <a href="https://www.cuberoot.me/skewb-l2l-by-learning-order/">Skewb L2L Method</a></p> <p>NS Method: A supplement to the L2L Method. In the L2L Method, when it requires four or five SH superpositions to complete, continuing to use the L2L Method involves too many steps and takes too long. Therefore, the NS Method was created to supplement the cumbersome situations in the L2L Method with new formulas.</p> <p>KK method: Same as the NS method, but not very useful, gradually phased out.</p> <h3>Full prediction</h3> <p>Deduce the situation after restoring one side, then restore the skewb cube using the two-step method without any pauses or thinking in between.</p> <h2>Symbol Description</h2> <h3>Basic notations</h3> <p>The rotation method is the same as the third order, when looking at a face, a clockwise rotation on that face is the notation for that corner (without an apostrophe).</p> <h3>H&#x26;S notations</h3> <p>The names S (Sledge) and H (Hedge) originally came from the terminology of the 3x3 cube, but as they were gradually phased out in the 3x3, they were found to be very suitable for the Skewb, and thus were popularized.</p> <h2>Optimized LBL Method</h2> <h3>FL (First Layer)</h3> <p>This step requires restoring the bottom corner pieces and the bottom center.</p> <p>Overall, it is similar to the bottom cross of a 3x3 cube, requiring a lot of practice. Once you become more familiar with how the Skewb rotates, this step will be easily completed.</p> <p>However, during the first few solves, you might encounter trouble with the last corner. It is very likely that while trying to solve this corner, you might disrupt an already solved one. At this point, there are two situations that can be handled with algorithms.</p> <h3>LL (Last Layer)</h3> <p>This step requires simultaneously restoring the top layer corner pieces and the top layer center.</p> <p>There are a total of ten small cases, the formulas are as follows.</p> <h3>Side Centers</h3> <p>This step requires restoring the center pieces on the sides, similar to the beginner's method.</p> <h2>Credits</h2> <ol> <li><a href="https://www.cuberoot.me/">Cube Root</a></li> <li>李宗阳 <a href="https://www.bilibili.com/video/BV1Tp4y1e74q/">控心法</a></li> <li><a href="https://www.gancube.com/zh/gancube-tutorials-skewb/">Gan's Skewb tutorial</a></li> <li><a href="https://zhuanlan.zhihu.com/p/421944291">斜转魔方: Skewb速拧法</a></li> </ol>https://www.lyt0112.com/blog/dw2https://www.lyt0112.com/blog/dw2有钱是真有钱了, 但是 RTD 有点像在逗我Sat, 22 Jun 2024 20:16:05 GMT<p>RTD 写的过于唯心主义了</p> <p>看了看 <a href="https://tieba.baidu.com/p/9061254728">讨论贴</a> 基本上贬大于褒, 参考一些讨论总结一下</p> <h2>优点</h2> <ol> <li>这一季 Kate 的存在感足够多, 很帅很😍.</li> <li>还有 Sarah Jane 的一个反派 Trickster出现, 有点唤起了六年之前的暑假的回忆.</li> </ol> <h2>缺点</h2> <ol> <li>像遛狗一样就遛死 Sutekh 了??? 有点草率了感觉.</li> <li>Ruby 是一个 human 也不是不行, 试图跳出俗套也挺好的, 那凭什么就下雪了❄️还有圣诞颂歌, 毫无逻辑, 真就是因为 “We invest things with significance.” 呗.</li> <li>为什么 Goblin 会管 Ruby 叫 “The Beast” , 难绷.</li> <li>之前Ruby寻亲的时候没找到亲生父母还可以勉强解释成他父母的基因都没入寻亲机构的基因库. 但是既然在2046年战争首相就强制采集DNA了, 那在遥远的未来, 救护机为什么检测不到Ruby亲生父母的信息呢.</li> <li>那个勺子桥段也太离谱了, 不懂意义在哪里, 摸不着头脑, 如果是为了搞笑为啥那么严肃... 看看之前的勺子都是怎么做的, 比如 12 的 Robin hood 那一集还挺好玩的.</li> </ol> <ol start="6"> <li>73 yard 明明是 Moffat 在桥边为了让人恰好看不清脸随便找的一个距离, 怎么就恰巧跟T娘的设定一样了.</li> </ol> <h2>Wait and see</h2> <p>尚未揭晓的伏笔还很多</p> <ol> <li>Mrs.Flood是谁? 能打破次元壁与观众互动、知道T娘、知道Ruby会是博士的同伴、知道苏泰克, 或许还有其他神、衣着模仿克拉拉&#x26;Romana I, 还会说“clever boy”, 所以Mrs. Flood到底是谁? 从本集她谈论造物主和结尾的那段话, 感觉不太像是克拉拉、Susan和Romana (她们仨应该不会用讲故事的语气和表情说15的结局会很惨吧) ... 会是Missy吗? 还是Rani?</li> </ol> <p>在翻贴吧的时候发现 Romana II 美美美</p> <ol start="2"> <li>gravity变成mavity, 60周年特辑的这个伏笔到现在也没有任何揭晓的迹象. 考虑到“ma-”这个字头和"magic", "marvel"相似，而且牛顿在物理学的奠基地位, 这个伏笔似乎是在说世界由科学转向魔法. 这是个最基础的伏笔,至少要到第三季结尾,才会真正扭转过来, 考虑到 RTD 确实喜欢埋多季的伏笔, 这样也不是不行.</li> <li>撒盐对世界的影响，这和第一条是类似的, 都加重了这个世界的魔法性.</li> <li>Ruby的超能力: 下雪, Maestro说这个能力来源于她内心深处隐藏的一首歌, 而Maestro无法将其吸出, 所以Ruby的谜题并未全部揭晓.</li> </ol> <h2>Next</h2> <p>魔法特将于2024年圣诞特辑《普世欢腾》(Joy to the World）回归:</p> <p>“我不能拒绝, 我喜欢写圣诞特辑, 我想过 ‘写过《Boom》了, 不需要再写了’ 然后RTD给我发邮件 ‘你想要写圣诞特辑吗?’ 我回他‘好的, 必须写’ 每写一个故事都可能是我最后一个故事, 我总是想发掘一些东西, 有时圣诞特辑似乎比其它常规集更以博士为核心. 我真的不能多说, 圣诞礼物要留在圣诞节拆开.”</p> <h2>Credits</h2> <p><a href="https://www.digitalspy.com/tv/a60835258/doctor-who-varada-sethu-surprise-appearance">Doctor Who's Steven Moffat addresses surprise early Varada Sethu appearance</a></p> <p><a href="https://screenrant.com/doctor-who-season-14-ncuti-gatwa-modern-doctors-interaction-steven-moffat/">How The New Doctor Would Interact With Other Modern Doctors Revealed By Past Doctor Who Showrunner</a></p> <p><a href="https://screenrant.com/doctor-who-season-14-steven-moffat-interview/">Steven Moffat Explains What Makes "Boom" A Defining Doctor Who Episode For Ncuti Gatwa's Doctor</a></p> <p><a href="https://www.tvinsider.com/1136487/doctor-who-boom-varada-sethu-mundy-susan-twist-characters-steven-moffat">‘Doctor Who’: Steven Moffat Talks Introducing Spoiler &#x26; What Wasn’t in First Draft of ‘Boom’ Script</a></p>https://www.lyt0112.com/blog/dw1https://www.lyt0112.com/blog/dw1Woohoo! Here we go!Thu, 02 May 2024 20:15:26 GMT<p>Ready to rock through time!</p> <h2>说明</h2> <p>本季是自1963年老版开播至今的第40季，是2005年新版复播软重启至今的第14季，也是BBC和Disney+在2023年四部特辑再度软重启全新开启的第1季。日常怎么称呼都可以（比如把1季称呼为14季），只需了解BBC官方定义和运作人RTD专访上《神秘博士》电视剧历史阶段划分为三个时代。综合BBC官方、运作人RTD、外网胡粉、国内胡粉对三个时代的称谓，总结如下（为了避免大家问名单里譬如“怎么没有战争博士和逃犯博士”这种问题，我在其他博士写明他们，只出现在官方杂志、或运作人采访譬如月亮博士、以及老版的养蜂人，因未在银幕中证明身份的，只是运作人嘴上说说，却没在剧里呈现的，我就不加入里面了）</p> <h3>一、经典系列老版（BBC）</h3> <p>1963年至1996年 （1963年至1989年共26季和1996年电影）</p> <p>主演: 1任至8任博士 其他博士: 莫比乌斯博士（1任之前）、Valeyard（无法重生后博士具象化黑暗面）、梅林（未来博士）</p> <h3>二、复活系列05新版（BBC）</h3> <p>2005年至2022年（共13季）</p> <p>主演: 9任至13任博士 其他博士: 战争博士（8任和9任之间时间大战时期）、馆长/策展人(博士退休后可自由更改过去最爱面孔的老年形态)、逃犯博士（1任之前）</p> <h3>三、复活系列23新版（BBC &#x26; Disney+）</h3> <p>2023年至今</p> <p>主演: 14任（结局为博士退休）/15任博士至今 其他博士: 老年5任博士（双重生存活至今），老年6任博士（双重生存活至今），老年7任博士（双重生存活至今）</p> <h2>Credits</h2> <p>https://tieba.baidu.com/p/9010746968</p>https://www.lyt0112.com/blog/hello_worldhttps://www.lyt0112.com/blog/hello_worldHello dear someone in the world, nice to meet you from the beginning of the story!Wed, 01 May 2024 09:13:43 GMT<h2>Hi there!</h2> <p>Hello dear someone in the world, hello from the beginning of the story!</p> <h2>My blogs</h2> <ol> <li>My first website theme was created on May 1, 2024, followed the style of <a href="https://github.com/shiro/blog">Shiro</a>, and was stopped at July 28, 2024.</li> <li>The second website theme was created on July 28, 2024, and is still in use.</li> </ol>