As Steven pointed out it is an implementation detail and these two concepts might be used together  (primarily for optimization). Switching to kernel mode (e.g. dealing with kernel objects like event, mutex, semaphore through system calls) is a very time costly operation, therefore some libs provide spinning optimizations, which do spinning (for some few cpu cycles) and if they are still unable to acquire a lock, they make a system call which changes into the kernel mode and finally puts the thread into the blocked state if the object is still not available (signaled, unlocked etc). But even so it is not black and white in the concurrency world. :( Some would like to achieve speed through such an optimization others would like to get rid of such an optimization. A good example might be an embedded app running on a battery driven HW, where energy plays a major role. Here wasting CPU cycles for speed optimization might not be a good idea... But anyway that should be separately evaluated. 

With Kind Regards,

Ovanes