リード・ライトが逆転しないの意味

以前、Load-Link/Store-Conditional(LL/SC)の話を書いた。

予約してメモリを書き換える

同じ変数を複数のコアから書き換える場合に、書換の予約をして、

他のコアがアクセスしていなければ書換を実行するという仕組みである。

他にマルチコアのメモリアクセスにまつわる問題を解決するためにメモリバリアというのがあるらしい。


サンプルプログラムでこんなのがあったんですよね。

long atomic_read(volatile long *ptr){
   long ret=*ptr;
   rmb();
   return ret; } void atomic_write(volatile long *ptr, long val){
   *ptr = val;
   wmb(); }

wmbはwrite memory barrierの略らしいから、

ここで確実にメモリライトされるのだろうとは直感的にわかった。

でも、rmbの意図がよくわからなかった。


前提として、CPUは依存関係のないリード・ライトの順番を入れ換えることがある。

REGX = SETTING_X;
REGX; //dummy read
read = REGY;

REGXにライトしてから、REGYをリードすることを期待しているが、

ダミーリードを挟まないとリード・ライトの順番が入れ替わることがあると。

シングルコアのシステムだとこういう工夫でなんとかできるのだが、

マルチコアのシステムでコア間の整合を取るには不十分だという。


そこでメモリバリアという仕組みがある。

wmbやrmbはメモリバリア命令を呼び出すマクロだが、具体的な内容は後で。

さっきのatomic_read, atomic_writeの用法はこんなのだった。

if(atomic_read(&state)==PENDING){
   something(somedata); }

これでstate変数をリードしてから、条件を満たす場合はsomething変数をリードするという意味になる。

atomic_read関数を使用しない、すなわちrmb()を挟まない場合、

state変数がPENDINGになる以前のsomething変数の値を使ってしまう可能性がある。

atomic_write(&state, PENDING);
IPI_TRIG = ipi_mask;

これでstate変数を他のコアに見えるようにライトしてから、IPI_TRIGへのライトをするという意味になる。

ここで言うIPI_TRIGへのライトは他コアに割り込みを発生させる意味である。

atomic_write関数を使用しない、すなわちwmb()を挟まない場合、

割り込みが飛んできてもstate=PENDINGのライトが反映されていない可能性がある。


で、ARMの場合、rmbとwmb、リード・ライト両方のメモリバリアmbは、

#define mb()         asm volatile("dsb"    : : : "memory")
#define rmb()        asm volatile("dsb ld" : : : "memory")
#define wmb()        asm volatile("dsb st" : : : "memory")

こんなインラインアセンブラで展開されるそうである。

dsb命令の前に重要なのがインラインアセンブラの最後の”memory”である。

破壊されるレジスタの一覧に”memory”と指定しているんですね。

これはコンパイラの最適化対策だそうで、これを挟んで命令の入れ替えが発生しないことを表している。

コンパイラが順番を入れ換えることを防ぐだけなら、これでいいらしい。

#define barrier()   asm volatile("" : : : "memory")

何の機械語もないインラインアセンブラである。

で、コンパイラが順番通り並べても、CPUがリード・ライトの順番を入れ換えてしまうことがあると。

それを防ぐためにdsb命令でリード・ライトの両方あるいは一方の完了まで待つ。


さっきのatomic_writeとatomic_readの使用例の組み合わせは少しおかしくて、

state変数へのライト→IPI_TRIGへのライトの順番は逆転しないが、

atomic_writeより前にあるライト→state変数へのライトは逆転の可能性がある。

atomic_readの使用例はstate変数のリード→somedata変数のリードの逆転を防ぐものなのに、

ライト側で逆転の可能性があるっていうのはどうなんだという話である。

割り込みをうけてatomic_readを実行するならば、ほぼ問題ないんだろうが、

厳密にはatomic_writeの前にwmbを置くべきなのだろう。


なかなかイメージがつかみにくい話ではあるんだけどね。

コア間での同期を考えないといけないシチュエーションではこういうのがあるという話だった。

Blogを書きながら勉強してると、これはおかしいかもと思うところはあれこれ。

そのあたりまた点検しないとな。

まいばすけっと に似ている

セブン&アイが「SIPストア」の実験店舗を開店するとのニュースがあった。

新コンセプト店舗「SIPストア」をオープン (セブン&アイホールディングス)

屋号はセブンイレブンだけど、一般的なセブンイレブンよりは大きいな。

で、スーパーのような生鮮品が並んでいる写真があり……

これ、まいばすけっと と同じような商売だね。


7&iはコンビニ(セブンイレブン)がほとんどの稼ぎを生み出す一方、

祖業であるイトーヨーカドーをはじめとするスーパーの収益率が低く、

株主からスーパー事業の売却をするように圧力を受けてきた。

コンビニ以外の事業という点では百貨店の そごう・西武 を昨年9月にフォートレスに売却している。

百貨店か疑わしいからストライキ

一方のスーパー事業は食品分野ではコンビニとの関係が深いということで、

直営の衣料品売場をやめたり、北海道・東北・信越の店舗は他社に譲渡しつつ、

大都市圏での食品スーパーとしては今後も続けていきたいと言っている。

イトーヨーカドーは、全国規模のGMSから主に関東圏の食品スーパーに変化することになるが、

セブンイレブンとイトーヨーカドーをともに経営するシナジーは大きく、

SIPストアはそれが現れたコンセプト店舗になるのだと言っていたのである。


で、これがSIPストアだということらしい。

SIPは「SEJ・IY・パートナーシップ」の略らしい。なんだそれは。

屋号がセブンイレブンであるようにコンビニとしては一人前である。

その上で食品スーパーとしての機能を備えているということになる。

生鮮品は絞り込んで配置、冷凍食品やチルド商品を多く備える。

日用品も一般的なコンビニに比較するとベビー用品を充実させたりしているよう。


で、冒頭にも書いたのだが、この商売は まいばすけっと によく似ている。

まいばすけっと はイオンが南関東で1000店舗以上展開するブランドである。

2005年に1号店ができ、2011年にイオンリテールから分社化している。

駐車場を備えない小型スーパーというのがイオンの他の業態と比べた特色か。

展開している地域は限られるが、一定地域では大量に展開しており、

例えばイトーヨーカドーの1号店(千住店)があった足立区には まいばすけっと は23店舗もある。

こういう状況からするとSIPストアは周回遅れにも思えるけど。


イトーヨーカドーを近畿・東海に中途半端に残した理由というのも、

これらの地域にもSIPストアのような店舗を展開する意図もあるのかも。

と思ったのだが、この観点でもイオンは先を行く。

