[心得] 2020-2-17 每日新聞

看板Soft_Job (軟體人)作者damody (天亮damody)時間6年前 (2020/02/17 11:45)推噓0(0推 0噓 3→)

留言3則, 2人參與討論串1/1

#每日新聞 # 2020-2-17 每日新聞 # FB: http://bit.ly/2UizW6X # 跟朋友PK寫程式的網站如果有一些嘴炮在那邊吵就直接來pk https://binarysearch.io/ # Rust: prodash可以同時顯示多個程式運行進度 http://bit.ly/38zsitd # Rust: 比較不同的RwLock 在futures_locks::RwLock的情況下，讀取器和寫入器獨立排隊。調度程序無法將鎖獲取與該模型交錯。測試的異步版本顯示了預期的“Reader 餓死”行為。 async_std::sync::RwLock不會顯式地將任務排隊，而是依賴於一個雙態計數器，該計數器可以“鎖定寫入”或“由n個Reader 鎖定”。這種實現方式的麻煩在於，雙態計數器可能永遠保持讀取狀態。獲取讀取鎖的唯一要求是寫入器不持有該鎖。這使Reader讓Writer挨餓。 futures_util::lock::RwLock具有與async-std中非常相似的實現。由於這是一個開放的（並且正在運行！）PR，因此作者對我的報告做出了回應。而且我懷疑這種實施方案將在審查之前解決飢餓問題。最後，tokio::sync::RwLock使用waiter隊列，其中Reader從信號量中獲取1個許可，而Writer則獲得所有許可。服務員隊列按FIFO順序交錯讀寫鎖定獲取，因此它確實提供了公平的鎖定策略！萬歲！ http://bit.ly/2u2KzA8 # Java: SocialInfo4J 可從社群網站取得資料可從fb ig 拿資料 http://bit.ly/2uQ8vXV # Go: resilient service worker http://bit.ly/2PfoQfZ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.141.7.243 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1581911152.A.1E9.html