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を触ってる

• 自分用のアプリのログ処理を入れ換えた
• windowsとlinuxそれぞれあるけど、fluentd-forwarderを使ってlinuxのfluentdに集約
• windowsはrubyで書いてる
  • ruby2.1じゃないと動かない
    • http://qiita.com/okahashi117/items/a0b55ea24a6ef7b6582b
    • msgpackは未対応
    • オプションが渡せないため、bundlerも使えない
  • SSL接続に失敗する
    • https://gist.github.com/luislavena/f064211759ee0f806c88
    • ここのpemファイルの位置をSSL_CERT_FILE環境変数に設定する必要がある

fluentd-forwarder にPR送った

• atomic処理のメモリアライメント的な問題でwindows 32bitだと動かなかったので直した
  • https://github.com/fluent/fluentd-forwarder/pull/10
  • まだマージされてないので、手元のブランチでビルドしたものを使ってる
• goのパッケージシステムは手元で動かすのとものすごく相性が悪い
  • 全てのパッケージバスを自分のリポジトリに書き換えないといけない
  • しかもmasterブランチ限定