Threads: why locking is required when using shared variables

I was recently faced with a thread that used .= on a shared variable, and I wondered if that was safe. I figured I'd write up a introductory tutorial on the answer I found. For simplicity, we'll look at ++ first.

The following code outputs 400,000:

my $count     = 100_000;
my $num_calls = 4;

my $sum = 0;
sub inc { ++$sum for 1..$count; }

inc() for 1..$num_calls;
print("$sum\n");   # 400000
[download]

If you ran the 4 calls to inc in parallel, would the answer still be 400,000? Not likely, if you don't change inc.

use threads;
use threads::shared;

my $count     = 100_000;
my $num_calls = 4;

my $sum : shared = 0;
sub inc { ++$sum for 1..$count; }

$_->join for map { threads->create( \&inc ) } 1..$num_calls;
print("$sum\n");   # 314813
[download]

That's because there is a race condition.

+=======================+
|          CPU          |
+-----------+-----------+
| thread 1  | thread 2  |
+===========+===========+
| ...       |           |   T
| load $sum |           |   i
| inc       |           |   m
+-----------+-----------+   e
|           | ...       |   |
|           | load $sum |   |
|           | inc       |   v
|           | save $sum |
|           | ...       |
+-----------+-----------+
| save $sum |           |
| ...       |           |
+===========+===========+
[download]

The solution is to protect the critical section using a thread synchronization mechanism such as lock.

use threads;
use threads::shared;

my $count     = 100_000;
my $num_calls = 4;

my $sum : shared = 0;
sub inc { for (1..$count) { lock($sum); ++$sum } }

$_->join for map { threads->create( \&inc ) } 1..$num_calls;
print("$sum\n");   # 400000
[download]

Whenever an transformation operation (read ⇒ manipulate ⇒ write) is performed on a shared variable, locking is needed. See threads::shared for tools to do this.

The program behind the <spoiler> below outputs results similar to the following:

++s     sum = 233564 (expecting 400000)
s+=1    sum = 143915 (expecting 400000)
c.=l    length = 248149 (expecting 400000)
c=c.l   length = 123360 (expecting 400000)
[download]

As you can see, +=, .= and = . are also not atomic. The program can only prove that an operator isn't atomic (i.e. is interruptable). It cannot prove that an operator is atomic (i.e. is not interruptable). If you're getting the "expecting" result, try upping $count and/or $threads.

Update: Added the preface and links to Wikipedia.

Added to Tutorials by planetscape

( keep:0 edit:6 reap:0 )

Back to Tutorials