From a3bf617fa4ee55d5d2ec262f98767a3e384ee875 Mon Sep 17 00:00:00 2001
From: Josef Utbult <josutb-7@student.ltu.se>
Date: Fri, 5 Mar 2021 15:23:49 +0100
Subject: [PATCH] bare4_3
---
examples/rtic_bare4.rs | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/examples/rtic_bare4.rs b/examples/rtic_bare4.rs
index 28e5e2e..2637ed6 100644
--- a/examples/rtic_bare4.rs
+++ b/examples/rtic_bare4.rs
@@ -108,7 +108,7 @@ const APP: () = {
// Digging a bit deeper, why do you think `read_volatile` is declared `unsafe`.
// (https://doc.rust-lang.org/core/ptr/fn.read_volatile.html, for some food for thought )
//
-// Because you can get undefined behaviour
+// Because you can get undefined behaviour.
//
// Commit your answers (bare4_2)
//
@@ -121,7 +121,7 @@ const APP: () = {
//
// Why is it important that ordering of volatile operations are ensured by the compiler?
//
-// ** your answer here **
+// Because you can get race conditions when you have multiple read and writes to the same registers
//
// Give an example in the above code, where reordering might make things go horribly wrong
// (hint, accessing a peripheral not being powered...)
@@ -131,6 +131,8 @@ const APP: () = {
// Without the non-reordering property of `write_volatile/read_volatile` could that happen in theory
// (argue from the point of data dependencies).
//
-// ** your answer here **
+// When you have read and write operations to the same register, as in line 62-63 and
+// 66-67, there would be a problem if the compiler swapped the operations around, as
+// there wouldn't be any data to write if it hasn't been read yet.
//
// Commit your answers (bare4_3)
--
GitLab