Reactivecocoa: アトミック：SPINLOCKはiOSでは安全ではありません

「違法」の意味すらわかりません。

最初からいなかったので、興味がありますが、そもそもAtomicタイプにOSSpinLock使用されたのはなぜですか？

NSLock使用された後、遅すぎることが示された後、 pthread_mutex_tがテストされ、遅すぎることが判明しましたか？ 残念ながら、gitには「ソースの移動…」の前の履歴がありません。

スピンロックは、カーネルやデバイスドライバー以外のコンテキストで使用するとは思わないので、私は尋ねます。 どちらかといえば、ここでのバグはOSSpinLockがまったく使用されていないことだと思います。 ：stuck_out_tongue：

上記の私のコメントに対位法を追加するために、これはタイトルがそれを理解するかもしれないほど大したことではありません： https ：

CPUが不足している場合でも、クリティカルセクションが非常に小さいため、実際の状況では問題ない可能性があります。
—Twitterの@Catfish_Man

@kastiglioneからの上記のコメントについて：

「違法」の意味すらわかりません。

答えはわかりませんが、ARM CPUに何かがあると、スピンロックプリミティブがIntelCPUと同じ利点/保証/仮定の多くを享受できないと思います。 （しかし、https：//twitter.com/Catfish_Man/status/676851988596809728によると、おそらくすべてではありません）

とにかく、実際には「ここには何も表示されない」可能性があります。代わりに、 @ NachoSotoが示唆するように、より安全なプリミティブに置き換えてパフォーマンスの低下を測定するために、調査を行う必要があります。

https://twitter.com/jspahrsummers/status/679245419931660288と、 https：//github.com/ReactiveCocoa/ReactiveCocoa/pull/278を含むフォローアップを

OSSpinLock使用を置き換える必要があると思いますが、利用可能なドキュメントを考えると、それらを使用する理由は有効だったと思います。

ええ、そして関連する歴史のコミットに感謝します。 特定のファイルの履歴が要求されたときにGitHubがgit log --follow実行しない理由がわかりません。

とにかく、「おそらく大丈夫だ」と繰り返し述べます。 「今より高速な」ミューテックスを使用することはおそらく簡単な作業ですが、最初にそれらをどのようにプロファイリング/テストしたかを知らなければ、それほど簡単ではありません。 そこに何か提案/ポインタがありますか？

パフォーマンスが懸念される場合の前進方法については、ロックフリーキューを調査する価値があります。 （概念に慣れていない読者のためのかなり良い記事があります：http：//www.linuxjournal.com/content/lock-free-multi-producer-multi-consumer-queue-ring-buffer？page = 0,0）。 少し前に内部オーディオライブラリ用に似たようなものを作成しましたが、このように一般的な用途に適合させることができるかもしれません。

「今より高速な」ミューテックスを使用することはおそらく簡単な作業ですが、最初にそれらをどのようにプロファイリング/テストしたかを知らなければ、それほど簡単ではありません。 そこに何か提案/ポインタがありますか？

私はInstrumentsのTimeProfiler andAllocationsでGitHubDesktopを実行し、RACを多用するスタックに焦点を合わせていました。 今は@joshaberまたは@mdiepに相談する必要があります。 ：ウィンク：

知っておいてよかった。 Swift側のものは、テストするために同様に大きくて深いコードベースを必要とするだろうと思います。 私は過去数か月で自分の成長を遂げました¹が、RACを「十分に強く」押して十分なサンプルを取得できるかどうかはわかりません。 他の多くのものは、私のようなアプリでインスツルメンツチャートに現れる傾向があります。 ：スマイル：

¹プラグ！ http://capoapp.com 、とhttp://capoapp.com/neptuneは最新、完全に設計された、使用して-RAC4コンポーネントです。

私は今日、iOSでスピンロックが「違法」である理由について詳しく説明するブログ投稿を書きました： http ：

少し前にAtomicを中断し、pthread_mutex_lockに移行しました。 すべてのアカウントで、これは最高のロックです。NSLockのような動的ディスパッチはなく、スピンロックのように競合しない限りインスタントロックは、スピンロックとは異なりエネルギーを浪費しません。

私のリポジトリからソースをコピーして貼り付けるか、好きなことをしてください。

https://github.com/Adlai-Holler/Atomic
https://github.com/Adlai-Holler/Atomic/blob/master/Atomic/Atomic.swift

@kballardそれは素晴らしい説明です、ありがとう！

私はこの問題の専門家ではないので、これについて強い意見はありません。 使用するロックの種類を変更する（または変更しない）かどうかの決定は他の人に任せますが、自分で変更することもできます。

そのようなベンチマークは、ソースなしでは完全に役に立たない。 さらに、実際に何を表しているのかを文書化せずに、構成ごとに1つの時間を表示しているだけです。 さまざまな構成要素は、競合しているかどうか、ロックで競合しているスレッドの優先順位などに応じて動作が異なります。 @synchronizedも好奇心旺盛な獣であり、そのパフォーマンスはアクセスパターンに大きく依存します。 、同じオブジェクトを繰り返しロックしているのか、新しいオブジェクトをロックしているのかなど、同時にいくつの@synchronizedブロックが出入りするかなど。

注意： dispatch_semaphoreは優先順位を寄付しません。これは、もう1つの潜在的な落とし穴です。

@ jspahrsummers @ kballardアトミックCASを使用した実装があります。 興味があればPRをお願いします。

編集： Atomicの使用法を見ると、私の実装は役に立たないと思います。 べき等更新を実行できる場合、CASを使用すると、メモリ内で一種の楽観的なトランザクションを実行できます。これは素晴らしい場合がありますが、かなりのリファクタリングが必要になります（ただし、すべてがCoW不変である場合は非常にうまく機能しますが、実際には突然変異を次のように扱うことができます。インメモリトランザクション）。

私は今日このスレッドを見つけ、さまざまな種類の同期を調査し、iOSシミュレーターと実際のデバイスでベンチマークを実行しました。
結果は私にとって非常に興味深いものです。 iOS 10では、dispatch_semaphoreのパフォーマンスが明らかに低下しています。これは、スレッドの優先順位を尊重して動作が変更されている可能性があります。
これは、iOSで利用可能な基本的な同期メカニズムの概要図です。 すべてのテストはリリース構成で実行されます（Swift最適化-O）

SDK9のベンチマークコード
SDK10のベンチマークコード

あなたの番号は私には非常に疑わしいようです。 テストは何回実行しましたか？

比較のために、しばらく前に書いたハッキーなベンチマークハーネスを使用して、OS X 10.11.5で独自のベンチマーク（ソース）を実行しました。 ベンチマーク全体を10回実行し、各テストから下位2つの数値と上位2つの数値を削除し（外れ値を取り除くため）、残りの数値は次の範囲を生成しました。

同期なし：22-41ns
スピンロック：24ns
セマフォ：29ns
NSLock：45-71ns
ミューテックス：40-64ns
同期：75-122ns
キュー：505-554ns

このことから、スピンロックがはるかに安価であり、次にセマフォ、ミューテックス、NSLockがミューテックスの少し後ろにあることがわかります（基本的にミューテックス+ objc_msgSendであるため）、同期はほぼ2倍の費用がかかり、最終的にキューは非常に高価になります高価で、はるかに-私が予想したよりもそうです。

ご覧のとおり、

理由