@dc0d: That shouldn't be an issue. Threads run synchronously, so as long as you're not doing anything within the lock that would cause another lock you're fine. In POSIX the mutex isn't reentrant either, and it doesn't cause problems in usage. Your SpinMutex isn't reentrant either. If you call Lock twice from the same thread you'll deadlock.
I found this, which is an interesting benchmark. http://blog.moxen.us/2010/08/22/lock-spinlock-and-compareexchange-performance/
His findings are different from yours, which shows that the performance characteristics are very dependent upon usage scenarios. In general, the Monitor is going to be a highly efficient synchronization mechanism. You've just discovered a scenario where there's probably low contention and the time in the lock is smaller than the overhead of the lock itself so the synchronization became your hotpoint (again, I assume you've profiled and know this to be true). That's exactly what SpinLock is for. There's not a huge difference between SpinLock and your SpinMutex in implementation, but the differences are likely to mean SpinLock will outperform your SpinMutex, and again, you won't have to maintain the code. Synchronization concepts are pretty heady, and any time you don't have to create your own and maintain it you'll be better off.
If this is truly a hotspot, though, I still contend lock free and/or pre-caching will provide you the best performance.