まいばすけっと はイオン北海道が札幌でも42店舗展開している。

ダイエーが大阪市内で12店舗展開しているCoDeliも同様の業態である。

まいばすけっと と比較すると惣菜・弁当に強いような話は聞くが。

まだ店舗数は少なく、多くは既存の小型スーパーからの転換らしいが、芽はあるということで。


SIPストアの特色は食品というより非食品のような気がしたけど。

まいばすけっと はほぼ食品しか置いてませんからね。

ローソンストア100 も商売としては似ていて、食品以外もあるにはあるけど、

食品を優先していることは明らかで通常のローソンより手薄である。

日用品の細々した品揃えはセブンイレブンは得意そうだなと思う。

それと食品スーパーとしての機能が合わさると強いのかはわからないけど。


イトーヨーカドーが北海道・東北・信越の店舗を多く譲渡したのは、

売場を持て余す大型店舗が多かったという事情が大きいんじゃないかなと。

関東圏はダウンサイジングしながら食品スーパーに特化する道が見えた。

関東圏への集約というよりは脱GMSの一環と見るべきなのかもしれない。

正直なところ、イトーヨーカドーがここまで来てしまったことが残念だし、

効果的な手を打てなかったのもコンビニで儲かってたからなんだろうと。

それでもイトーヨーカドーを続ける理由の1つとして書かれていたSIPストアだが、

イオンではすでに20年ほど前からやっていたことだったというのは、

スーパーという商売への真剣味がないことを表しているかのようで、なおさら残念に思えた。

改札外で東西往来できない敦賀駅

北陸新幹線の当面の終着駅となる敦賀駅だが、こんな話を見た。

自由通路が唯一ない「敦賀駅」開業後どうする 米原駅にみる駅と再開発 (中日新聞)

敦賀駅の東西を結ぶ改札外の通路が設けられていないという話である。


線路を越える歩道橋などの通路を整備して、そこに改札口を集約するのは全国各地で行われている。

観点としてはバリアフリー対策、踏切対策が多い。

バリアフリー対策という観点では、近鉄の西大寺駅がその名目だった。

元々地下通路は存在したがバリアフリー化ができていなかった。

このため暫定対策として住民に通行証を発行して駅構内を通していた。

奈良市が南北を結ぶエレベーター完備の自由通路を整備し、そこに面して近鉄が改札口を移転・集約している。

踏切対策という観点では拝島駅がそうで、元々130mにも及ぶ長い踏切があったのだが、

安全面の問題が多々あり、自由通路整備後に踏切は廃止されている。


で、敦賀駅はどうなのかというと、元々駅付近で線路を横断する手段がない。

さらに言えば中心市街地の反対側の駅東側には今は改札すら存在しない。

新幹線開通に合わせて初めて東口が設置されるのである。

駅の東西を結ぶ通路が必要という話は昔から言われていたのだが、

実現しないままずっときて、新幹線開通で初めて駅構内の通路として実現したのである。

ただ、駅構内の通路なので列車を利用しない人は入場券を買わなければ通過できない。


なぜ、このようなことになったのか。

まず地図を見てみると敦賀駅の東側は主に工場で市街地ではない。

このため東側から駅を利用する需要や、駅の東西を往来する需要はあまり想定されていなかったようである。

敦賀駅はもともとホーム間を結ぶ地下道があったが、階段のみだった。

バリアフリー対応として橋上駅に作り替えて、東西を結ぶ通路にしようという案もあったそうだが、

当時は新幹線の計画が固まりきっておらず、バリアフリー対応を急ぐこともあり、

跨線橋を追加してそこにエレベータ・エスカレータを付けることにした。

結果としてはこの通路を延長して新幹線駅舎につなげる形になった。


新幹線駅舎は従来の駅舎より東側に作られることとなり、

駅舎と木ノ芽川の間、狭いがここに駐車場とロータリーが作られることに。

すなわち東口というのは駐車場や送迎で新幹線・特急を利用する人の利用を主に想定している。

東口を整備するにあたり東西を結ぶ通路の整備を改めて検討したようだが、

線路を何本もまたぎ300mにもわたる通路を整備すると50億円以上はかかる。

駅東側の状況を考えれば、それに見合った需要は見込めないだろうと。

バリアフリー対応として作った跨線橋を新幹線駅舎につないだわけである。


ところで敦賀駅は新幹線と在来線が東西に分かれていると単純には言えない。

なぜならば新幹線接続の在来線特急は新幹線の下に発着するからである。

あと、今どきの新幹線の駅には珍しく新幹線に直接出入りできる改札口はない。

市街地側の西口から新幹線だと当然在来線構内を通過するのだが、

東口にしても在来線特急コンコースへの改札口が設けられるだけである。

ここを通って新幹線はすぐ近くの乗換改札、普通列車は跨線橋へ向かうことになる。


逆に西口から新幹線・特急を利用する場合は跨線橋を通ることになる。

気になったのが西口のみどりの窓口が新幹線開通後はなくなること。

みどりの券売機プラスが設けられるのでオペレータ対応は可能ですが。

メインの改札口の窓口がなくなるというのも変な気がしたのだが、

ハピラインふくいお客様カウンター(定期券売場)が西口に設けられるためだそう。

改札業務自体は東西ともJR担当らしいんですけどね。

乗換口や東口にはみどりの窓口があるので、対応できなければ通行証をもらって窓口に行くんじゃないか。


というわけで新しい敦賀駅はたいへん難しい駅である。

東西の往来をできるだけしたくないという考えは当然あるはずで、

そうすると新幹線・特急利用者は東口に乗り付けるのが多くなるだろう。

通勤・通学以外の地元利用者の大半がそうなるのかもしれない。

それで東口利用者は増えるだろうが、西側と歩いて往来できる必要はないかもしれない。


ここまで駅構内の通路が効果的な駅も珍しいんじゃないかな。

高尾駅や逗子駅など定期入場券(入場券の定期券ってこと)が売られている駅はあるけど、

踏切・歩道橋・アンダーパスなど使っても歩けないほど遠くはないように思う。

ただ、敦賀駅については迂回ルートは2km近くあり、歩くには遠すぎる。

それならば入場券を買うかという話もあるが、入場1回で150円である。

すなわち往復すると300円なんだよね。通り抜け目的だとそうなるんだよ。


調査のために新幹線開通後しばらく東西連絡バスを運行するとのこと。

ただ、建設費に見合う効果はないという結論になるんじゃないかな。

そもそも新幹線駅舎ができた後からそういう通路を作れるのかという話で、

やるなら新幹線と一緒にやっておくべきだったと思うが、

