How is NET 4.0 SpinWait method different to pre-4.0 SpinWait()?

Question

MSDN "Thread-Safe Collections .NET Framework 4" states:

"Some of the concurrent collection types use lightweight synchronization mechanisms such as SpinLock, SpinWait, SemaphoreSlim, and CountdownEvent, which are new in the .NET Framework 4"

while MSDN website tells that SpinWaitwas was available as far as .NET 1.1 while another MSDN article starts SpinWaitwas from .NET 4.0

Well, the curiosity is from the comment by Lee Grissom to answer What is the difference between SynchronizedCollection and the other concurrent collections?:

"@Matt, the .NET4 concurrent classes use SpinWait objects to address thread-safety instead of Monitor.Enter/Exit (aka Critical section)?"

as well as first NSDN quote stating that SpinWait is new to .NET 4.0

So, is it new or not?
And if new then how?

Kathernkatheryn

From looking at your links, and with no other knowledge, it seems that a SpinWait function was present in .NET 1.1 and the SpinWait structure was added in .NET 4.0 – Artist

Answer 1

The struct System.Threading.SpinWait is new to .NET 4.0. The method System.Threading.Thread.SpinWait() exists since .NET 1.0.

Note that System.Threading.SpinWait internally calls System.Threading.Thread.SpinWait(). For further details see "Concurrent Programming On Windows" by Joe Duffy (chapter 14, section "Spin Waiting").

Jab

Oh, again that book. No more .NET books on concurrency, just one? – Kathernkatheryn

Answer 2

The System.Threading.SpinWait structure was introduced into .NET 4. The System.Threading.Thread.SpinWait method has been present since .NET 1.0.

From the docs for the SpinWait structure:

SpinWait is not generally useful for ordinary applications. In most cases, you should use the synchronization classes provided by the .NET Framework, such as Monitor. For most purposes where spin waiting is required, however, the SpinWait type should be preferred over the SpinWait method.

Note the part that says you shouldn't be using either of them in most cases :)

Deanadeanda

Looks to me like all answers about thread-safety are thread-unsafe. Conspirating to deter me from multithreading progranning – Kathernkatheryn