Most good OSes will briefly spin-wait on mutexes/critical sections and then context switch as necessary. So reinventing that wheel is kind of a waste.

I strongly suggest not messing with it until you are highly proficient with concurrent systems and understand them deeply. Moreover, it requires a very rich comprehension of how the OS and even hardware work to do lockless correctly. IMHO, suggesting lockless programming to someone who is not already very experienced with concurrency is utterly bad advice.

Quoted for emphasis.
I thought I had a very professional level of understanding regarding multi-threaded software, so I went off and wrote my own lock-free queue. Took me a month of weekends of debugging until I thought I had something solid...
After using my queue with no problems for 6 months (and having the unit tests run and succeed every day), it's unit test finally failed one day, due to a small bug!
Now, I've had years of practice doing it, and I'm still quote anxious whenever I'm doing any lock-free stuff. Definitely get some practice and do your homework before stepping into that arena! Also, I've seen a lot of implementations that make use of dynamic memory ([font=courier new,courier,monospace]new[/font]/[font=courier new,courier,monospace]malloc[/font]/etc), which locks anyway, defeating the point.