それでもGOが出せなかっただけの理由はあるということだな。

39人ライブの座席不定チケット

今日は休暇を取っていたのだが、それは昨日出かけていたからである。

THE IDOLM@STER MILLION LIVE! 10thLIVE TOUR Act-4 MILLION THE@TER!!!!

ミリオンライブ史上初めて39人全員が揃うイベントである。

今まで半々に分けて2日で全員というのはあったんですけどね。

4thライブは3公演で全員と予告しておきながら、他の出演日の人もサプライズ登場し、

最終日は37人全員(当時)が揃うと思っていたら、病気のため1人休業で……

今回は最初から予告して実際に39人揃ったということですね。


そんなイベントのチケットをアソビストアプレミアム会員として申し込もうとしたら、

旧友から俺の分も申し込んでくれと言われて、2人分で申し込んだ。

2日目一本狙いも功を奏したか無事に当選した。

それで木曜日にチケットの発行が開始され、といっても電子チケットなのだが、

同行者のバンダイナムコIDを紐付けて、それぞれチケットが利用できるようになった。

で、チケットを見て思ったのは席番号が書いていないということ。

※座席番号・位置は、公演当日ご入場の際に入場口で発券される「座席券」にてご案内しますので、デジタルチケットには記載されておりません。

ASOBI TICKETという自社のチケットプラットフォームを立ち上げたのだが、

そういう機能を作り込んでいたということらしい。

転売対策なんだろうかな。座席を厳選する目的の転売って最近もあるんかね?


あと、これは旧友に言われて気づいたんだけど、

※スクリーンショットの表示ではご入場いただけませんが、万が一、大規模な電波障害等が発生した場合は、主催者よりスクリーンショットでのご入場をお知らせする場合もあります。
電波障害等に備えて、事前にデジタルチケットの表示をご確認いただき、スクリーンショットで必ず保存してください。

基本的にはスクリーンショットでは入場できないけど、緊急時に備えてスクリーンショットを撮影しておいてねと。

専用のアプリを使う場合、アプリにチケットをダウンロードしておけば、スタンドアロンで改札できる仕組みがあるが、

ASOBI TICKETはWebページでチケット情報を表示するだけなので、そうはいかない。

じゃあスクリーンショットでいいのかというと、基本的にはダメですよと。

彼の見立てではチケット画面上のアニメーションを認識しているのでは? と。

緊急時にはこの認識機能を切って対応できる仕組みがあるのだろう。


そんなこんなで会場のKアリーナへ。

アンパンマンミュージアム近くの横断歩道で車を通すために時々歩行者を止めるのだが、この列の長いこと。

入場口ではQRコードリーダーをスマートフォンの画面に近づけられると、

長い感熱紙が出てきて、ここに席番号が記載されていた。

今回の席はLEVEL3ということで、入場口と同じ階に入口がある。

ステージとの距離感はいい感じだが、左端に近かったので角度が気になるかも。

今回の様に出演者が多いと幅広のステージをフルに使うからいいけど。


ところでKアリーナは入場口が1箇所に集約されているが、

複数の入場口に分ける会場の場合はどうやって対応するんだろうね。

入場時まで座席を伏せるとしても入場口の場所はあらかじめ言う必要がある。

大雑把にアリーナとスタンドぐらいの区分はバレても仕方ないとするのか。

まだASOBI TICKETはそういう会場で適用された例はなさそうだが。


39人揃うならオリジナルメンバー揃って披露できるということで、

TVアニメのユニット曲を中心に、揃うならとあれこれ詰め込んだのと、

あとはソロ曲で、これはショートサイズだが2日で全員披露している。

このあたりは出演者にとって印象深い曲を選んだようである。

これを2日間に押し込むのはかなり欲張りだなというのが正直な感想である。

この人数を揃えるのが大変なのもあるけど、ステージに立つのも大変。

Kアリーナのステージの広さも生かした気合いの入った公演だったのでは。


ただ、詰め込みすぎたためか終演が21時半ごろとは遅すぎる。

公演時間が長かったという側面もあるが、開演が17:30と遅かったのもある。

開演時間というのはリハーサル時間とのトレードオフという面はある。

あと、Kアリーナの広さを考えてか開場は1時間半前で15時にしている。

出演者や演目の入れ替えが少なければ2日目は早くできたりするんですけど。

うまく詰めて30分、できれば1時間前倒しにできないもんかなと思うんだけどね。


さらにはKアリーナは退場にも時間がかかる。呼び出しまで30分ぐらい待機。

建物外に出るが建物外周をぐるっと回らされて、各出口からの人の流れが合流すると詰まり、

横浜駅方面とそれ以外に分かれると、そこから新高島駅までは近いが。

今回も新高島駅から電車に乗ったけど、前よりこのルートに流れる人は多かった。

Kアリーナに行って帰る

新高島駅で乗った各停がそのまま渋谷まで先着という意外な展開もあり、

渋谷に到着したのは23時を少し回ったところ。

そこから乗り換えて帰宅すると日付が変わってしまった。うーん……

休暇取って正解でしたね。こんなん翌日仕事にならんわ。


39人で使っても窮屈に感じさせない広いステージで、これぐらい見やすくて、

Kアリーナだからこそできた公演かなとは思うんですよね。

これで開演さえ早ければなぁ。

でも出演者の多さと開場の広さが開演を遅くしてしまっていると言われるとね。

SPFとDKIMだけで足りないDMARC

先日、DMARC対応の話を書いた。

送信と受信のDMARC対応

すでにSPFとDKIMに対応していればTXTレコード1つ足すだけだね、

とは書いたものの、実はSPF対応していても、場合によってはDKIM対応していても、

そのままではDMARC対応できないケースというのが存在するという。


メールの送信者にはFromとして表示されるヘッダーFromと、

メールサーバーが認識して不達時の連絡先(Return-Path)として利用されるエンベロープFromがある。

SPFは後者、エンベロープFromのドメインに対するなりすましチェックである。

例えば、Return-Pathが …@risonabank.co.jp なのに、同ドメインのTXTレコードに記載されていないサーバーから届いたらNGとすると。

ただ、一般的なメール受信者はReturn-PathではなくヘッダーFromを見る。

Return-PathとヘッダーFromは必ずしも一致している必要はない。

外部のメール送信サービスを利用する場合に一致しないことは珍しくない。

なのでReturn-Pathには自分が管理する適当なメールアドレスでSPFをPassさせて、

Fromになりすましたい会社や公的機関のメールアドレスを書く手法がありうるとは気づいていた。


DKIMについても似たような問題がある。

