BitArray race conditions may lead to memory corruption

[GrabYourPitchforks]

As of dotnet/corefx#33781, the BitArray class contains unsafe code as a performance optimization. Since BitArray instances are not thread-safe, this opens the possibility that improper cross-thread access to a BitArray instance may result in global memory corruption.

We should modify the BitArray internal logic to be resilient against this possibility. We don't need to make the type thread-safe, but improper cross-thread access shouldn't be able to cause damage beyond corruption of the individual BitArray instances involved.

[benaadams]

Work on local array references rather than class references?

[GrabYourPitchforks]

@benaadams Yeah, that should work. I didn't want to be too prescriptive in the bug description. :)

[benaadams]

Also probably faster too :)

[mikedn]

Simply using local array references is not sufficient. You have to acquire the array and the length atomically but that's not really possible so the only solution is to validate the length once the 2 have been copied to local variables.

P.S. Though perhaps this isn't needed, it seems that the relevant operations use m_array's Length and not m_length so just copying the array to a local should be enough.