section.
--- /dev/null
+#lang racket
+
+#|
+
+Only the below three cases will remain:
+
+101: P1 sets x to 100 and then P2 increments x to 101.
+121: P2 increments x to 11 and then P1 sets x to x times x (121).
+100: P1 accesses x (twice), then P2 sets x to 11, then P1 sets x.
+
+|#
\ No newline at end of file
--- /dev/null
+#lang racket
+
+#|
+
+(define x 10)
+
+(parallel-execute (lambda () (set! x (* x x)))
+ (lambda () (set! x (* x x x))))
+
+list all possible values of x.
+
+|#
+
+#|
+
+1. 100
+2. 1000
+3. (expt 100 3) = 1000000
+4. (expt (expt 10 3) 2) = 1000000
+5. (* 10 (* 10 10 10)) = 10000
+6. (* 10 (* 10 10) (* 10 10)) = 100000
+7. (* 10 10 (* 10 10)) = 10000
+
+|#
+
+#|
+
+Which of these possibilities remain if we instead use serialized procedures:
+
+(define x 10)
+
+(define s (make-serializer))
+
+(parallel-execute (s (lambda () (set! x (* x x))))
+ (s (lambda () (set! x (* x x x)))))
+
+ans:
+
+=> 1000000
+
+|#
\ No newline at end of file
--- /dev/null
+#lang racket
+
+#|
+
+I don't agree. 'balance' is only read and for a particular account, it is
+not usually read while another transaction is in progress. Further, even if
+it is read concurrently with a transaction (deposit or withdrawal), one will
+get either the value before the transaction or the one after. Both are
+acceptable.
+
+|#
\ No newline at end of file
--- /dev/null
+#lang racket
+
+#|
+
+Yes, it is safe.
+
+|#
\ No newline at end of file