DKIMの場合はメールに付ける署名の公開鍵をDNSのTXTレコードに書いて、

署名を検証すればドメイン所有者の認めたサーバーから届いたことがわかる。

では、このドメインとは何なのかというと、DKIM-Signatureヘッダのdレコードに記載されたドメインである。

FromのアドレスのドメインとDKIM-Signatureヘッダのdレコードに書くドメインは当然一致していると思ったが、

外部のメール送信サービスが自社の公開鍵で署名する第三者署名というケースもあるらしい。

DKIMをそういう使い方をする理由はよくわからないのだが、DKIM=Passでもこのような場合はアテにならない。


DMARCはSPFとDKIMの両方がNGのメールの処理を規定するものだが、

DMARCでSPF=Passとなるためには、ヘッダーFromとエンベロープFrom(Return-Path)のドメインが一致してなければならない。

全く同じである必要はなく、標準設定ではサブドメインでもよい。

例えば Return-Pathが xxx@foo.example.com でSPF=Pass、

Fromが yyy@example.com であればDMARCはPassとなる。

DKIMも同様でDKIM-SignatureヘッダのdレコードとFromのドメインが一致していなければPassにならない。

こちらについては第三者署名は無効ですよと捉えればよいと思う。


外部のメール送信サービスを使っている場合には、ここを対応しなければDMARC対応とはならない。

例えば、Amazon SESではこのように対応できると書かれている。

Amazon SES の DMARC 認証プロトコルへの準拠 (AWS)

SPF対応については「カスタムの MAIL FROM ドメインを使用する」という対応をすればよいとある。

これは適当なサブドメインをAmazon SESのReturn-Path用に利用できる様にすると。

すなわち、従来はReturn-Pathを zzzz@amazonses.com としていたのを、

bar.example.com宛のメールはAmazon SESのサーバーで処理する設定をして、

かつ、同サブドメインのSPF設定にAmazon SESのサーバーを記載する。

その上でReturn-Pathを zzz@bar.example.com に変更してもらう。

こうすればFromに @example.com から始まる適当なメールアドレスを使えるようになる。

不達時の通知はAmazon SESで処理できるので従来と使い勝手は変わらない。


DKIM対応については3つの方法があると書かれている。

1つはAmazon SESの公開鍵を自分のドメインの公開鍵として公開する方法である。

これで、DKIM-Signatureヘッダのdレコードにそのドメインを指定して、

Amazon SESで持っている秘密鍵で署名できるようになる。

なるほど、その手があったかという感じである。確かにこれは簡単。

2つ目は自分で用意した鍵ペアの公開鍵をドメインで公開、秘密鍵をAmazon SESに支給する方法である。

僕は最初、この方法しかないと思っていた。もっとも素直な方法である。

3つ目はAmazon SESに送信依頼するメールにあらかじめDKIM-Signatureヘッダを付けておく方法。

この方法はエラーをAmazon SES側で検出できないから注意しろとはあるが、

DKIM-Signatureを任意に設定できるメールサーバーであれば、

メールサーバー側がDKIM対応してなくてもDKIM対応できる仕組みである。


ところでGmailでは大量にメール送信する人にSPFとDKIMの両対応を求めている。

DMARCではどちらか一方だけ対応していればOKなのに、なぜ両対応が必要なのか。

これはおそらく転送メールの都合ではないかと思う。

SPFは送信元のメールサーバーとReturn-Pathの一致を確認するが、

転送メールは他のサーバーから転送されてくるのでこれを満たせない。

一方のDKIMは元々Passしていたメールをそのまま転送すれば当然Passする。

大量送信すれば、そのうち一定割合は転送サービスで転送されてしまうだろう。

そうなったときSPFだけだとPassできなくなってしまう。

だからDKIMも付けて転送メールでもDMARCをPassできるようにしてね。

こういう趣旨なのではないかと思う。


じゃあ、逆にDKIMだけでDMARC対応してしまえという考えもありそうだが。

SPFでDMARC対応するにはReturn-PathとヘッダーFromのドメインを一致させる必要がある。

DKIMの場合はここが一致しなくてもFromとDKIM-Signatureのドメインが一致すればよい。

でも、実際はそういう例はあまり多くないのだろう。

Return-Pathのドメインを合わせるカスタマイズの方が結局は容易なのだろう。


ちなみにヘッダーFromとエンベロープFrom(Return-Path)の不一致については、

Gmailではこれまでも自主的に「xxxxx.xxx経由」という表示をしてきた。

これを表示する条件はDMARCのNG条件に似ていて、

ヘッダーFromとエンベロープFromのドメインが一致しなくて、

かつヘッダーFromのドメインでDKIMをPassしていない場合である。

DMARC対応となればエンベロープFromのドメインを一致させる方向に動いたと思うが、

それ以前はDKIMの導入で「xxxxx.xxx経由」の表示を消す考えもあったかもしれない。


今日、ちょうどSPFがPassでDMARCがFailとなるメールが届いたんですよね。

Return-Path: <amz@shxiudada.com>
DMARC-Filter: OpenDMARC Filter v1.4.2 hdmr.org 9CE2FDBA40
Authentication-Results: hdmr.org; dmarc=fail (p=quarantine dis=none) header.from=mastercard.com
Authentication-Results: hdmr.org; spf=pass smtp.mailfrom=shxiudada.com
From: "MasterCard" <info@mastercard.com>

Authentication-Resultを見るとspf=passとなっているが、

同ヘッダーには検証されたドメインの名前が書いてあるがヘッダーFromとはまるで一致しない。

なので、DMARCの判定においてはこの結果は利用しないということになる。

DKIMについてはそもそも署名なし。

その上でヘッダーFromのmastercard.comのDMARCポリシーは存在しているので、

DMARCの判定をして、SPF無効・DKIMなしで dmarc=failと判定。

p=quarantineと記載されているので、迷惑メールとして扱うのが相当とわかる。

導入早々わかりやすい例がきてDMARCの効果を確認出来た。

東武と他社が同居する駅たち

春を感じたいと思い観梅のため越生に出かけていた。

2021年にも来ているが、今回は往復ともバスを拾えた。

ただ、自家用車の影響か渋滞でノロノロ運転でしたね。

越生へ花見に行く

今回は入園料取られましたね。400円なり。

今年は暖かくなるのが早かったのでまさに満開。綺麗でしたね。


帰り道、寄居に寄り道して帰ってきた。特に目的があったわけではないが。

越生→寄居は本来はJR八高線だけで行けるのだが、

小川町止まりを引いたので、小川町→寄居は東武東上線に乗り換えて。

