20검증 문제
임의적인 rule 충돌 없애기
1. 문제와 수정 범위
받아들인 요청 하나는 정확히 한 rule이 처리해야 합니다. Boost 요청은 8비트 값을 두
배로 만들고 boostCount를 증가시킵니다. 일반 요청은 5를 더하고 offsetCount를
증가시킵니다. 처리 전에는 busy가 참이고, 처리 뒤에는 거짓이어야 합니다.
Starter의 두 rule은 pending만 조건으로 사용합니다. 요청이 대기하면 둘 다 활성화되고
resultReg와 pending에 동시에 쓰려고 합니다. bsc는 하나를 억제하는 schedule을
만들고 경고합니다. boostReg에 저장한 요청 종류는 실행할 rule을 고르는 데 쓰이지
않습니다.
수정 범위는 applyBoost와 applyOffset의 조건입니다. Action body, request method,
카운터, 폭, 인터페이스는 그대로 두세요. 두 조건은 저장된 요청 종류를 반영해야 하고,
동시에 참이 되지 않아야 합니다.
2. Starter 읽기와 증상 예측
request부터 읽어 보세요. 이 method는 amount와 boost 여부를 저장하고 pending을 참으로
만듭니다. 레지스터 쓰기는 에지에서 commit되므로, 요청을 받은 같은 사이클에는 worker
rule이 실행되지 않습니다.
다음 순서로 충돌을 찾아보세요.
| 순서 | 확인할 항목 | 판단할 내용 |
|---|---|---|
| 1 | 두 worker의 guard | 같은 상태에서 함께 참이 되는지 |
| 2 | 두 worker의 write set | 함께 쓸 수 없는 레지스터가 무엇인지 |
| 3 | boostReg | 요청 종류가 저장되지만 읽히지 않는 이유 |
| 4 | 결과, 두 카운터, busy | 실제로 선택된 worker를 구분하는 관찰값 |
수정하기 전 컴파일에서는 충돌과 억제된 rule에 대한 scheduling 경고가 발생해야 합니다.
실행에서는 현재 우선순위의 승자가 모든 요청을 처리합니다. 같은 결과가 반복되더라도 요청
종류에 따른 동작을 보장한 것은 아닙니다.
3. 요청 종류를 활성 조건에 포함하기
두 worker의 기존 pending 조건은 유지하세요. 저장된 Boolean 선택을 guard에 결합해,
요청마다 하나의 worker만 활성화합니다. Body 안의 if나 우선순위 annotation으로는 다른
rule이 선택되지 않는 문제를 없앨 수 없습니다.
완료된 protocol은 여러 사이클에 걸쳐 다음 상태를 보입니다.
| 관찰 시점 | 일반 요청 | Boost 요청 |
|---|---|---|
| 요청 전 | busy는 거짓이고 이전 결과와 카운터가 유지됩니다. | 같은 상태입니다. |
| 요청 commit 뒤 | amount와 종류가 저장되고 busy는 참이며 카운터는 그대로입니다. | 같은 상태입니다. |
| 처리 에지 | Offset worker만 5를 더하고 자신의 카운터를 증가시킵니다. | Boost worker만 두 배 연산과 자신의 카운터 증가를 수행합니다. |
| 처리 다음 상태 | 8비트 결과가 보이고 busy는 거짓입니다. | 8비트 결과가 보이고 busy는 거짓입니다. |
일반 요청과 boost 요청을 반복하거나 번갈아 보내도 요청 종류와 일치하는 카운터만 증가해야 합니다. 요청을 받은 사이클에는 이전 결과가 유지되어야 합니다. 각 연산의 결과는 8비트에서 wraparound해야 하며, 억제되거나 실행 불가능한 worker에 대한 경고도 없어야 합니다.
4. 단계형 힌트
힌트 1 — 누락된 상태 읽기
각 guard가 읽는 레지스터를 적어 보세요. request가 저장하지만 두 guard에서 사용하지 않는
Boolean 레지스터가 요청 종류를 나타냅니다.
힌트 2 — 수정 위치
두 rule header의 pending은 남겨 두세요. 요청 종류는 action body가 아니라 두 guard에서
선택 조건으로 사용합니다.
힌트 3 — 배타성 증명
한 guard는 boost인 경우를, 다른 guard는 그 반대인 경우를 나타내야 합니다. Boolean 값 두 개에 대한 진리표를 작성해, pending일 때 정확히 한 조건만 참인지 확인해 보세요.
5. 추가 실험
필수 수정을 마친 뒤 공개 요청의 boost 여부만 바꿔 실행해 보세요. 이어서 일반 요청의
amount를 8'hff에 가까운 값으로 바꿔 보세요. 각 실행 전에 선택될 카운터와 8비트
wraparound 결과를 계산합니다. Rule 순서를 바꾸지 않아도 요청 필드만으로 동작이 선택되고,
scheduling 경고가 없어야 합니다. 추가 실험은 채점 조건이 아닙니다.