分享到plurk 分享到twitter 分享到facebook

版本 801f34c5bc677c109826b3d8f2f4e44566659238

User/sternacht

Changes from 801f34c5bc677c109826b3d8f2f4e44566659238 to 5e8013401582240ae01a9ea727ebccf6d8686317

---
title: sternacht (許中瑋)
categories: User
...
# 簡介

# 2022 Linux 核心設計 春季班 自我評量
* 國立成功大學 工程科學系 111 級 (2018~2022)

* github : [`sternacht`](https://github.com/sternacht)

## 成果發表
## Linux 核心和相關專案貢獻

# 2022 Linux 核心設計 春季班 自我評量

## 作業共筆
* [lab0](https://hackmd.io/T7CyT9P2QOiTjh9XkOTEdg)
* [fibdrv](https://hackmd.io/h2SqV4_DSIiFtxS2hipBCg)
* [ktcp](https://hackmd.io/MvBaTZWsQDuSXbrrH-uSDQ)

## 隨堂測驗共筆
* [quiz1](https://hackmd.io/tPI7uafoQ1G2t5Bv9vsxEg)
* [quiz2](https://hackmd.io/qxT5WW6CQS6nJdGnGvRvow)
* [quiz3](https://hackmd.io/vpS9eWxBRwitmGuK5bpriA)
* [quiz4](https://hackmd.io/gj8N2imaS9GJvkzh8R3O4A)
* [quiz5](https://hackmd.io/eIyvzngQRUeh2CiWJbrxXg)
* [quiz8](https://hackmd.io/31dvPt8VQoW3ePF184Q9uA)

## 期末專題
* [quiz5-B](https://hackmd.io/eIyvzngQRUeh2CiWJbrxXg)
* 一對一討論[附件1](https://mail.google.com/mail/u/0/?hl=zh-TW#search/一對一/FMfcgzGpFWJxkgWgmLmqqdGTbShKcnvg), [附件2](https://docs.google.com/document/d/1dkScu9rfG-PdP6wLnBgKn484UuiDc0Dupu23t9yr2Pc/edit), [附件3](https://docs.google.com/document/d/1KEgYiQ6KIYmfip0AY7ilLMsW6zHgaxBc9xdJNj3QM4Q/edit)
* 一對一討論[附件1](https://docs.google.com/document/d/1A_aSRPuKHZNqegXd8n4z5JlXG_8bByXhl2kyb3p4HoQ/edit), [附件2](https://docs.google.com/document/d/1dkScu9rfG-PdP6wLnBgKn484UuiDc0Dupu23t9yr2Pc/edit), [附件3](https://docs.google.com/document/d/1KEgYiQ6KIYmfip0AY7ilLMsW6zHgaxBc9xdJNj3QM4Q/edit)

* 成果
1. 根據現有程式碼及[論文](https://erdani.org/publications/cuj-2004-12.pdf)提示優化程式執行時間
2. 修改程式碼使執行多個 writer 的情況下不會有 data race 發生
3. 使用 Userspace RCU 函式庫改寫程式碼,並用條件編譯將兩種執行方式存在同一份實作中

* 啟發 : 在做這份期末專題之前,我從未做過一份實作需要考慮到這麼細的時間刻度,也因此,在整個專題的過程中都不斷地在想如何在避免 data race 以及優化程式碼流程之間做取捨。例如一開始在想著要怎麼在多加入 active 參數的同時能做到程式執行不會出錯,試了許多方式總是會出問題,於是走回笨方法直接用 CAS 一整個 data struct,果不其然速度上就慢了許多,這時候突然就體會到原本隨堂測驗提供的程式碼之中所用的方式,用指標是否為 null 作為 active 來判斷,其實是一個相當好的方式。
另一個感觸是,在多執行續的執行環境中,程式能否執行到結束已不是最終目標,更重要的是執行的過程中不明顯的錯誤必須被避免的同時,又不會拖累太多效能,說起來跟人之間的團隊合作也有幾分相似。

## 所見所聞所感
一開始打算修這門課時,聽了一些前人的回饋都是說這門課很難,要花很多時間,但心裡想著我都大四了,不就是最有空的時候嗎,於是果斷陪著朋友一起來修這門課。結果第一周派的作業就來了個迎頭痛擊,光是閱讀完一遍第一周的材料以及作業講解就幾乎花了一個禮拜,撰寫程式到通過測試時已經快到第二個禮拜日了。不過通過第一個作業,我也發現過去我所寫的 C 語言程式都太過簡單,許多 C 的特性及限制也都從未注意過,過去總是弄不明白的指標也在作業的過程中有進一步的認識。

學期中寄來了老師編撰關於排程器的電子書,除了 github 與上課的材料之外,這是第一次接觸到與 linux kernel 相關的材料,在閱讀上雖然不算吃力,但總是似懂非懂,缺乏自己動手實驗帶來的感受,後續則因為忙於其他課程及期末專題而忽略了這本電子書,另一份《每位程式開發者都該知道的記憶體知識》則在看過幾章後,自認先備知識不足而放棄閱讀,現在想想覺得有些可惜。

學期後段開始製作專題,閱讀了三篇論文,相較於電子書,論文的內容在閱讀上更為吃力,光是看過並不容易完全明白其中的意思,與老師討論的過程中也發現我閱讀論文的習慣並不正確,更應該做的是在閱讀的過程中嘗試提出疑惑,而不是自己為那些不明白的地方找解釋,否則此舉燭之舉對學習而言並無幫助。此外我也嘗試將論文中所提到的方法實際應用在實作中,雖然過程並不順利,甚至幾乎算是相當失敗,但還是一個很好的經驗。

## 自我評量
我給自己 7 分 

這一整個學期下來,大部分能看懂能聽懂的教材我都盡量花時間在上頭去了解,隨堂測驗也從第一周的兩個零分之後漸漸上手,作業以及隨堂測驗的後續討論也在能力範圍內盡力的去做的,只不過到最後學期末的時候專題在實作上總是感覺自己好像已經了解了很多相關的知識,卻在撰寫程式碼的過程中一一被打槍,回頭想想那些教材我充其量也只是看過,並沒有真正的看懂。雖然如此,我還是學到很多東西,包括瞭解程式碼撰寫的技巧以及寫程式的思維, 7 分我認為對的上我這學期的努力。
這一整個學期下來,大部分能看懂能聽懂的教材我都盡量花時間在上頭去了解,隨堂測驗也從第一周的兩個零分之後漸漸上手,作業以及隨堂測驗的後續討論在能力範圍內盡力的去做的,每個禮拜都花了不下 40 小時在上頭,只不過到最後學期末的時候專題在實作上總是感覺自己好像已經了解了很多相關的知識,卻在撰寫程式碼的過程中一一被打槍,回頭想想那些教材我充其量也只是看過,並沒有真正的看懂,更深入的細節也沒有想清楚,雖然如此,我還是學到很多東西,包括瞭解程式碼撰寫的技巧以及寫程式的思維, 7 分我認為對的上我這學期的努力。