As I discovered that the source IEnumerable is called by PLINQ from multiple threads, it made me thinking: how can it possibly work? E.g. when someone writes code like this:<\/p>\n
the Range iterator must keep its current state in some variable. If this state is accessed from multiple threads, how are race conditions avoided? Here are my findings in order:<\/p>\n 1. Each enumerator, however, is not<\/b> thread safe and does not have any locking code.<\/p>\n 2. Enumerable.Range(1,1000).AsParallel()...<\/code><\/p>\nEnumerable.Range()<\/code> returns an IEnumerable<int><\/code>. This enumerable’s GetEnumerator()<\/code> will return different enumerators for different threads. This appears to be a built-in feature of enumerables generated from yield return<\/code> keyword. Reflector is my witness. Proof link<\/a>.<\/p>\nAsParallel()<\/code> calls GetEnumerator()<\/code> only once, and then uses it from multiple threads, so the above protection does not work.<\/p>\n