2

Are the Employee and/or Illness instances thread-safe in this scenario? Does each thread have it own copy of the objects? Originally I thought that each thread would have its own copy, but now I'm not sure.

Parallel.ForEach(line01s, _options, o =>
{
    var employee = new Employee();
    // set values on employee...Safe?

    var illness = new Illness();
    // set values on illness...Safe?

    employee.AddIllness(illness);  // Illness is a property on Employee

}

Is it possible for the Illness object to be set on the wrong Employee object? Do I need to add lock around employee.AddIllness(illness);? The more I work with this TPL stuff, the more I find I don't understand

Big Daddy
  • 5,160
  • 5
  • 46
  • 76

2 Answers2

7

Your example only works with objects creating inside the scope of the lambda expression, therefore you have nothing to worry about. If you were modifying the state of an object outside of the lambda block, then you'd need to worry about locking, etc.

Justin Niessner
  • 242,243
  • 40
  • 408
  • 536
  • Suppose I modify the state of the Illness class in the employee.AddIllness(Illness illness) method. Would I need to lock inside that method? – Big Daddy Oct 22 '14 at 17:09
  • @BigDaddy - No. You'd still only be modifying the single instance from the single lambda. Locking is only needed if you're modifying shared state from multiple threads. – Justin Niessner Oct 22 '14 at 17:11
2

If you iterate Parallel.ForEach over employees collection, or create new employee inside the lambda, then there is nothing to worry. Each lambda call is completely independent of others(if there are no outer variables in closure).

If employees collection have duplicates or the processing is more complex, then you will have to use some synchronization code.

Community
  • 1
  • 1
Eugene Podskal
  • 10,270
  • 5
  • 31
  • 53