由於thread_yield只是在用戶空間中對線程調度程序的一個調用，所以它的運行非常快捷。這樣，mutex_lock和mutex_unlock都不需要任何內核調用。通過使用這些過程，用戶線程完全可以實現在用戶空間中的同步，這些過程僅僅需要少量的指令。
上面所敘述的互斥量系統是一套調用框架。對於軟件來說，總是需要更多的特性，而同步原語也不例外。例如，有時線程包提供一個調用mutex_trylock，這個調用或者獲得鎖或者返回失敗碼，但並不阻塞線程。這就給了調用線程一個靈活性，用以決定下一步做什麼，是使用替代辦法還只是等待下去。
到目前爲止，我們掩蓋了一個問題，不過現在還是有必要把這個問題提出來。在用戶級線程包中，多個線程訪問同一個互斥量是沒有問題的，因爲所有的線程都在一個公共地址空間中操作。但是，對於大多數早期解決方案，諸如Peterson算法和信號量等，都有一個未說明的前提，即這些多個進程至少應該訪問一些共享內存，也許僅僅是一個字。如果進程有不連續的地址空間，如我們始終提到的，那麼在Peterson算法、信號量或公共緩衝區中，它們如何共享turn變量呢？
有兩種方案。第一種，有些共享數據結構，如信號量，可以存放在內核中，並且只能通過系統調用來訪問。這種處理方式化解了上述問題。第二種，多數現代操作系統（包括UNIX和Windows）提供一種方法，讓進程與其他進程共享其部分地址空間。在這種方法中，緩衝區和其他數據結構可以共享。在最壞的情形下，如果沒有可共享的途徑，則可以使用共享文件。
如果兩個或多個進程共享其全部或大部分地址空間，進程和線程之間的差別就變得模糊起來，但無論怎樣，兩者的差別還是有的。共享一個公共地址空間的兩個進程仍舊有各自的打開文件、報警定時器以及其他一些單個進程的特性，而在單個進程中的線程，則共享進程全部的特性。另外，共享一個公共地址空間的多個進程決不會擁有用戶級線程的效率，這一點是不容置疑的，因爲內核還同其管理密切相關。