C# 4 and .NET 4

512 ❘ ChaPTer 20 threAds, tAsks, And synchrOnizAtiOn
occur more often than with a single-core CPU. The
problem will occur with a single-core CPU because
thread scheduling is preemptive, but not that often.
Figure 20-1 shows an assertion of the program,
where the race condition occurred after 75,069
loops. You can start the application multiple times,
and you will always get different results.
You can avoid the problem by locking the shared
object. You can do this inside the thread by
locking the variable state, which is shared among
the threads, with the lock statement as shown.
Only one thread can be inside the lock block for
the state object. Because this object is shared
among all threads, a thread must wait at the lock
if another thread has the lock for state. As soon as
the lock is accepted, the thread owns the lock and
gives it up with the end of the lock block. If every
thread changing the object referenced with the
state variable is using a lock, the race condition no
longer occurs.
figure 20-1
public class SampleTask
{
public void RaceCondition(object o)
{
Trace.Assert(o is StateObject, "o must be of type StateObject");
StateObject state = o as StateObject;
}
}
int i = 0;
while (true)
{
lock (state) // no race condition with this lock
{
state.ChangeState(i++);
}
}
code snippet ThreadingIssues/SampleTask.cs
Instead of performing the lock when using the shared object, you can make the shared object thread-safe.
Here, the ChangeState() method contains a lock statement. Because you cannot lock the state variable
itself (only reference types can be used for a lock), the variable sync of type object is defined and used
with the lock statement. If a lock is done using the same synchronization object every time the value state is
changed, race conditions no longer happen.
public class StateObject
{
private int state = 5;
private object sync = new object();
public void ChangeState(int loop)
{
lock (sync)
{
if (state == 5)
{
www.it-ebooks.info