FMP3のupdate_schedtsk_dsp()で呼び出しているmemory_barrier()の必要性について

[fxycw360]

FMP3を利用してSMP対応RTOSのしくみを調査している者です。

update_schedtsk_dsp()の中で、p_pcb->p_schedtsk へアクセスするところでバリアを挿入していますが（下記342行）、これの必要性が理解できません。

[kernel/task.h]

 336 update_schedtsk_dsp(PCB *p_my_pcb, PCB *p_pcb, TCB *p_new_schedtsk)
 337 {
 338         TCB             *p_prev_schedtsk;
 339
 340         if (p_pcb->dspflg) {
 341                 p_prev_schedtsk = p_pcb->p_schedtsk;
 342                 memory_barrier();
 343                 p_pcb->p_schedtsk = p_new_schedtsk;
 344                 if ((p_pcb != p_my_pcb) && (p_prev_schedtsk != p_pcb->p_schedtsk)) {
 345                         request_dispatch_prc(p_pcb->prcid);
 346                 }
 347         }
 348 }

カーネル全体の中で、p_schedtskへアクセスしている箇所は多々ありますが、ほとんど（update_schedtsk_dspも）は giant_lock 取得状態でアクセスしており、バリアは不要だと考えています（コア間のアクセス競合が起きないので）。

core_support.S の dispatcher_0 にて giant_lock 未取得の状態で p_schedtsk を参照しているので、おそらくは dispatcher_0 における参照と、update_schedtsk_dsp() でのアクセスが競合（たとえば、コア0が dispatcher_0 を実行、コア1がupdate_schedtsk_dsp() を実行し、p_pcb-> p_schedtsk へのアクセスが競合する）した時のために当該バリアが必要なんだろうと想像していますが、これ以上のことがわかりません。

当該バリアは「不具合対策」として v3.2.0 で追加になったものであることはversion.txtを見て承知しています（だから絶対に必要なバリアなのでしょうが自分には理解できずに悩んでいます）。

ご多用中恐れ入りますがSMP初心者にわかりやすく当該バリアの必要性をご教示願えないでしょうか。
なおバリア命令についてはARMのマニュアルや一般的な文献を読んで一応は理解して（いるつもりで）おります。

fxycw360

[hiroakitakada]

3年前に修正した箇所ですので，すぐに状況を思い出せないのですが，hrmp3カーネルのdoc/hrmp3_design_memo.txtの「プロセッサ管理ブロック（PCB）」の節の(2-3)に理由が書いてあります。まず，これを読んでいただいて，疑問が残るようでしたら，再度ご質問ください。

[fxycw360]

ご教示ありがとうございます。
(2-3)を読んで納得いたしました（(2-3)(a)は自分でもわかっていましたが(2-3)(b)には考えが及んでいませんでした）。
SMPはしびれますね。

fxycw360

[hiroakitakada]

はい。マルチコアは難しいです。