- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
N(8-32) threads will access a same atomic variable,will this impact the scalability?
I use this atomic variableto do some notes for every thread.I don't know if there is better way to do that?
TBB has any datastructurewhich candistribute the access or mitigate the parallel race? how does concurrent_queue distribute the access?
コピーされたリンク
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
> N(8-32) threads will access a same atomic variable,will this impact the scalability?
Yes, indeed.
> I use this atomic variableto do some notes for every thread.I don't know if there is better way to do that?
It depends on what exactly you do. In general you need to distribute data structure, centralized mutable data structures do not scale on Intel platforms.
> TBB has any datastructurewhich candistribute the access or mitigate the parallel race?
Maybe thread local storage.
> how does concurrent_queue distribute the access?
It does not.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
TLS can be used to store data per thread,but eventually I need to calculate a sumof all these data...
seems has to do this serially.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
TLS can be used to store data per thread,but eventually I need to calculate a sumof all these data...
seems has to do this serially.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
You may try following (as suggested already):
Worker threads updates the values which are dedicated to each of them (carefully seprated against false-sharing, visible to collector/aggregator/summer/reader thread). Aggregator periodically or as needed polls each value and performs the agregate function calculation. I gues yo don't need to have any locks to read-from per-thread (single updater) values. TLS not needed in this way if you choose to poll the values rather than push it via workers.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
If the problem allows usage of thread-local data with subsequent/periodic/episodic aggregation, then it's usually the way to go.
If aggregation phase takes significant time, it may be parallelized as well. Consider parallel merge phase of the parallel merge sort.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
