thread testing tool?

[Peter]

Hi

Is there a simple tool I can use to test how two threads using the same
instance of a class would react? For example, I would like to manually
control two threads stepping through the below code to see the states
of the threads (and the list in MyClass) if the threads share the same
MyClass instance.

My guess is that it would be possible for the below class to return
different List instances to each thread.


public class MyClass
{
private List<string> aList;

public List<string> AList
{
get
{
if (aList == null)
{
aList = new List<string>();
}
return aList;
}
}
}

 

[Ignacio Machin ( .NET/ C# MVP )]

Hi

Is there a simple tool I can use to test how two threads using the same
instance of a class would react? For example, I would like to manually
control two threads stepping through the below code to see the states
of the threads (and the list in MyClass) if the threads share the same
MyClass instance.

My guess is that it would be possible for the below class to return
different List instances to each thread.

public class MyClass
{
  private List<string> aList;

  public List<string> AList
  {
    get
    {
      if (aList == null)
      {
        aList = new List<string>();
      }
      return aList;
    }
  }

}

Honestly, I do not know of any such tool.

But IMHO it would be useless for what you want. you would have to take
into account ANY and ALL of the possible scenarios just to get a valid
coverage of what would happen IF ....

In your case both threads can execute up to the comparison point. so
both will create a new isntance of the list.


so your assumptions are correct

 

[harborsparrow]

Am I missing something? If you have two threads, and both can write
to a shared class, each thread MUST lock the object before writing to
it. Otherwise, you'll have a race condition (at a minimum). If
either thread hogs the object, you could get a deadlock. So this kind
of thing should only be done briefly in order to signal across the two
threads.

You can have each thread report information by calling "safely" into
some sort of user interface thread. So for example, in a Windows
application, a worker thread can write into the (main) event loop
thread by calling a "safe" public method like this:


public void SafeSetLabelRight(string theName)
{
if (this.labelRight.InvokeRequired)
{
this.labelRight.Invoke(
new DelegateForTextUpdate(this.SetLabelRight),
new object[] { theName });
}
else
{
this.SetLabelRight(theName);
}
}


public void SetLabelRight(string theName)
{
this.labelRight.Text = theName;
}

private delegate void DelegateForTextUpdate(string param);



The above code first checks where "invoke is required" (i.e., whether
the caller is in a different thread). If the caller is in the same
thread as the thing begin written to, no problem, just call the code
to write the text. But if in a different thread, use a delegate to
make the call asynchronously. This way, nothing gets locked and there
is no race condition because the write operation happens when the UI
thread has time to process the next event.

The trickly part of this code is the weird delegate syntax.

 

[Israel]

Am I missing something?  If you have two threads, and both can write
to a shared class, each thread MUST lock the object before writing to
it.  Otherwise, you'll have a race condition (at a minimum).  If
either thread hogs the object, you could get a deadlock.  So this kind
of thing should only be done briefly in order to signal across the two
threads.

Well you can't get a deadlock with one resource. If a thread never
releases the lock then technically it's because it's waiting on some
other resource but presuming that the code will always release the
lock then a million threads won't dead lock unless there are multiple
resources they need to lock.

 

[Israel]

private readonly object aListLock = new object();
(...)
if(aList == null) {
  lock(aListLock) {
    if(aList == null) {//double check
      aList = new  List<string>();
    }
  }}

return aList;

You shouldn't be checking for null on aList outside of the lock
either. Any access to aList should be done within the lock. It
really doesn't gain you anything except not having to aquire the
lock. Granted this will probably not fail but it's not a pattern to
repeat since checking that aList is null could technically be context
switched just as it's getting set to not null.