diff --git a/lectures/concurrency/index.html b/lectures/concurrency/index.html index e5f00b1..ca0e459 100644 --- a/lectures/concurrency/index.html +++ b/lectures/concurrency/index.html @@ -482,7 +482,8 @@

Volatile variables

though they have their own mutex: each access to such a variable (read or write) causes synchronization using that mutex. This mechanism is occasionally useful, but it's not enough in many situations. For example, declaring the variable balance to be volatile -in the earlier bank example would not help at all; all of the wrong interleavings would still be possible. +in the earlier bank example would not help at all. +Each access will be separately synchronized, so all the bad interleavings remain possible.

Some programmers have a bad habit of trying to solve concurrency problems @@ -492,25 +493,10 @@

Volatile variables

with them can be accomplished with other synchronization mechanisms. And because they cause automatic synchronization, they are expensive, both because synchronization has an inherent overhead and because it can remove desirable parallelism. -The time that volatile is useful is when +The volatile declaration is useful is when all you want is indeed to acquire a mutex around all accesses to a variable; in this case, volatile is the easiest and cheapest way to do it.

-

-We might think that we could fix the Account example from earlier by -declaring balance to be volatile: -

- -
-private volatile int balance;
-
- -

-But this declaration will not help at all. There are still two -separate accesses to the variable (a read and a write) from each of the methods of -Account. Each access will be separately synchronized, so all -interleavings remain possible. -

Atomic abstractions