越生駅は東武とJRが同居する駅だが、こんな感じである。

東武・JRそれぞれのホームに自動改札機(JRはICのみ)・券売機が設置されていて、駅舎に見えたのは待合室と案内所でしかない。


八高線の汽車で2駅、小川町駅に到着、乗換まで時間があったので一旦外に出る。

通路にある改札機にタッチするようにと案内があったのでタッチして、

東武に直接乗り換える場合はどうなるんだろ? と思いながら改札に歩いて行くと、

出口には東武の自動改札機が並び、JRから来た人ももう一度タッチするようにと案内があった。

なるほど、ICカード利用者はJR→東武の乗換後に東武の出場をする仕組みなのか。

東武の券売機が並ぶ中にJR用の券売機(現金専用)が1台置かれていたが、

実はこの券売機は東武所有らしく、きっぷを買うと東武の用紙で出るらしい。


東武に乗って寄居駅に到着したが、ここも通路にある改札機にタッチするように案内がある。

さすがにこれは見逃さないだろうと通路の真ん中に鎮座していた。

この駅は秩父鉄道・東武・JRの3社が同居して1つの改札口を使う。

現在は3社ともICカードを導入しており、多くの利用者がICカードを使う。

そのような実情に合わせて3路線の通路が分かれた先にICカード専用の自動改札機が置かれている。

秩父鉄道はホームに設置されているようだね。

相互に乗り換えて利用する人もいるが、出場→入場とタッチすればよい。


多くの利用者が通路にある改札機にICカードをタッチして使うこともあり、

係員のいる改札口は実態としてフリーパスである。

紙のきっぷはここで渡すんだろうけど、ほとんどICカード利用だからか駅員も立ち番をしてなかった。

実は秩父鉄道のICカード対応以前は小川町駅の逆で、改札口にはJRの改札機(ICカード専用)が置かれ、

ICカードで東武を利用する人は JRの改札機と通路にある改札機を2回タッチする仕組みだったらしい。

この頃は改札係もそこそこ見てたんだろうけどね。

改札外には3社の券売機が並んでいるが、ICカードのチャージはJRの券売機のみ対応している。

秩父鉄道の券売機がいかにも古くさいからかICカード導入からまもないからか、

「秩父鉄道全線で交通系ICカード使えます」と強調されていた。


東武って他社と同居する駅多いよねと思った。

直通運転絡みを除いて他社と改札内で同居している駅としては、

東上線では小川町・寄居、東武線では北千住(JR:千代田線・常磐線快速の乗換の都合)・相老(わたらせ渓谷鉄道)・赤城(上毛電鉄)とあるが、

越生駅もかつて同居していたし、東武線でも伊勢崎駅もJRと同居していた。

紙のきっぷでは自動改札機を設置せず対応してきた駅もICカードとなればそうもいかない。


帰りは森林公園駅から「川越特急」に乗換。

運賃のみで利用できる列車だがTJライナー用の車両を使っている。

川越特急という名前だが、池袋~川越の停車駅は快速急行より1駅少ないだけ。

どちらかというと停車駅の差が大きいのは川越~東松山なんですよね。

快速急行は副都心線直通がメイン、川越特急は池袋発着という違いはあるが。

川越特急という命名は西武の特急「小江戸」(こちらは有料)を意識してるんだろうな。

送信と受信のDMARC対応

Y!mobileからMMSでDMARCによるなりすましメールの対策を導入すると来ていて、

これ自体は特に問題はないが、そういえば自分のメールサーバーはどうだっけと。

Yahoo!メールヘルプ/DMARCとは (Yahoo!)

すでにSPFもDKIMも導入しているから設定を加えればOKですね。


そもそもSPFとDKIMも含めたわかりやすい説明はここに書いてある。

ドメイン認証技術「DMARC」について (Yahoo!)

DMARCはSPF, DKIMの判定でNGとなったメールの処理方法を決めることを主目的としている。

だから、基礎としてSPFまたはDKIMを導入していれば、処理方法を記載するだけでよい。

SPFとDKIMで迷惑メールよけ

SPFは送信するメールサーバーをDNSのTXTレコードに記載する方法。

MXレコードのサーバー以外から届いた場合は怪しい(softfail)という記載例を書いている。

特に送り側のメールサーバーには細工がいらないのでかなり普及している。

DKIMは電子署名を付けて送信し、DNSのTXTレコードに記載した公開鍵で検証できるようにする。


今までこれらの技術でNGとなったメールの扱いは不明瞭なところがあった。

DKIMについてはADSPというNG時の動作を決める仕組みがあったが、廃止されている。

で、Gmailに大量送信するメールサーバーについては、DMARCへの対応が要求されている。

大手の送信ドメイン認証「DMARC」導入率が8割超に、Gmailのガイドラインが奏功 (日経XTECH)

SPFとDKIMの両方を導入した上でDMARCに対応することが求められている。


というわけで、僕の場合は、DNSに下記の設定をするだけで済む。

_dmarc                  TXT     "v=DMARC1; p=reject"

p=rejectはSPFもDKIMもダメなら拒否してねという意味になる。

すでにSPF, DKIMともに実績が十分あるのでこの設定だが、rejectはあまり一般的ではないかも。

Yahoo!メールのヘルプにも書いてあるのだが、p=quarantineで迷惑メールに分類の意味で、これが一般的である。

p=noneにするとそのまま受信してという意味にはなるのだが、

その場合はなりすまし対策に弱いドメインとみなされ、結果として迷惑メールに分類されやすくなる場合があるという。

そういう意味では最低でもSPFは導入した上で、p=quarantineでDMARCを導入するとよさそうだ。


DMARCにはもう1つ目的があって、それがレポート機能である。

受信サーバー側で当該ドメインからのメールの判定結果を送ってくれる。

上記の設定に rua=mailto:… を書き加えると、統計データが送られてくる。

DMARCでは設定必須なのかと思ったのだが、必須というわけではない。

送られてきても使い道がないと思えば書かなくてもよい。

ただ、これを受け取ることでなりすましメールの実情を知ることが出来る。


さて、これでGmailとかYahoo!メールに送って届いたメールのヘッダを見る。

Authentication-Results: mx.google.com;
        dkim=pass header.i=@hdmr.org header.s=xxxx header.b=XXXXXXX;
        spf=pass (google.com: domain of h@hdmr.org designates xxx.xxx.xxx.xxx as permitted sender) smtp.mailfrom=xxxxx@hdmr.org;
        dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=hdmr.org

dkim=pass, spf=pass, dmarc=pass ということで合格ですね。

DMARCの設定をする以前はdmarc=passが付かなかったはず。


