１つ目のコードについては

2:09 AM

concurrentキューなので

2:09 AM

投入されるタスク同士は並行に動いちゃいます

2:10 AM

Dictionaryに対する並行アクセスが、readだけでも並行アクセスしても大丈夫なのかがそもそもわからないので、get側のsyncだけでも怪しい気はしますが、それは別にしても

2:10 AM

set側のasync(barrier)は、バリアされたタスク同士の同時実行を防ぐものなので https://developer.apple.com/documentation/dispatch/dispatchworkitemflags/1780674-barrier

2:11 AM

~~書き込み操作同士は直列化されますが~~ (edited)

2:11 AM

~~読み込み操作とは（多分）排他されないので~~ (edited)

2:11 AM

~~Dictionaryに対して書き込みと読み込みを同時に行う可能性のあるコードになってます~~ (edited)

2:12 AM

~~これは明確にDictionaryに対する違反なので暴走して未定義状態になってると思います。~~ (edited)

2:12 AM

２つ目のコードについては、デッドロックしてないと思います。

2:12 AM

~~nを10000x1から10000x10まで順番に増加させていくと~~ (edited)

2:13 AM

~~だんだん処理時間が増加していって、6,7,8ぐらいで急激に増加してました~~ (edited)

2:13 AM

~~なので、x10のときも時間がかかってるだけに思います。~~ (edited)

2:14 AM

~~急激に増加するのはおそらくDictionaryのrehashが発生するからだと思います。~~ (edited)

2:14 AM

ちなみに1つ目のコードに関しても、個人的には書き込みをasyncで後回しにするのはあまりやらないほうが良いと思っていて

2:15 AM

その理由は、後回しにする事自体がDispatchQueue側のリソースを食うからです。

2:15 AM

めちゃくちゃたくさん使われるプリミティブなところでそういう処理を書くと、ちょっとしたスケジューリングのブレとかで、

2:15 AM

一瞬で10000タスクがDispatchQueueに乗って待機しちゃうことがありえます

2:16 AM

そうすると普通にそれだけの要素数の配列を読み書きするコストがDispatchQueue内部でかかるし、メモリも食うので、