Sleep mutexes support priority propagation. Because of this behavior, sleep mutexes are not susceptible to the deadlock described above. If a thread attempts to acquire a sleep mutex that is being held by another thread, it will context switch (that is, sleep) and wait for the mutex to be released. Sleep mutexes are the most commonly used lock. Ordinarily, you’ll never use spin mutexes.
FREEBSD MEMINFO CPUINFO CODE
Spin mutexes should be held only for short periods of time and should be used only to protect objects related to nonpreemptive interrupts and low- level scheduling code (McKusick and Neville-Neil, 2005). Consequently, while holding a spin mutex all interrupts are blocked on the local processor and a context switch cannot be performed. This spinning can result in deadlock if a thread that is holding a spin lock is interrupted or if it context switches, and all subsequent threads attempt to acquire that lock. Spin, in this case, means to loop infinitely on the CPU. If a thread attempts to acquire a spin lock that is being held by another thread, it will “spin” and wait for the lock to be released. All waiters must pass the same lock in con- junction with cvp.
However, Giant may not be used as lock for the cvwaitunlock() function. Note that the Giant mutex may be specified as lock. The cv wait unlock() function does not reacquire the lock before returning. In addition, the thread will fully drop the Giant mutex (even if recursed) while the it is suspended and will reacquire the Giant mutex before the function returns. When a thread waits on a condition, lock is atomically released before the thread is blocked, then reacquired before the function call returns. A thread must hold lock before calling cv wait(), cvwait sig(), cv waitunlock(), cvtimedwait(), or cv timedwaitsig(). A mutex(9) argument must be initialized with MTX_DEF and not MTX_SPIN. The lock argument is a pointer to either mutex(9), rwlock(9), or sx(9) lock. 此外，使用 conditional variables必然涉及到 lock，以下是关于 lock的规则（下列内容摘自 FreeBSD Kernel Developer’s Manual）： Threads woken up in this manner reacquire foo before proceeding. A thread that causes the condition to be true wakes up the threads sleeping on bar. While asleep on bar, threads relinquish foo.
If the condition is false, it sleeps on the bar condition variable.
It works like this: A thread first acquires the foo lock. In contrast, locks synchronize threads by controlling their access to objects.Ĭondition variables are used in conjunction with locks to “block” threads until a condition is true. What is the equivalent of /proc/cpuinfo on FreeBSD v8.1?。 发布于 6月 10, 2017 6月 10, 2017 分类 技术 标签 cpu、 FreeBSD、 UNIX 于FreeBSD操作系统上获取CPU信息留下评论 FreeBSD kernel 笔记（13）-delaying executionĬondition variables synchronize the execution of two or more threads based upon the value of an object. Signature: Type 0, Family 6, Model 15, Stepping 6Ĭonfiguration: Enabled, Not Socketed, Level 1 （3）通过 dmidecode命令获得 CPU和 cache信息： # dmidecode -t processor -t cache （2）读取 /var/run/dmesg.boot文件： # grep -i cpu /var/run/dmesg.bootĬPU: Intel(R) Core(TM) 2.40GHz (2400.05-MHz K8-class CPU)įreeBSD/SMP: Multiprocessor System Detected: 2 CPUs （1）使用 sysctl命令： # sysctl hw.model hw.machine hw.ncpu There are other laptops, umpc’s, pda’s and other misc machines that are not on this list. Purpose : secondary workstation / ssh gateway
Linux uranus 2.6.23-gentoo-r3 #2 SMP Thu Dec 20 13:21: x86_64 Intel(R) Xeon(TM) CPU 3.00GHz GenuineIntel GNU/Linux Just a list of machines with some spec info:
0 kommentar(er)
