atomicな処理でアライメントを揃える必要があるらしい

goのatomic.AddInt64や、
WindowsのInterlockedExchangeでは、
32bit環境で64bitの値をアトミックに変更する場合、
その値が64bit境界に置かれている必要があるらしいです。
ですが、何故それが必要なのかを調べているのですが、それらしい理由が見つかりません…

一応、Intelのアーキテクチャには、ロックをせずに変更する場合、
64bitアライメントに乗っていない場合はアトミックな処理が保証されないと書いてありましたが、
goではロックしてからCMPXCHG8Bを実行しており、アトミックな処理になるはずです。

また、ロックやCMPXCHG8Bもメモリアライメントの制約は受けないため、特に問題は無さそうです。

一応、64bit境界に無い場合は性能が低下する可能性があるそうですが…

Android 触ってた

  • string.xmlは同じフォルダに別の名前のxmlを作っても、勝手にまとめてくれるので同じようにアクセスできるみたい。
  • Dropbox SDKを触ってみた
    • サンプルがかなり良い具合に出来ている
  • UIを変更できるのは描画用のスレッドだけ
    • doInBackgroundは別スレッドで処理を行う
    • UIを変更しようとすると落ちる
    • 終了時にonPostExecuteがUIスレッドで呼ばれるのでそこで処理する

fluentdを触ってる

fluentd-forwarder にPR送った

  • atomic処理のメモリアライメント的な問題でwindows 32bitだと動かなかったので直した
  • goのパッケージシステムは手元で動かすのとものすごく相性が悪い
    • 全てのパッケージバスを自分のリポジトリに書き換えないといけない
    • しかもmasterブランチ限定
このエントリーをはてなブックマークに追加