推 springgod:偷偷推一下 有沒有考慮在顯示的時候拿掉? 140.112.251.218 09/21
※ 引述《reader (讀者)》之銘言：
: ※ 引述《in2 (敬請期待 :P)》之銘言：
: : 我知道這樣子很佔板面, 可是這樣子做有幾個好處:
: : 1.
: : 因為目前 .DIR 是 linear 存的
: : (即第一篇放在 0*sizeof(fileheader_t) , 第二篇放在 1*sizeof(fileheader_t))
: : 於是要清掉中間其中一篇, 是會導致大量的資料搬動的,
: : 尤其如果又在尖鋒時段, 系統 loading很高的時候再加上那個板很大的時候,
: : 這樣做一點都不是好主意.
: 但是絕大多數時候，都是刪除最近的文章，搬移動作對於系統的
: 負擔，並不太大。例如兩岸板大多數時候，都是刪除剛轉進來的
: 文章。
: 又或者如果是搬移太前面的文章，才使用 (本文已被刪除)。
@_@
: : 2.
: : 因為推文、修文會把 fileheader_t 寫到 .DIR 原來的地方,
: : 如果原來的地方被壓掉的話, 就會爛掉 (所謂黑洞一類的)
: : 所以使用 (本文已被刪除) 其實可以大量避免黑洞的問題.
: 我沒有看過 ptt 的原始碼，但早期的 bbs 都有總文章數的設計，
: 頂多是造成推文推錯或推文數不對，而修文更只是純檔案的操作，
: 並不需要寫入什麼資訊在 .DIR, 理論上會造成問題的，只有新增
: 文章才對。可以簡單解釋一下嗎?
這個我前面已經解釋過了 @@
: : 我覺得現在機器的 loading已經夠大了,
: : 做一些很暴力的事情 (像是 semaphore) 並不是好主意 @@
: : 而且我也想不到要怎麼用比較好?
: : 一個板一個 semaphore?
: : 每次有人要讀/ 寫就去 lock 那個 semaphore ?
: : 那 performance會爛掉 :p
: : 我還是覺得用本文已刪除最好 ;p
: 新增文章和刪除文章才需要吧。而且也能透過各板的 busy flag
: 單用兩個 simaphore 達成 mutex 的效果。
光是新增和刪除要, 這個量就大的不得了了.
而且請麻煩參考我前面寫的文章,
就算是 mutex還是不會解決目前碰到的問題.
: 其實 256 個 simaphore 才用到一個 IPC key, 可以製造 128 組
: mutex, 並不是那麼佔用系統資源的事，雖然我沒試過 loading
: 很大的狀況，但也不曾覺得 simaphore 很暴力很傷效能，又不是
: 要用 Dijkstra 演算法手動自行製造 mutex.
我還沒有看過 kernel source , 並不知道實際 simaphore 是怎麼 implement ,
只是想起來就很傷 ^^;;;
尤其如果又是用 spin-lock做的話 :p
: 如果現在的 ptt 已改成 multi-threading (應該是吧), 那麼還
: 能使用 pthread_mutex_lock 的方式，更節省系統資源，不過沒
: 試過效能如何就是了。
不是, 我們現在還是 multi-process 架構.
目前大部份的 bbs也都是使用 multi-process ,
multi-threading 目前我只有聽過天火.
也許 colabbs也可以算是 multi-threading,
不過 colabbs performance太差,
當然不考慮.
: 這都不用大改程式碼，不然我更推薦用 thread/process + pipe
: 專門處理資料新增和刪除，亦即 resource manager 的做法，就
: 不會有那麼多奇奇怪怪的資源共享問題了。
與其這樣子的話, 倒不如用我想的某個方式.
在 SHM中, 開個新的 array, 對於每個板給一個 char vstate
(共花費 MAX_BOARD bytes)
如果有發生砍文章的動作 (包括 expire)
就把該值加一.
在輸入推文前以及進入修改文章前, 自己先紀錄一下當時的 vstate.
等到要寫入 .DIR 之前, 再核對一下和當前 SHM中的一不一樣.
如果一樣的話就寫入, 不一樣的話就推薦失敗/ 修文失敗 (存進暫存檔)
這樣子聽起來明顯會有 race ,
不過就目前的情況看起來應該會好的多/ 可以解決大部份的情況.
等到真的 race 再來手動修就是 :p
--
「假設上天只給我愛情或微積分, 我願選擇一生的幸福」
-- ψ 中華人民共和國 1981-未決
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.112.30.144