linux scull 中的缺陷

让我们快速看一段 scull 内存管理代码. 在写逻辑的深处,scull 必须决定它请求的内 存是否已经分配. 处理这个任务的代码是:

?

if (!dptr->data[s_pos]) {

dptr->data[s_pos] = kmalloc(quantum,GFP_KERNEL); if (!dptr->data[s_pos])

goto out;

}

?

假设有 2 个进程( 我们会称它们为"A"和"B" ) 独立地试图写入同一个 schull 设备的相 同偏移. 每个进程同时到达上面片段的第一行的 if 测试. 如果被测试的指针是 NULL,每个进程都会决定分配内存,并且每个都会复制结果指针给 dptr->datat[s_pos]. 因为 2 个进程都在赋值给同一个位置,显然只有一个赋值可以成功.

?

当然,发生的是第 2 个完成赋值的进程将"胜出". 如果进程 A 先赋值,它的赋值将被进 程 B 覆盖. 在此,scull 将完全忘记 A 分配的内存; 它只有指向 B 的内存的指针. A 所分配的指针,因此,将被丢掉并且不再返回给系统.

?

事情的这个顺序是一个竞争情况的演示. 竞争情况是对共享数据的无控制存取的结果. 当 错误的存取模式发生了,产生了不希望的东西. 对于这里讨论的竞争情况,结果是内存泄 漏. 这已经足够坏了,但是竞争情况常常导致系统崩溃和数据损坏. 程序员可能被诱惑而 忽视竞争情况为相当低可能性的事件. 但是,在计算机世界,百万分之一的事件会每隔几 秒发生,并且后果会是严重的.

?

很快我们将去掉 scull 的竞争情况,但是首先我们需要对并发做一个更普遍的回顾.