关于工程师的笑话

调侃工程师的笑话,多为工程师自娱自乐所为,其中逻辑及笑点也是非工程师所能深解,但好在工程师也不是什么高深的职业。

话说,某工刚下班,家里领导打来电话说:路上买三个馒头,看到西瓜买一个。结果等此工回到家时,领导看到他只买了一个馒头,并不是三个!

讲到此处,工程师们应该已笑开了怀。这则笑话以前就曾看过,后来,与朋友自驾浙江游玩时,一朋友又讲起此笑话,严格意义上当时只我一个算是个“工程师”,但这年头,是个知识分子,哪有没写过程序的?!所以全车人笑地还是异常热烈,特别是再经过“非工程师”人的诠释,以至这个如此简单的笑话几乎让我们笑了一路子。

还有个笑话:作家、物理学教授、和工程师开会回来,驾车驶进盘山小路,结果刹车失灵,车辆直冲而下,所幸为小树所阻,三人才得以死里逃生。从惊吓中恢复过来后,作家先发话说来灵感了,要将此次经历写成一部超惊险超刺激超恐怖的超现实体验主义小说;物理学教授也跟随,一定要搞出个数学模型来描述此次刹车片摩擦受热失灵的量子状态以及车辆带动力俯冲下山的动量矢能转换,话虽未说完但早已是一脸的急切;此时的工程师却是眉头紧缩,满脸疑惑地摇着头说:咱们为什么不再重现一次好找出问题的根本原因?

Continue reading » · Rating: · Written on: 06-28-12 · No Comments »

离奇事件薄之Irp死亡未遂

白天在外面耗了一整天,和各色朋友们讨论了一整天的新公司初创、经营、账务、税收等相关的问题,竟也蛮有兴致,也费了相当的口水,等回到家时间已很晚了,可精神却还是异常兴奋,只得爬起来找点事打发一下过剩的精力,第一直觉上便想到了前阵子曾遇到的一个稍许离奇的问题。

内容上可接承以前的一篇日志《离奇死亡事件薄之CoCreate篇》,于是继续取题《离奇事件薄》。细节如下:

驱动程序中要转向IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY,即Directory Enumeration操作,以方便处理此目录下所有的文件项。

由于会涉及文件I/O操作,不得不将操作移至系统线程中来做(至于为什么,请读者自己思考),所以在用户请求线程中不得不将原Irp请求的完成延后(pending),函数原型可简化成如下二个函数:

/* 用户线程环境:直接处理 IRP_MJ_DIR_CTRL / IRP_MN_QUERY_DIRECTORY */

NTSTATUS MyQueryDirectory(DevObj, Irp)

{

        ……
        MyQueueToSystemThread(DevObj, Irp);
        return STATUS_PENDING:

}

/* 系统线程,用以处理面向新路径(Dcb)的IRP_MN_QUEYR_DIRECTORY操作 */

NTSTATUS MySystemThreadHandler(DevObj, Irp)

{
        PIRP newIrp = IoAllocateIrp(newDevObj);
        ……
        IoCallDriver(newDevObj, newIrp);
        KeWaitForSingleObject(…):

        /* 处理返回的目录项 */
        ……
        /* 完成原用户的IRP请求 */
       IoCompleteRequest(irp, IO_NO_INCREMENT);

}

代码在逻辑上并没有问题,MySystemThreadHandler()正确获取目录项内容并实施对目标项的逐一检查,之后再完成用户所发的Irp请求,Irp的状态被系统(I/O Manager)修改为完成状态,此过程中并没有异常。但最早发出IRP_MJ_DIR_CTRL / IRP_MN_QUERY_DIRECTORY请求的用户线程却被永远地挂起来了,原Irp内容依然有效,虽然其状态已被标记为“完成”。

调试发现,由于系统线程优先级稍高,MySystemThreadHandler()完成Irp的操作竟然先于MyQueryDirectory()返回至I/O Manager。

执行顺序如下:
时间1:MyQueryDirectory() 添加一个新任务至系统线程队列
时间2:MyQueryDirectory() 被系统挂起了
时间3:系统线程执行MySystemThreadHandler()来处理时刻时间1所添加的任务
时间4:MySystemThreadHandler()执行完毕
时间5:原用户线程MyQueryDirectory()被唤醒,并返回STATUS_PENDING给I/O Manager

看到此序列,对于熟悉Irp操作规则的开发者来说,问题已经明了:显然是对此Irp的第二阶段用户线程环境相关的处理没有进行(Stage 2),也就是说,添加Kernel Apc的部分被跳过了。

一般Irp的完成要经过两个过程(可参见本文末所附文档链接):
Stage 1: IofCompleteRequest(): 完成与请求线程环境无关的操作
Stage 2: IopCompleteRequest(): 与Kernel Apc中执行,用以完成与请求线程相关的操作

之所以Stage 2的IopCompleteRequest会被跳过,有两方面的原因:

  1. Windows内核在处理IRP_MJ_DIR_CTRL/IRP_MN_QUERY_DIRECTORY请求时会默认加上标志位IRP_DEFER_IO_COMPLETION。据我所知,仅对DeviceIoControl操作不加此标志。当此标志位被设置的同时,如果Irp的Pending位没有设置,IoCompleteRequest()(此函数会调用IofCompleteRequest())则会直接返回,从面不在继续处理第二阶段(stage 2)。
  2. 原用户线程IoCallDriver()返回之后,由于返回值为STATUS_PENDING,I/O Manager将不在调用IopCompleteRequest()

所以二者同时跳过Stage 2,导致Irp的Stage 2处理不会再有机会执行,从而原用户线程也得不到被唤醒的机会了。

解决办法却是异常简单,在MyQueryDirectory()调用IoCallDriver()之前,或MySystemThreadHandler()调用IoCompleteRequest()之前将Irp设为PendingReturened非状态即可,此操作由系统支持函数IoMarkIrpPending()来做的。

最后,不妨再复习一下OSR介绍Irp操作的经典之作吧:《Secrets of the Universe Revealed! - How NT Handles I/O Completion

Continue reading » · Rating: · Written on: 06-28-12 · No Comments »