予想に反しておもしろい記事だった＞＜
マイクロソフト"心臓部"で見た｢AI革命劇｣の本質 世界一アツい企業の内部は静寂に包まれていた | 特集 | 東洋経済オンライン https://toyokeizai.net/articles/-/746006
気温が微妙で体調つらい＞＜
能登半島地震 隈研吾さん 輪島市の復興計画のアドバイザーに就任 | NHK | 令和6年能登半島地震
https://www3.nhk.or.jp/news/html/20240407/k10014415061000.html
2024年3月18日
ことしで90年 函館大火 | NHK北海道
https://www.nhk.or.jp/hokkaido/articles/slug-n1b03607c822e
[B! 技術] 世界初の「走行中にEVをワイヤレス充電できる高速道路」がまもなく誕生
https://b.hatena.ne.jp/entry/s/gigazine.net/news/20240408-first-highway-segment-that-can-charge-electric-vehicles/
"...合計400メートルほどの区間に設置が行われ、大型トラックを用いたテストが行われることになっています。"
Interstate Highway System - Wikipedia
https://en.wikipedia.org/wiki/Interstate_Highway_System
"Length 48,756 mi[a] (78,465 km)"
SemaphoreSlim版も追加した＞＜
C#で、await lockっぽいやつ＞＜
https://gist.github.com/orange-in-space/f8e4b03afafb465d771f7f6d8a005c87
orange
さんがブースト
パフォーマンスじゃなくて，単に await できるロック開放待ち機能を持ってるからって話だと思います．
ハードウェアの都合で排他処理が多数発生する一方でスレッドプールな感じの処理があまり必要ないような場面であれば、昔ながらのThreadクラスとlock(Monitor)を使うべき？＞＜
（そういう場面ではlockとSemaphoreSlimの性能差の影響がawaitでの最適な（？）スレッドプールの扱いによる性能向上よりも大きくなる可能性が高い？＞＜）
awaitは処理の中でスレッドが変わっちゃう事がある（待つ時にスレッドを占有しない）ので、同一スレッドから呼び出すのが前提のlockは使えないっぽい＞＜
なんでスレッドを占有しないかというと、（一般的に考えて）たぶんその方がだいたいの場面でパフォーマンスがいいから＞＜
で、代わりにSemaphoreSlim が使える＞＜
でも、SemaphoreSlimはlockと比べるとパフォーマンスよくない＞＜
難しい＞＜；
マルチスレッドで高速なC#を書くためのロック戦略 #C# - Qiita
https://qiita.com/tadokoro/items/28b3623a5ec58517d431
orange
さんがブースト
そういう場面では SemaphoreSlim を使うらしいよ
orange
さんがブースト
await lock(lockobject)に相当する部分、最近作ってる特定のプロセスの音だけ録音するライブラリのデモアプリにも出てくるけど、スレッドつくって頭でMonitor.TryEnterをループで回すってしてる＞＜
これ作るために試行錯誤してわかったけど、排他処理を複数同時にしなきゃいけないような場面でasync/awaitを使うと大混乱に陥るので、そういう時はasync/await使わないほうがいい！＞＜；
作った＞＜
C#で、await lockっぽいやつ＞＜
https://gist.github.com/orange-in-space/f8e4b03afafb465d771f7f6d8a005c87
？？？？？？？＞＜
c# - Monitor.TryEnter doesn't work - Stack Overflow
https://stackoverflow.com/questions/21410320/monitor-tryenter-doesnt-work
await lock(lockobject)に相当する部分、最近作ってる特定のプロセスの音だけ録音するライブラリのデモアプリにも出てくるけど、スレッドつくって頭でMonitor.TryEnterをループで回すってしてる＞＜
ていうかasync/awaitを使う方が圧倒的に性能がよくなる場面が圧倒的に多いと思うけど、(少なくともハードウェアの都合が出る場面では)わかりやすさとか排他処理は、昔ながらのThreadクラスを使って書く方が圧倒的に簡単では感＞＜
ウェブアプリとか事務処理とか？ は、もしかしたらasync/awaitの方が使いやすいのかもしれないけど＞＜
await lockがあったらめちゃくちゃ便利そうだけど、オレンジはそれ以前にasync/awaitを自分のコードで率先して使ったこと無い＞＜(使わなきゃ使えないライブラリの時だけ使う)
音系のアプリを作ること多いのでマルチスレッドじゃないと困る場面は多々発生するけど、全部Threadクラス使って自分で制御してる＞＜
orange
さんがブースト
C#で
```
await lock(someObj)
{
// ....
}
```
みたいに書けたらいいなぁ、と思ってたんだけどやっぱり似たようなことを考える人はいるようで
Async thread lock ("await lock") · Issue #983 · dotnet/csharplang · GitHub https://github.com/dotnet/csharplang/issues/983
- ＠orange_in_space
2017年 4月に登録
