bjab的个人空间

tiamo：有些看不明白你这段话的意思.... 嗯..... 那个spinlock的使用只是在中断处理过程中 和KeSynchxxxx的时候才使用..... 这个两个地方都有KeRaiseIrql的调用 这两个调用是个spinlock本身不相关的 并不是spinloc...(2004-09-07 05:01)

回复

hangzhoustayer：是啊，照tiamo，lu0,arthurtu他们的说法，windows里面这个spinlock根本就应该叫spinlock(2004-09-06 21:02)

回复

Leopard：linux里面的spinlock实现似乎维持了spinlock的原始意义 (2004-09-06 18:34)

回复

hangzhoustayer：--------------------------------------------- 这个spin lock其实是可以运行在任意的irql上面的... 只是windows限制程序员在高irql上面使用spin lock... 而windows自己却高频率的在devic...(2004-09-06 14:16)

回复

wowocock：楼上的说法是不对的.... 单cpu上面spinlock只是把irql升到dispatch level...在我的机器上面他只是更新了os的irql并没有编程8259....不知道在有local apic的cpu上面...会是个什么样子... 同时....在比disp...(2004-09-04 10:03)

回复

tiamo：楼上的说法是不对的.... 单cpu上面spinlock只是把irql升到dispatch level...在我的机器上面他只是更新了os的irql并没有编程8259....不知道在有local apic的cpu上面...会是个什么样子... 同时....在比disp...(2004-09-03 23:40)

回复

hangzhoustayer：spinlock跟提升IRQL的本质还是不一样的吧，在单机上提升IRQL不能保证不被同样优先级的其它调用或更高优先级的代码来访问吧?(2004-09-03 14:16)

回复

bjab：那么现在假如就只有一个CPU呢？ 情况如何？(2004-05-27 15:25)

回复

slwqw：既然KeSynchronizeExcution上获得SPINLOCK 而在单CPU上SPINLOCK就是把IRQL提升DISPATCH_LEVEL 那么使用KeRaiseIrql提升到相应的硬件中断级别岂不是比把IRQL提升到DISPATCH_LEVEL更高 那...(2004-05-26 11:36)

回复

bjab：既然KeSynchronizeExcution上获得SPINLOCK 而在单CPU上SPINLOCK就是把IRQL提升DISPATCH_LEVEL 那么使用KeRaiseIrql提升到相应的硬件中断级别岂不是比把IRQL提升到DISPATCH_LEVEL更高 那...(2004-05-26 11:12)

回复