Comments by GWBas1c (Top 1 by date)

In my case I was performing volatile reads from a field, yet still getting old references. The code queueing an item in the threadpool was part of the loop assigning new values to the field, thus I couldn't imagine a way that the item on the threadpool could get an old version of the object unless it was reading it from a stale cache. Volatile didn't work; nor did copying the field's value into a closure for the threadpool anonymous delegate; nor did passing the correct value of the field as the "state" object to QueueUserWorkItem.

The only thing that worked was waiting for the old object to be garbage collected. Of course, if this was something other then an NUnit test, I would have taken a much different approach.

I do suspect VMware fusion, because I know that VM authors sometimes put in "optimizations" that break constrains that developers rely on. It could also be a compiler issue, debugger issue, ect, ect. What I do know, however, is that the "volatile" keyword was not being used as documented.