2016-07-22 14 views
2

私は原子的にも非アトミックにも同じメモリ位置を操作したいと思います。ユニオンを介したアトミックなアトミックなアクセス

はのは、私がintのように、単純型での作業、特にstd::atomic<T>::is_lock_free()戻りtrue、そのsizeof(T) == sizeof(std::atomic<T>)ことだと仮定しましょう。

私はreinterpret_castが働くべきであると考えた:

std::atomic<int> x; 
int& xx = reinterpret_cast<int&>(x); 

しかしN4013が、これは、コンパイラで型に基づく別名解析を混乱させ、したがって、信頼性がないことを説明しています。

私の質問は:についてはどうですか?次のように作成する場合:

union AtomicInt 
{ 
    int nonatomic; 
    std::atomic<int> atomic; 
}; 

AtomicInt x; 
x.nonatomic = 5; 
x.atomic.compare_exchange_weak(...); 

これは意図したとおりに動作しますか?同じメモリを原子的にも非原子的にも操作できますか?


非アトミック操作の代わりにload(std::memory_order_relaxed)を使用する方法についての提案を先取りするために、 私は関連の質問にthis answerでの提案を試みたが、それは50%で私のコードをスローダウン。

+0

'std :: atomic 'は内部的に 'int'と同じだと思いますか? –

+0

ロックフリーでサイズが同じであれば、違うと想像しています。 – foxcub

+0

私もそういうことについて間違っていました。私はあなたが得る最高の結果は、それがうまくいくと思われるということである。決して失敗したり、それに気づくことさえありません。格納された値へのアクセスは、まったく異なる方法で行われます。 'int 'を介して加えられた変更は、例えば別のCPU上で動作するスレッドには見えないかもしれません。あなたのコンパイラが出す指示を見て、それがうまくいくかどうかを見てください。せいぜい私は、「働く」はプラットフォームに依存するUBだと言います。しかし、パフォーマンス上の理由からそれを行う必要があるかもしれません。 –

答えて

0

ロックフリーの原子プリミティブは、混雑度が非常に高いためです。高い輻輳があり、アトミック変数を非アトミックとして使用し始めると、具体的なアーキテクチャの場合はのバグが導入されます。intatomic<int>のレイアウトは同じです。

輻輳が少ないが、特定の注文が必要な場合は、ロックを使用する必要があります。

+2

並列実行中に私の変数を非アトミックとして使用することは決してありません。原子の実行に先行する連続実行中に非アトミックとしてそれらを使用したいと思います。 – foxcub

+0

次に、他の(非原子的な)変数をその前に使用し、それを後でアトミックに割り当てるのはなぜですか? – Dutow

+1

私はコピー(とメモリ)のオーバーヘッドを望んでいません。 – foxcub

関連する問題