逆に受信側なのだが、OpenDMARCを導入してみた。

もともとpolicyd-spfを導入していたのを、OpenDMARCでSPFとDMARCの判定をする形に改めた。

なお、OpenDKIMについてはDKIMの署名・判定のために併用する。

送信メールについてはOpenDKIMで署名→OpenDMARCでは何もせず、

受信メールについてはOpenDKIMで署名検証→OpenDMARCではSPF判定、DKIM・SPFの結果を総合してDMARCの結果を記載という流れになる。


OpenDMARCは/etc/opendmarc.confで設定するが、

IgnoreMailFrom hdmr.org
RejectFailures false
SPFIgnoreResults true
SPFSelfValidate true

IgnoreMailFromで自分のドメインを書かないと、これから送信するメールを検証してしまう。

RejectFailuresは標準でfalseだが念のため。こう書くとp=rejectでも受信する。

後で書くのだが端的に言えばDMARCには期待していないということである。

SPFIgnoreResults, SPFSelfValidateはOpenDMARCでSPFの検証を行うための設定。

これをした上で従来のpolicyd-spfの設定を削除することとする。


で、これをPostfixに設定するわけだが、OpenDKIM→OpenDMARCの順にmiltersに記載すればよい。

smtpd_milters = unix:/run/opendkim/opendkim.sock,
unix:/run/opendmarc/opendmarc.sock
non_smtpd_milters = $smtpd_milters

ただ、Permission deniedのエラーが出てしまう。

これはpostfixユーザーにsockファイルのアクセス権がないのが原因で、

opendkimグループとopendmarcグループにpostfixユーザーを参加させればよい。

# usermod -aG opendkim postfix
# usermod -aG opendmarc postfix

これでDMARCの判定が適切に行われる。

DMARC-Filter: OpenDMARC Filter v1.4.2 hdmr.org 1BBC5DBA40
Authentication-Results: hdmr.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: hdmr.org; spf=pass smtp.mailfrom=gmail.com
DKIM-Filter: OpenDKIM Filter v2.11.0 hdmr.org 1BBC5DBA40
Authentication-Results: hdmr.org;
     dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=....

3つのAuthentication-Resultsヘッダで書かれるんだな。

このAuthentication-Resultsのdmarc=pass または dmarc=fail を見て、

マーキングやフォルダ振り分けなど行うことが出来るわけである。

とりあえずはThunderbirdでdmarcの結果によってタグを付けるようにした。

(元々SPFとDKIMの結果でタグを付けるようにしていたのを変更した)


ただ、これが迷惑メール対策として効果的なのかはよくわからない。

というのもSPFもDKIMも他人のドメインへのなりすまし対策であって、

ドメインをなりすました迷惑メールというのはそう多くない印象である。

昔はSPFもDKIMもNGなら迷惑メールに分類する対策をしていたが、

迷惑メールでもない誤設定のためかメールがNGになる割には、迷惑メールがOKとなることも多く不便だった。

このためマーキングに留めるようにしたのである。

最近はGmailがDMARC対応を求めたためかNGになるメールは減りましたが。


なぜあまり効果的ではないのかという話だが、ドメインのなりすましがそう多くないからである。

例えば、最近は りそな銀行 へのなりすましメールが何通か届いたが、

risonabank.co.jpから送信したように見せようとはしてないんですよね。

自分で取得した適当なドメインにSPF・DKIM・DMARCの設定をした上で送ってきているのである。

そしたらそのドメインでSPF・DKIM・DMARCが全てPASSになってしまう。

確かにドメインをりそな銀行に偽装はしていないのだが、

タイトルや本文でりそな銀行から送ったように見せていれば、それは立派ななりすましメールですよね。

こういうことがあるのでメールは注意して見なければならないのだが、

結果としてSPF・DKIM・DMARCはこのタイプのなりすましメールの対策にはなっていないのである。


各所で迷惑メール対策が進む中で、行儀のよい迷惑メールが増えた印象で、

こうするとなかなか正当なメールとの識別が難しいのが実情である。

Gmailが大量にメールを送るところにDMARC対応を求めたのは、

迷惑メールの報告が少なく信頼できるドメインを明確にするためなのではないか。

  • xxx.exampleからのメールは迷惑メールの報告が少ないがDMARC非対応
  • yyy.exampleからのメールは迷惑メールの報告が多いがDMARC対応
  • zzz.exampleからのメールは迷惑メールの報告が少なくDMARC対応

yyy.exampleのような迷惑メールの報告が多いドメインは、DMARCの有無によらず迷惑メールへの分類を進める。

xxx.exampleは今は迷惑メールの報告は少ないが、DMARC非対応だとなりすましが容易である。

すなわち迷惑メールの温床になる危険があるのでやめてくれと言っている。

zzz.exampleのような迷惑メールの報告が少なくDMARC対応となっていれば、

DMARCがpassであれば迷惑メールの可能性は低く信頼度が高い。

DMARCがfailになれば なりすまし で迷惑メールと判断できる。


Gmailのような大量のメールが届く事業者ならこういう対策もあるだろうけど、

ビッグデータなしにDMARCを迷惑メール対策に使うのは難しいのかなと。

DMARCがfailする迷惑メールがたくさん届くなら考えるんだけど、全然来ませんからね。

それでも何か役に立つかもしれないとマーキングだけはしていると。

2500m戦が1400m戦になる

「距離短縮」がトレンドに入っていて、何のことかと思って見てみると、

笠松競馬場で行われている地方全国交流の重賞「オグリキャップ記念」が、

昨年までの2500mであったところ、今年から1400mに短縮されるとの報だった。

令和6年度笠松競馬 重賞・準重賞競走について (笠松けいば)

それはもはや別のレースだろと思うわけだが、いろいろな事情が絡み合っての大幅短縮となったようだ。


ところで笠松はダートグレード競走を開催していない地方競馬主催者である。

ばんえい競馬のみ実施する帯広市を除けば唯一である。

(金沢競馬は開催ごとに石川県主催と金沢市主催が変わるが、これを1つとみなした場合)

かつてはオグリキャップ記念がそうだったのだが、賞金を出せないため返上、

以後は地方全国交流競走でやってきたという経緯がある。

ただ、最近は笠松競馬の経営状況も改善し、オグリキャップ記念の1着賞金は2000万円まで引き上げられた。

JpnIIIのダートグレード競走よりちょっと安い程度まで来たのである。


オグリキャップ記念の大幅短縮にはダートグレード競走復活も意識したようだが、

それ以上に問題だったのは名古屋競馬場のダートグレード競走の変更だった。

