有两种基元构造：用户模式和内核模式。
应该尽量使用基元用户模式构造，因为它的速度明显高于后者。这是因为他们使用特殊的CPU指令来协调线程，这意味着协调是在硬件中发生的。但是，这也意味着win32系统永远无法检测到一个线程在一个基元用户模式构造上阻塞了。除此之外这些CPU指令只是阻塞线程极短的一些时间。而缺点就是：只有win系统内核能停止一个线程（以避免CPU时间）。在用户模式中运行的线程可能被系统抢占，但线程会以最快速度再次调度。所以，想要取得一个资源但是又暂时取不到，一个线程会在一直在用户模式中运行。这可能大量浪费CPU时间。
这使我们将目光转向基元内核模式构造。内核模式的构造是由win系统自身提供。所以他们要求你在应用程序中调用操作系统内核中实现的函数。将线程用用户模式转向内核模式（或相反）导致巨大性能损失。这正是避免使用内核模式构造的原因。但是他们有一个重要的优点：一个线程使用内核模型构造获取其他线程拥有的资源时，win会阻塞线程，使它不浪费CPU时间。然后当资源可用时，win会恢复线程，使它访问资源。
对于一个在构造上等待的线程，如果拥有这个构造的线程一直不释放它，前者就可能一直阻塞，如果是一个用户模式的构造，线程将一直在一个CPU线程上运行，我们称之为“活锁”，如果这是一个内核模式构造，线程将一直阻塞，我们称为“死锁”。但在两者之间，死锁总是优于活锁，因为活锁既浪费CPU时间，又浪费内存，而死锁只浪费内存。
而理想中的构造应该拥有两者的长处。也就是说，在没有竞争的情况下，这个构造应该快而且不会阻塞。但是，如果存在对构造的竞争，我希望他被操作系统内核阻塞。像这样的构造，确实存在，我们称之为混合构造。
CLR的许多线程构造只围绕win32的“线程同步构造”的一些面向对象的类包装器而已。比较CLR线程就是win线程。