Mechanized Proof for Article: "Revamping Hardware Persistency Models: View-Based and Axiomatic Persistency Models for Intel-x86 and Armv8" (PLDI 2021)
Home Page: https://cp.kaist.ac.kr/pmem
License: BSD 2-Clause "Simplified" License
po자명
이미 증명되어 있음
po \/ rf = po \/ rfepo \/ rf
= po \/ rfi \/ rfe (<- rf = rfi \/ rfe)
= po \/ rfe (<- 모든 rfi는 po다)
po \/ rfpo \/ rf = po \/ rfe 이므로 acyclic po \/ rf <-> acyclic po \/ rfepo 이므로 만약 사이클이 있다면 반드시 rfe가 경로에 있어야 함rfe--> Rx 로 놓자.rfe--> Rx; [P]; Wy --rfe--> Ry --po--> Wx 로 이루어져 있어야 한다.po | [P]; W; rfe; R; potso다. induction [P] !!
Rx; po; Wy : dob이므로 tso다.Rx; [Pk]; W; rfe; R; po; Wy
W; rfe; R 은 obs다R; po; Wy 은 dob다Rx; [Pk]; W; obs; R; dob; Wy이므로 tso다rfe--> Rx --tso--> Wy --rfe--> Ry --po(dob)--> Wx 이다.spurious failure를 허용해야 하기 때문
둘 중 뭐가 의도인지 인텔 사람에게 물어보기:
Figure 11 (Axiom-PARMv8)의 fl relation 정의에 대한 질문 드립니다.
(dc.cvap가 FO event를 내는 것으로 이해하였는데 혹시 아니라면 알려주시기 바랍니다.)
fl = [W ∩ D]; (ob+ ∩ CL); [FO]; ob+; po; [dsb.sy]
EX: x = 1; dc.cvap; dsb.sy
현재 fl은 위와 같이 정의되어 있는데요, 지금의 정의를 따르면 EX의 dsb.sy가 실행되었다고 해도 x = 1이 persist할 필요가 없는 것으로 보입니다.
pob에 [FO]; po; [dsb.sy]가 추가하고 fl을 아래와 같이 수정해야 하는 것은 아닌지 궁금합니다.
fl = [W ∩ D]; (ob+ ∩ CL); [FO]; ob+; po?; [dsb.sy]
추가로 dsb.sy 외에 FO와 order를 갖는 dsb는 없나요?
제 생각에 pob는 그대로 놔두고 fl = [W ∩ D]; (ob+ ∩ CL); [FO]; ob*; po?; [dsb.sy]로 바꾸는게 어떨까 합니다. (뒤 ob+ -> ob*).
아마 증명 어딘가에서 틀렸을텐데 위와 같이 바꾸면 다시 증명도 맞을 것입니다.
pob를 그대로 놔두고 싶은 이유는 fence를 ob에서 빼고싶기 때문입니다. Promising-ARM/RISC-V에서처럼... Fence가 오더에 들어가면 더 복잡해지는 것 같아서요.
dsb.sy 외에 가령 dsb.st가 FO와 order를 갖지 않나 추측하긴 합니다만, 명확하진 않습니다.
Viktor paper에서는 dsb.sy만 다루었고 ("DSB_full" in their paper), ARM reference manual에서도 별다른 논의가 없는데요,
나중에 ARM 엔지니어에게 물어보는게 좋을 것 같습니다.
snu-sf/promising-coq? snu-sf/?? 찾아서 lib/Basics.v 이런데 넣고
admit 모두 "myadmit" ...
Admitted -> Qed
일단은 간단히만....
모든 A의 행동에 대해 이에 대응하는 어떤 P의 행동이 있다는 것을 증명
v(eids) : eids.map(view_of_eid).fold(U, ㅗ) )vrn, vwo, coh 등에 컨트리뷰트하는 axiomatic 시퀸스를 정의.
.
.
AtoP를 거꾸로?
#29 와 어느정도 연관이 있는 이슈
우선 promising tso에서는,
(R) 모든 read와 rmw는 바로바로 vrn을 갱신해준다.
(W) 모든 write와 rmw는 무조건 t에다가 쓴다.
한편 기존 promising arm에서는 vro와 vwo는 barrier를 통해 vrn과 vwn을 갱신하여 준다.
그러나 promising tso에서는 barrier가 오직 wr일 때에만 유효하다.
때문에 아래의 두 뷰는 이러이러한 이유로 필요하지 않은 것 같다:
vro가 vrn에게 전해줄 게 없다.vro가 vwn에게 전해줄 게 없다.write와 rmw이 딱히 preview를 필요로 하지 않기에 vwn을 사용하지 않는다.기존 코드(TsoPromising.v)에서 vro와 vwn을 빼도 증명은 잘 됩니다.
https://github.com/kaist-cp/promising-hw/blob/master/src/axiomatic/TsoAxiomatic.v#L622
현재 dob는
read;po;access \/ access;po;write 으로 정의되어 있는데
read;po;read \/ access;po;write 으로 좁혀도 무방하지 않을까 싶습니다. (아니면 바꾼다한들 별로 의미가 없을까요?)
promising arm(A.3-FENCE) 논문에 의하면 risk-v에서
fence.tso = fenceR,R ; fenceRW ,W
로 정의되어있다고 합니다.
nvo 증명에서 인터리빙을 없애기 위해서 필요할 수 있음
T1
x = 1 // (1.1)
r1 = x // (1.2)
r2 = y // (1.3)T2
y = 1 // (2.1)
r3 = y // (2.2)
r4 = x // (2.3)behavior
r2 = r4 = 0rfi <= tso라면,
fr-> (2.1), (2.3) -fr-> (1.1) 사이에 tso가 있다. (fr <= obs <= ob= tso)local = { cow, view } // cow = forward bank
cow: loc -> option Time
view: Time
(READ)
(cow1 X).unwrap <= ts
latest X ts view1 mem1
view2 = cow1 X == Some ts ? view1 : view1 U ts
---------------------
{ cow1, view1, mem1 } -(read X ts)-> { cow1, view2, mem1 }
(WRITE)
ts = len mem1
mem2 = mem1 ++ [msg]
---------------------
{ cow1, view1, mem1 } -(write X ts)-> { cow1 U (X->ts), view1, mem2 }
(RMW)
{ cow1, view1, mem1 } -(read X tr)-> { cow2, view2, mem2 }
{ cow2, view2, mem2 } -(write X tw)-> { cow3, view3', mem3 }
latest X tr tw mem2
view3 = view3' U tw
---------------------
{ cow1, view1, mem1 } -(update X tr tw)-> { cow3, view3, mem3 }
(MFENCE)
view2 = view1 U max cow1
---------------------
{ cow1, view1, mem1 } -> { fun _ => None, view2, mem1 }TODO:
Latest ARM architecture reference manual: https://developer.arm.com/documentation/ddi0487/fb/ Searching for "persist" leads us to interesting references...
--
78 page says:
ARMv8.2-DCCVADP allows two levels of cache clean to the Point of Persistence by:
• Redefining Point of Persistence, which changes the scope of DC CVAP .
• Defining a Point of Deep Persistence.
• Adding the DC CVADP System instruction.
--
144 page says:
Instructions and data can be held in separate caches or in a unified cache. A cache hierarchy can have one or more
levels of separate instruction and data caches, with one or more unified caches that are located at the levels closest
to the main memory. Memory coherency for cache topologies can be defined using the conceptual points Point of
Unification (PoU), Point of Coherency (PoC), Point of Persistence (PoP), and Point of Deep Persistence (PoDP).
--
2508 page defines PoC, PoU, PoP, PoDP, etc (must-read).
Point of Persistence (PoP)
When ARMv8.2-DCPoP is implemented:
The point in a memory system, if it exists, at or beyond the Point of Coherency, where
a write to memory is maintained when system power is removed, and reliably
recovered when power is restored to the affected locations in memory.When ARMv8.2-DCPoP and ARMv8.2-DCCVADP are implemented:
The point in a memory system where there is a system guarantee that there is
sufficient energy within the system to ensure that a write to memory will be persistent
if system power is removed.
Point of Deep Persistence (PoDP)
The point in a memory system where any writes that have reached that point are persistent, even
in the event of an instantaneous hardware failure of the power system.
What's the diff? I really cannot understand the diff precisely...
Lemma internal_rw
p ex
eid1 eid2
(PRE: pre_ex p ex)
(CO2: co2 ex)
(RF2: rf2 ex)
(INTERNAL: Execution.internal ex eid1 eid2):
<<EID1: ex.(Execution.label_is) Label.is_access eid1>> /\
<<EID2: ex.(Execution.label_is) Label.is_access eid2>>.
Lemma internal_read_read_po
p ex
eid1 eid2
(PRE: pre_ex p ex)
(CO2: co2 ex)
(RF2: rf2 ex)
(INTERNAL: Execution.internal ex eid1 eid2)
(EID1: ex.(Execution.label_is) Label.is_read eid1)
(EID2: ex.(Execution.label_is) Label.is_read eid2):
Execution.po eid1 eid2.
Lemma ob_read_read_po
p ex
eid1 eid2
(PRE: pre_ex p ex)
(CO1: co1 ex)
(CO2: co2 ex)
(RF1: rf1 ex)
(RF2: rf2 ex)
(RF_WF: rf_wf ex)
(INTERNAL: acyclic (Execution.internal ex))
(OB: Execution.ob ex eid1 eid2)
(EID1: ex.(Execution.label_is) Label.is_read eid1)
(EID2: ex.(Execution.label_is) Label.is_read eid2):
Execution.po eid1 eid2.
Lemma po_loc_write_is_co
ex eid1 eid2 loc
(CO1: Valid.co1 ex)
(INTERNAL: acyclic (Execution.internal ex))
(PO: Execution.po eid1 eid2)
(LABEL1: ex.(Execution.label_is) (Label.is_writing loc) eid1)
(LABEL2: ex.(Execution.label_is) (Label.is_writing loc) eid2):
ex.(Execution.co) eid1 eid2.
bob를 정의할 때 다음과 같은 방식으로 사용되고 있음 (is_dmb_wr을 그대로 가져다 씀):
Definition bob (ex:t): relation eidT :=
⦗ex.(label_is) Label.is_write⦘ ⨾
po ⨾
⦗ex.(label_is) (Label.is_barrier_c Barrier.is_dmb_wr)⦘ ⨾
po ⨾
⦗ex.(label_is) Label.is_read⦘.기존에 아래와 같이 정의된 dmb를 tso에 맞게 재정의하는 게 숙제임:
Inductive dmb (rr rw wr ww:bool) (lc1 lc2:t): Prop :=
| dmb_intro
(LC2: lc2 =
mk
lc1.(coh)
(joins [lc1.(vrn); ifc rr lc1.(vro); ifc wr lc1.(vwo)])
(joins [lc1.(vwn); ifc rw lc1.(vro); ifc ww lc1.(vwo)])
lc1.(vro)
lc1.(vwo))
.이전에 언급된 바 (#4) 는 아래와 같음:
match (rr, rw, wr, ww) {
(_, _, true, true) => mfence,
(_, _, false, true) => sfence,
_ => nop
}dmb 이름을 그대로 고수하는 게 맞을까요?sfence는 추후에 persisence(wb, fl, fo)가 적용될 때에만 의미를 가지고 지금 단계에서는 nop과 다를 바가 없는데 고려할 필요가 있을까요?
dmb에서 의미있는 파라미터는 wr 밖에 남지 않으므로 정의는 아래와 같이 단순화할 수 있을 것 같습니다:Inductive dmb (lc1 lc2:t): Prop :=
| dmb_intro
(LC2: lc2 =
mk
lc1.(coh)
(joins [lc1.(vrn); lc1.(vwo)])
lc1.(vwn)
lc1.(vro)
lc1.(vwo))
.ts1
x = 1
mfence
r1 = y // 0ts2
y = 1
r2 = CAS(x, 666, 42) // fail returning 0?vrn이(like read step) 아닌, join(vrn, vwo)이어야할 것 같다ts1
z = 1
mfence
r1 = y // 0ts2
y = 1
r2 = CAS(x, 666, 667) // fail returning 0
r3 = z // 0?r3는 1이어야 한다.join(vrn, vwo)으로 갱신시커야할 것 같다(마치 barrier처럼)ARM에선 다음 relation이 acyclic임을 요구:
Definition internal (ex:t): relation eidT := (po_loc ex) ∪ (fr ex) ∪ ex.(co) ∪ ex.(rf).
irrefl po; fr, irrefl po; co, irrefl po; rf셋이 irreflexive임을 요구만해도 충분할 것 같고pmem에 남는 메모리의 상태를 나타내는 smem(: Loc->Val)을 두자.
Axiomatic.persisted p ex smem
Promising.persisted p m smem
TODO
# Initially, x = y = 0
# Thread 1
1: r1 = x
2: if r1 >= 0
3: y = 1
# Thread 2
4: r2 = y
5: x = r2
# Behavior in question:
r1 == r2 == 1dob--> 3 --rfe--> 4, 4--dob--> 5 --rfe--> 1r1이 0r2가 0# Initially, x = y = 0
# Thread 1:
1: r1 = x
2: r2 = x
3: if r1 == r2
4: y = 1
# Thread 2:
5: r3 = y
6: x = r3
# Behavior in question:
r1 == r2 == r3 == 1dob--> 2 --dob--> 4 --rfe--> 5, 5--dob--> 6 --rfe--> 1r1이 0r3가 0# Initially, x = y = 0
# Thread 1:
1: r1 = x
2: r2 = x
3: if r1 == r2
4: y = 1
# Thread 2:
5: r3 = y
6: x = r3
# Thread 3:
7: x = 2
# Behavior in question:
r1 == r2 == r3 == 1dob--> 2 --dob--> 4 --rfe--> 5, 5--dob--> 6 --rfe--> 1r1이 0r3가 0# Initially, x = y = 0
# Thread 1:
1: r1 = x
2: y = r1
# Thread 2:
3: r2 = y
4: x = r2
# Behavior in question:
r1 == r2 == 1dob--> 2 --rfe--> 3, 3--dob--> 4 --rfe--> 1r1이 0r2가 0# Initially, x = y = z = 0
# Thread 1:
1: r1 = x
2: y = r1
# Thread 2
3: r2 = y
4: x = r2
# Thread 3
5: z = 1
# Thread 4
6: r3 = z
7: x = r3
# Behavior in question:
r1 == r2 == 1, r3 == 0.rfe--> 6, r3 == 0dob--> 2 --rfe--> 3, 3--dob--> 4 --rfe--> 1r1이 0r2가 0r3가 1r1이 0# Initially A = B = 0
# Thread 1
1: r1 = A
2: if (r1 == 1)
3: B = 1
# Thread 2
4: r2 = B
5: if (r2 == 1)
6: A = 1
7: if (r2 == 0)
8: A = 1
# Behavior in question:
r1 == r2 == 1dob--> 3 --rfe--> 4, 4--dob--> 6 --rfe--> 1dob--> 8 --rfe--> 1, 1--dob--> 3 --rfe--> 4r1은 0r2는 0# Initially, x = y = z = 0
# Thread 1:
1: r1 = z
2: r2 = x
3: y = r2
# Thread 2:
4: r3 = y
5: z = r3
6: x = 1
# Behavior in question:
r1 == r2 == r3 == 1.dob--> 5 --dob--> 6--rfe--> 2, 2 --dob--> 3 --rfe--> 4r1은 0r3는 0# Initially, x = y = 0
# Thread 1:
1: r1 = x
2: r2 = 1 + r1*r1 - r1
3: y = r2
# Thread 2:
4: r3 = y
5: x = r3
# Behavior in question:
r1 == r2 == 1dob--> 2 --dob--> 3 --rfe--> 4, 4 --dob--> 5 --rfe--> 1r1은 0r3는 0 => r1은 0# Initially, x = y = 0
# Thread 1:
1: r1 = x
2: r2 = 1 + r1*r1 - r1
3: y = r2
# Thread 2:
4: r3 = y
5: x = r3
# Thread 3:
6: x = 2
# Behavior in question:
r1 == r2 == 1dob--> 2 --dob--> 3 --rfe--> 4, 4 --dob--> 5 --rfe--> 1r1은 0r3는 0
r1은 0r1은 2# Initially, x = y = z = 0
# Thread 1:
1: r1 = x
2: if (r1 == 1)
3: y = 1
# Thread 2
4: r2 = y
5: if (r2 == 1)
6: x = 1
# Thread 3
7: z = 1
# Thread 4
8: r3 = z
9: if (r3 == 1)
10: x = 1
# Behavior in question:
r1 == r2 == 1, r3 == 0.r1은 0r2는 0r3는 1r1은 0r2는 0# Initially, x = y = z = 0
# Thread 1:
1: r1 = z
2: w = r1
3: r2 = x
4: y = r2
# Thread 2:
5: r4 = w
6: r3 = y
7: z = r3
8: x = 1
# Behavior in question:
r1 == r2 == r3 == r4 == 1rfe-->3, 3 --dob--> 4 --rfe--> 6 --dob-->8r1은 0w가 initially 1일지라도 5가 먼저 실행되면,
r1은 0r3는 0# Initially, x = y = 0; a[0] = 1, a[1] = 2
# Thread 1
1: r1 = x
2: a[r1] = 0
3: r2 = a[0]
4: y = r2
# Thread 2
5: r3 = y
6: x = r3
# Behavior in question:
r1 == r2 == r3 == 1dob--> 4 --rfe--> 5, 5 --dob--> 6 --rfe--> 1 --dob--> 3r1은 0r3는 0# Initially, x = y = 0
# Thread 1:
1: r1 = x
2: if (r1 == 1)
3: y = 1
# Thread 2:
4: r2 = y
5: if (r2 == 1)
6: x = 1
# Behavior in question:
r1 == r2 == 1rfe--> 4, 4 --dob--> 6 --rfe--> 1 --dob--> 3r1은 0r2는 0# Initially, a = b = y = 0, y is volatile
# Thread 1:
1: r1 = a
2: if (r1 == 0)
3: y = 1
4: else
5: b = 1
# Thread 2:
6: do {
7: r2 = y
8: r3 = b
9: } while (r2 + r3 == 0);
10: a = 1;
# Behavior in question:
r1 == r3 == 1; r2 == 0rfe--> 1, 1 --dob--> 5 --rfe--> 8 --dob--> 10r1은 0# Initially, a = b = x = y = 0, x and y are volatile
# Thread 1:
1: r0 = x
2: if (r0 == 1)
3: r1 = a
4: else
5: r1 = 0
6: if (r1 == 0)
7: y = 1
8: else
9: b = 1
# Thread 2:
10: do {
11: r2 = y
12: r3 = b
13: } while (r2 + r3 == 0);
14: a = 1;
# Thread 3:
15: x = 1
# Behavior in question:
r0 == r1 == r3 = 1; r2 == 0rfe--> 1 --dob--> 3 --dob--> 9 --rfe--> 12, 12 --dob--> 14 --rfe--> 3r0은 0r1은 0# Initially, x = 0
# Thread 1:
1: r1 = x
2: x = 1
# Thread 2:
3: r2 = x
4: x = 2
# Behavior in question:
r1 == 2; r2 == 1rfe--> 3 , 3 --dob--> 4 --rfe--> 1 --dob--> 2r1은 0r2는 0# Initially, x = y = 0
# Thread 1:
1: r3 = x
2: if (r3 != 42)
3: x = 42
4: r1 = x
5: y = r1
# Thread 2:
6: r2 = y
7: x = r2
# Behavior in question:
r1 == r2 == r3 == 42dob--> 3, 1 --dob--> 4 --fr--> 7 --rfe--> 1r3는 0r2는 0# Initially, x = y = 0
# Thread 1:
1: r3 = x
2: if (r3 == 0)
3: x = 42
4: r1 = x
5: y = r1
# Thread 2:
6: r2 = y
7: x = r2
# Behavior in question:
r1 == r2 == r3 == 42dob--> 3, 1 --dob--> 4 --fr--> 7 --rfe--> 1r3는 0r2는 0# Initially, x = y = 0
# Thread 1:
1: join thread 3
2: r1 = x
3: y = r1
# Thread 2:
4: r2 = y
5: x = r2
# Thread 3:
6: r3 = x
7: if (r3 != 42)
8: x = 42
# Behavior in question:
r1 == r2 == r3 == 42dob--> 8, 8 --rfe--> 2 --dob--> 3 --rfe--> 4 --dob--> 5 --rfe--> 6r2는 0r3는 0# Initially, x = y = 0
# Thread 1:
1: join thread 3
2: r1 = x
3: y = r1
# Thread 2:
4: r2 = y
5: x = r2
# Thread 3:
6: r3 = x
7: if (r3 == 0)
8: x = 42
# Behavior in question:
r1 == r2 == r3 == 42dob--> 8, 8 --rfe--> 2 --dob--> 3 --rfe--> 4 --dob--> 5 --rfe--> 6r2는 0r3는 0axiomatic/promising 둘다 execution이 종료되면 (terminated) 가장 마지막 메시지가 persist 되어야 함
@jeehoonkang
write_incr와 rmw_incr를 증명하던 중 ts에 대한 조건이 추가되어야 할 것 같아서 아래의 CHECK대로 바꿔보았는데, 이 제안이 맞는지 여쭙습니다.
Inductive write (vloc vval res:ValA.t (A:=unit)) (ts:Time.t) (tid:Id.t) (lc1:t) (mem1: Memory.t) (lc2:t) (mem2: Memory.t): Prop :=
| write_intro
loc val
view_loc view_val
view_post
(LOC: loc = vloc.(ValA.val))
(VIEW_LOC: view_loc = vloc.(ValA.annot))
(COH: lt (lc1.(coh) loc).(View.ts) ts) (* CHECK: added due to write_incr *)
(VAL: val = vval.(ValA.val))
(VIEW_VAL: view_val = vval.(ValA.annot))
(VIEW_POST: view_post = View.mk ts bot)
(MEM: Memory.append (Msg.mk loc val tid) mem1 = (ts, mem2))
(RES: res = ValA.mk _ 0 bot)
(LC2: lc2 =
mk
(fun_add loc view_post lc1.(coh))
lc1.(vrn)
(join lc1.(vwn) view_post)
lc1.(vro)
(join lc1.(vwo) view_post))
.Inductive rmw (vloc vold vnew:ValA.t (A:=unit)) (ts:Time.t) (tid:Id.t) (lc1:t) (mem1:Memory.t) (lc2:t) (mem2:Memory.t): Prop :=
| rmw_intro
loc old new old_ts
view_post
(LOC: loc = vloc.(ValA.val))
(LATEST: Memory.latest loc old_ts (lc1.(coh) loc).(View.ts) mem1) (* CHECK: added due to rmw_incr *)
(COH: lt (lc1.(coh) loc).(View.ts) ts) (* CHECK: added due to rmw_incr *)
(* (LATEST: Memory.latest loc old_ts ts mem1) (* CHECK: removed 'cause it's too strong *) *)
(MSG: Memory.read loc old_ts mem1 = Some old)
(OLD: vold.(ValA.val) = old)
(NEW: new = vnew.(ValA.val))
(VIEW_POST: view_post = View.mk ts bot)
(MEM: Memory.append (Msg.mk loc new tid) mem1 = (ts, mem2))
(LC: lc2 =
mk
(fun_add loc view_post lc1.(coh))
(join lc1.(vrn) view_post)
(join lc1.(vwn) view_post)
(join lc1.(vro) view_post)
(join lc1.(vwo) view_post))
.이전에 rmw step의 old_ts에 대한 조건으로 exclusive를 사용하기로 한 적이 있음:
"old_ts부터 ts까지 tid가 아닌 곳에서 쓴 메시지는 없다"
X = 666
r1 = CAS(X, 0, 42) # success성공시켜주면 안 된다..
postview가 아니라 old_ts msg를 따라가야 함
quick is now deprecated)destruct (equiv_dec...) -> eqvtacHint Resolve foo와 같이 힌트를 core에 implicitly 등록하는 것만을 의미하는 것이었습니다. Hint Resolve foo: core 같은 식으로 explicitly 등록하는 것 자체는 상관이 없긴 합니다.hahn 제외)들이 core에 등록된 것 같은데 이들을 전부 hint db를 따로 파서 바꿔주어야 할까요?eauto 가 제대로 안 먹어서 애를 먹는 상태입니다. (core에 등록시 잘 됩니다)T1
x = 1
r1 = x
r2 = yT2
y = 1
r3 = y
r4 = xbehavior
r2 = r4 = 0[W];po;[FO];po;[SF] 같은 식으로 실행했을 때 persist가 되지 않는 행동이 일어나는지 실험방법 강구 및 실험 (#34)잠정적으로 아래 모델을 Axiom-PARMv8 모델로 사용하려고 합니다.
pob = [W U R]; po; [dmb.sy U dsb.sy]; po; [FO] U
[W U R]; (po ∩ CL); [FO] U
[FO]; (po ∩ CL); [FO] // can be removed
fl = [W ∩ D]; (ob+ ∩ CL); [FO]; po; [dsb.sy]
Formalization에서 [dm(s)b.sy] = [dm(s)b.rr ∩ rw ∩ wr ∩ ww]으로 정의됩니다.
추가로 x86 또한 아래와 같이 simplify 가능할 것으로 보입니다.
pob = [W ∪ U]; po; [FL]
∪ ([U]; po; [FO])
∪ [W]; (po ∩ CL); [FO]
∪ [R]; po; [FL ∪ FO]
fl = [W ∩ D]; (ob+ ∩ CL); [FL]
∪ [W ∩ D]; (ob+ ∩ CL); [FO]; po; [MF ∪ SF ∪ U ]
진행중
@jeehoonkang @Sung-HwanLee
co 확장에 관하여 몇 가지 의구심이 드는 부분이 있습니다
(가정: alternative Figure 10에서 fl의 ob+_scl을 co로 대체한다면)
co확장으로 인해 [FL]과 dom(co?;[P])이 더 이상 서로소가 아니게 됩니다.dom(co?;[P]) <= P <= W_D (Figure 10) 이므로 어떤 e(in [FL]) in W_D 가 될 수 있습니다.flush x; x=1; flush x"coi -> po"가 더 이상 참이 아닌데 이는 조금 이상합니다.
예시: flush x; x=1 에서 x=1 -co-> flush x 가 가능하고 x=1 in dom(fl) 이 되어버립니다.
irrefl (co; po) 추가FL; po; WFO; po_cl; W (이건 Px86에는 없는 규칙입니다)짧은 생각으로는 방법1이 더 심플한 것 같긴 한데 무엇이 맞는진 잘 모르겠습니다.
a -ob-> FL -ob-> b 이면 a -ob-> b 이다." 라는 렘마가 있었는데 이는 더 이상 참이 아니게 되기 때문입니다.x=1; flush y; flushopt y안녕하세요, 코드에 대해 코멘트 드릴 부분은 없고 질문이 몇 가지 있습니다.
X = 1
Y = 1 [rel]
||
a = Y // 1
dmb.sy
flush X
dsb.sy
Figure 12에 따르면 [X = 1] -ob-> [flush X] 가 존재합니다.
즉, dsb.sy 실행 후 X = 1이 persist해야 하는 것으로 보입니다.
Figure 11의 경우 [a = Y] -ob-> [flush X]가 없어 dsb.sy 실행 이후에도 X = 1이 persist할 필요가 없는 것으로 보이는데, 맞나요?
여기까지 맞다면 아래와 같은 변형에 대해서도 궁금합니다.
X = 1
Y = 1 [rel]
||
a = Y // 1
dmb.ld (= dmb r, rw)
flush X
dsb.sy
X = 1
Y = 1 [rel]
||
a = Y [acq] // 1
flush X
dsb.sy
만약 첫번째 프로그램에서 X = 1이 persist하다면 위 두 프로그램에서 X = 1이 persist하지 않다는 것이 굉장이 의아합니다.
또한 만약 이것이 참인 경우 현재 promising-ARM에서 구현하기 위해서는 다른 view component를 추가해야할 것으로 보입니다.
Promising-ARM에서 persistency를 global persistent view 이후의 메시지들이 persist 하다고 정의할 예정인가요?
Figure 11 및 12에서 ARM-WB-WB는 없어도 equivalent한 것이 아닌지 궁금합니다.
개인적으로 지금 ARM spec (Figure 12)가 다소 작위적이지 않나 생각합니다.
dmb.ld; flush 또는 flush; dmb.st의 order가 보존되지 않을 이유가 없는데 아마 기존 연구에서 충분한 이해가 이루어지지 않은 것 같습니다.
(dmb.st의 경우 ARM spec에 따르면 전후 write 사이에만 order를 부여하므로 아닐 수도 있습니다.
C11의 release fence는 dmb.sy로 컴파일 됩니다.)
acquire read나 release write의 경우도 마찬가지라고 봅니다.
이 부분에 대해서 ARM 개발자들과도 조금 더 논의해서 보완하면 어떨까 합니다.
다만 우리 구현에서는 barrier가 rr/rw/wr/ww로 나뉘어 있는데, 이 경우 flush를 write로 볼지 read로 볼지 애매한 부분이 생기긴 합니다.
PFtoA4SL에서의 증명은
을 보이는 것 같습니다.
예를 들어 vro라면,
(R \/ U); po 가 되고ts <= vro를 증명해야 합니다.그런데 예전에 lc2.vro = join(lc1.vro, old_ts) 로 놓기로 얘기가 되었습니다.
다시 말해 ts <= old_ts를 증명해야 되는데 이는 말이 안 되므로 rmw스탭에서의 vro를 바꿔야할 것 같습니다.
rmw의 가까운 친척인 read를 보면 vro를 메시지의 뷰로 조인하는 것이 아닌 post-view로 조인합니다.
vro를 "어디 있는 메시지까지 읽었냐" 보다는 "읽으면서 어디까지 보게 되었냐" 라고 해석한다면,
rmw의 vro도 역시 post-view, 즉 ts로 주어야 할 것 같습니다
t1
(a) X := 1;
(b) r0 := Y; // 1 from (f)
(c) r1 := X // 2 from (e)t2
(d) r0 = X; // 1 from (a)
(e) X = 2;
(f) Y = 1(a) -> (d) -> (e) -> (f) -> (b) -> (c) 순으로 실행될 때,
(c)는 2를 읽어야 한다.
res.annot에 담아두고 있어서 post-view를 참조할 때 res.annot을 보면 됨lc2.coh(x) = post-view 라는 사실을 이용하여 lc2.coh(x)를 참조하면 되지만lc2.coh(x) = join(lc1.coh(x), post-view) 이므로 lc2.coh(x)가 직접적으로 post-view를 나타내지 않음lc2.coh(x) = join(lc1.coh(x), post-view) 라는 것은 ARM에 있던 걸 그대로 가져와서 생기는 문제라고 봄lc2.coh(x) = post-view로 두어도 무방할 것처럼 보임lc1.coh(x) <= post-viewinitially, X[0] = X[1] = 0
t1
X[0] = 1
t2
a = X[0] // 1
b = X[a] // 0
c = X[1] // 0
다음 중 하나를 선택:
1. read 역시 write나 rmw처럼 lc2.coh(x) = post-view 로 수정. 이 경우 read 스탭후 어떠한 뷰도 작아지지는 않는다는 read_incr lemma를 증명해야 함
2. TsoPFtoA4SL 증명 중에 coh가 post-view보다 커지는 일은 없다는 것을 증명
3. read에서 post-view를 찾는 다른 방법을 강구
사실상 1과 2는 같은 증명을 해야하며 어디서 증명하느냐의 차이
매뉴얼로 더 알긴 힘든 것 같음
교수님 생각:
그럼 이제 어떡할지,
FO; po; FO 지우냐
-> 될 것 같은데, 나중에 핸드프루프를 해본다
케임브리지 dc 오퍼레이션 논문
vnew -> vrn 코멘트
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.