名古屋競馬では年3回のダートグレード競走を開催してきたが、

「全日本的なダート競走の体系整備」で3レースとも入れ替えになることに。

  • 名古屋グランプリ(JpnII・2100m) 12月上旬→5月上旬
  • かきつばた記念(JpnIII・1500m) 5月上旬→3月上旬(2月下旬)
    • 負担重量はハンデキャップ→グレード別定
  • 名古屋大賞典(JpnIII・2000m) 3月上旬→12月下旬
    • 負担重量はグレード別定→ハンデキャップ

全国的なダートグレード競走の実施時期の調整でこうなったのだが、

もっとも問題だったのが名古屋グランプリと東京大賞典の時期が近いことである。


元々、名古屋グランプリと東京大賞典が近いのはそうだったのだが、

これが殊更に問題となったのは名古屋競馬場の弥富トレーニングセンターへの移転である。

移転時にコースの都合で2500m→2100mの距離変更が行われた。

元々ダートグレード競走最長だったが、移転後はダイオライト記念(2400m)が最長となった。

そして、距離短縮により東京大賞典(2000m)やチャンピオンズカップ(1800m)との差が小さくなった。

このような時期に同距離のJpnIIのような格の高いレースをやるのは不適と。

こういう判断になるのは当然のことである。


それで、川崎記念(1月→4月に変更)と帝王賞(6月)の中間に移設となったと。

G1級レースの前哨戦としての意味を持つようになった。

これは元々かきつばた記念を行っていた時期なのでこれも移設となった。

で、年間のダートグレード競走のスケジュールを見たとき、上半期は古馬1500m以下の重賞が手薄となっている。

このため元々の名古屋大賞典の時期ぐらいに移設するのがよいとなったのではないか。

こうして押し出された名古屋大賞典は元々名古屋グランプリをやっていた12月に。

ハンデ戦にすることで同時期のG1級レースとのすみ分けを狙ったのではないか。

(地元馬が軽ハンデで出走しやすいという意図もあるのかもしれない)


で、笠松の話に戻ると、名古屋グランプリとオグリキャップ記念が同時期になった。

同じ東海地区で2100m(元2500m)と2500mでドン被りである。

いくら地方所属馬限定の重賞とは言え、これでは厳しい。

そこで目を付けたのが上半期に1500m以下のダートグレード競走が手薄なことである。

今年からJpnI格付けとなる さきたま杯(1400m)の前哨戦という名目も付く。

全日本的なダート競走の体系整備に資するものならば、早々Jpnグレードが付く可能性はある。

(例えば、ブルーバードカップは羽田盃の前哨戦として南関東準重賞→JpnIIIになっている)

一方で、2500m戦自体は何らかやりたいという意図もあったようで、

年末の東海ゴールドカップを1900m→2500mに変更、

回り回って元々の名古屋グランプリに近い時期に2500m戦が復活した。

ただ、こちらは東海地区のローカル重賞なんですけどね。


2500mの地方全国交流競走がいきなりなくなる影響はけっこう大きい。

折しも兵庫でも六甲盃(地方全国交流)が2400m→1870mに短縮となる。

ご当地ダービーはなくならない

こちらも1400mの重賞が手薄という課題があり、

兵庫大賞典を1870m→1400mに短縮し、さきたま杯に転戦可能とした。

この影響で園田唯一の2400m戦、六甲盃は1870mに短縮されることに。

帝王賞の前哨戦としてはこちらの方が適しているとも言える。


というわけで、いずれもそれなりの理由があっての変更なのだが、

結果としてダート2100m超の重賞は急激に減少している。

世界的に見てもかなり少ない区分ではあるんですけどね。

JRAでもダート2100m超は2勝クラス以下の条件戦しかない。

ダートグレード競走ではダイオライト記念が唯一となっているが、

地方全国交流競走も 東京記念(2400m・9月上旬)、北國王冠(2600m・11月上旬) の2レースだけかね。

地元限定のローカル重賞ではいくつかありますが。

しかしそれもダイオライト記念(3月上旬)~東京記念の間にはないかなぁ。

ちょうどこの期間にあった2レースがごっそり抜けたので影響は大きい。


以前も書いたのだけど、

新しいダート三冠を考えるにあたり、菊花賞(芝3000m)やベルモントステークスのことは意識したと思うが、

前身となったレースの距離を継承し、1800m・2000m・2000mとなった。

大井競馬場のコースを考えると2000mより長いのは2600mになる。

(2400mも可能だが、スタート~コーナーが近いので好ましくない)

結局のところ2100m超で全国チャンピオンを競う場がないんですよね。

そうである以上は2100m超のレースは全国的にも淘汰されるんだろうな。

芝については3000m級のレースは少ないながらに年間通じて設定されているが、

これは菊花賞と天皇賞(春)でG1が年2回あるのが大きいんですよね。

ダートはそうなっていないし、今後もそうならないのだろう。


なお、東海地区についてもダービーは名称変更して存続している。

東海ダービーあらため東海優駿、1971年の第1回に使っていた名称に戻る。

(第2回から東海ダービー、名古屋優駿の副名称が東海ダービーの時代もあった)

時期は東京ダービーとほぼ同時期である。ってそれはどうなんだ。

兵庫ダービーあらため兵庫優駿は、東京ダービー後に転戦できる時期にずらしたんですよね。

そういう転戦が現実的なのかという話はあるんですけどね。

無断でゆうパケットに変更していいのか

先日、発売まもない雑誌を中古でメルカリで購入した。

「即日発送」と書いてあり、大阪府から「らくらくメルカリ便」とある。

大阪府~東京都はゆうパケットだと翌々日になることも多いのだが、

ネコポスなら翌日着で、注文したのが昼頃なら当日便に乗る可能性もまぁある。

そんな期待も持って注文した。明日着は過度な期待だとは思ってたけど。


ただ、注文した日のうちには発送通知が来なかった。

翌日、発送通知が来たのだが、発送手段がゆうパケットになっていた。

すなわち らくらくメルカリ便→ゆうゆうメルカリ便 に変更したということである。

発送場所は郵便局、窓口しかない郵便局だから追跡情報の登録が遅れたわけではないだろう。

というわけで想定とかなり異なる発送だった。

発送翌日、すなわち注文翌々日の到着なので十分早いんだけどね。


ネコポス→ゆうパケットの変更と見て、心当たりはあった。

ネコポスの寸法規定は厳しい

この雑誌、変形判で横幅がネコポスの規定を超過してしまうのである。

角2封筒には入るけど、ネコポスの寸法を満たすところまで折れないと。

メルカリの匿名配送の料金設定の都合、ネコポスを発送手段に選ぶ人は多いが、

この寸法規定の厳しさというのを意識して選ぶのは面倒である。

僕は2022年6月の料金改定時以降、多くはクリックポストを使用している。

メルカリの送料が上がるのは経営難だから?

安いというのはあるけど、寸法規定で悩まなくてよいのも理由である。

(まとめ売りのときに1kgの重量制限を意識することはある)


で、取引開始後の発送方法の変更は認められてはいるのだが、

当然のことながら取引相手の承諾を得て変更するべきである。

重量制限がゆるくて助かった

これはメルカリじゃなくてヤフオクの話なんですけど。

匿名配送のゆうパケットから承諾を得てレターパックライトに変更した話。

元が匿名配送なので住所を教えてもらった上で変更をしている。


メルカリでは匿名配送同士の変更をすることもできる。

ネコポス と ゆうパケット の差を気にする人は少ないだろうから、

決済後に寸法を満たさないことに気づいたので変更したが、

この変更で承諾を得る必要があるという意識はなかったのだろう。

「即日発送」が守られなかったのも急遽ゆうパケットに変更した影響かも。

これも一報あってもよかったと思うのだが。


このあたり煩雑に思ったか、なんでも発送方法「未定」で出品する人もいる。

問題はこの商品が6000円ほどと高価で、発送方法が「未定」で登録されていたこと。

というわけで質問したところ、郵便局(ゆうゆうメルカリ便)かヤマト(らくらくメルカリ便)が決めていないということだった。

ああ、なるほど。それで「未定」だったんですか。

本当はどちらか適当に決めてくれた方がいいのだが、理由は理解できるのでそのまま購入手続きをした。

(未定は匿名配送にはならない)

ただ、この場合は匿名配送にならないという欠点もある。


ところでヤマト運輸は2024年度末までにネコポスの提供をやめると発表している。

現在は発送元の地域ごとに クロネコDM便・ネコポス から クロネコゆうメール・クロネコゆうパケット への切替をしているところである。

ただし、メルカリなどの個人間取引のネコポスは全国的に継続している。

具体的にどのような対応になるかはまだ発表されていない。

他のプラットフォームと比較してもメルカリは特にネコポス利用者が多い。

ヤマト運輸にとってもメルカリのネコポスが一掃されないと楽にならないだろうし。

一体どうなるんでしょうね。僕はもうネコポス使わないだろうけど。

wfi命令で割り込みを待つ意味

今まであまり使うことがなかったのがマイコンのスリープ機能である。

低消費電力化が求められるシステムなら当然使うんだろうけど。

割り込みが来るまで処理を止めるという話ですね。


で、ARMの場合、wfi命令というのが用意されている。

この命令を実行すれば割り込みが来るまでお休みになる。

while(1){
   if(flag==0){
     __asm("wfi");
   }
   if(flag==1){
    ...

割り込み処理でflag変数に何か入るまでループで待つというのを、

flag変数が0ならばwfi命令を実行して、割り込みが入るまでスリープ状体でお休みと。

wfi命令とif(flag==1)の間で割り込みが実行されることを期待しているわけだ。


でも、if(flag==0)とwfi命令の間に割り込みが入ったらどうするのだろう?

ここでは省略したのだが、実際のコードではこの間にUARTの受信割り込みを有効化するための処理が入っている。

フラグを見て直後にwfi命令を実行していると言い切れない部分もある。

そんなわけでwfi命令の使用例を調べてみると、こんなアセンブラコードが見つかった。

cpsid i /* 割り込みマスク */
mov r4, #0
msr basepri, r4 /* 全割り込み許可 */ wfi
cpsie i /* 割り込み受付 */

wfi命令は割り込み待ちの命令だが、その直前に割り込みマスクをして、

それでwfiを出たら割り込み受付をするという書き方である。


これを見てもわかるのだが、wfi命令というのは割り込み待ちが発生した時点で解除される。

なので割り込みマスク状態で動かしてもOKなんですね。

むしろそのように書くことでwfi命令に入るまでに割り込みが消化されてしまうリスクがなくなる。

というわけで、さっきのflag==0ならwfiで割り込み待ちというのは、

while(1){
   __asm("cpsid i");
   if(flag==0){
     __asm("wfi");
   }
   __asm("cpsie i");
   if(flag==1){
    ...

と書くとよい。

こうすればif(flag==0)とwfi命令の間に割り込まれる心配がなくなる。


このあたり厳密にやらなくてもだいたい動いてしまうんですけどね。

さっきのアセンブラコードの場合、wfi命令の前に割り込み優先度の操作をしている。

このため割り込み優先度の操作をした途端に割り込まれる可能性がある。

なので、一旦割り込み禁止にして、優先度を変えているんですね。

で、優先度を変えたことで割り込み待ちになればwfi命令は即抜けになる。

割り込みマスクを解除したときに割り込み処理が走るというわけ。


このコードを見る前から割り込みマスク中でもwfi命令から抜けるらしい、

という話は見ていて、一体何のためにそうなってるんだろうと思ったら、

こういう使い方をするためだったんですね。

もちろん割り込み有効状態でwfi命令を使っても、それはそれで動くのだが、

割り込みマスク状態で使って、wfi命令を抜けたら割り込みマスクを解除するという動きの方がより正確な動きのようである。


あと、これは特に関係ないが、wfi命令を検索するとwfe命令のことがひっかかる。

割り込みが発生するまでスリープするという目的ではwfi命令を使うのだが、

wfe命令というのは他のコアでsev命令が実行されるまで待つことを目的としている。

wfeは”Wait For Event”、sevは”Set Event”で一対の命令である。

ある変数が書き換わるまでポーリングするという処理をするのに、

wfe命令で待って、他コアで書き換えたらsev命令を実行するような使い方をするらしい。

    sevl
1:  wfe
    ldr r0, [r1]
    cbz r0, 1b

sevl命令は他コアでsev命令が実行されてなくても、次のwfe命令は抜けるという意味になる。

(sevlは”Set Event Locally”の意味で、自コアだけイベントをセットする意味)

1回はr1レジスタのアドレスに格納されたフラグをチェックして、

そのフラグが0ならばwfe命令に戻って待つという記述である。

で、この間に割り込みが入るか、他コアでsev命令が実行されればwfe命令を抜けると。

割り込みが入るまで待つという部分はwfi命令とも共通するのだが、使用目的が異なる。

他コアからのフラグをポーリングしている間でも割り込みは入らないと困るから抜けるだけである。

これは使わなさそうな感じがするが、そういうのあるという余談である。