一个并发或者称为锁的问题

晨曦之光 发布于 2012/04/10 15:06
阅读 47
收藏 0

我们很多人都用过标准io的write和read函数,我们先看看write函数的原形:
ssize_t write(int fildes, const void *buf, size_t nbyte)
这 里的buf为何是const?有没有const看似问题不大,但是对于并发来说确实是一个大问题,我们都知道,write最终进入系统调用进而进入 sys_write,进入sys_write之后一直到copy_from_user一直都没有操作buf,那么想象一种情况,如果这期间buf被改了怎 么办,程序的本意是写入改之前的buf,就是因为程序太信任库函数了才把buf交给write函数,但是buf却被改了,这样的话,写入文件的是修改前的 buf还是修改后的buf,按照常理来说,当然是修改前的buf了,但是谁能保证这一点呢?又是把保证这一点的工作交给谁呢?交给内核吗?内核忙着呢,根 本无暇管这些破事,那么交给用户吗?用户程序员能保证个个都是高手吗?不能!那么只有交给库函数,可是函数本身如果进行buf加锁动作的话就未免太耗时 了,难道为了避免少数人的无知就付出这么大的代价吗?当然不,那么怎么办呢?交给编译期是个不错的选择,这就产生了write参数的const。
这个问题到底是个机制问题还是个策略问题?如果是机制当然要交给内核,既然没有交给内核可见它不是什么机制,那么它就是一种策略了,实际上,保护buf是 用户行为也就是程序员工作的一部分,为了减轻程序员的负担才有了const一说,这只能说库的设计者想的比较周到。
现在我们想想这个问题,在没有多线程的环境里,const简直没有必要,即使有了多线程但是没有开启内核抢占的情况下,const似乎也没有多大意义,没 有内核抢占的情况下,只要进行系统调用进入内核,一切就安全了,除了中断这个杀手外谁也奈何我不得,但是现在的世界既有多线程又有内核抢占,甚至多核,多处理器已经成为趋势,并发的问题就凸现了出了。
还是我们多加些班来减轻库设计者的负担吧,他们够累了,给他们一些时间陪陪他们的妻子或丈夫吧,我们有薪水可拿,他们仅仅期待我们的认可,期待有一日我会得到如下的write接口:
write(char *buf).

//

回复:一个并发或者称为锁的问题 dog250

是啊,腺嘌呤,鸟嘌呤,胞嘧啶,胸腺嘧啶就这四样东西创造了整个人类世界,我们原来公司就有个哥们儿,自称自己精通EJB,Spring,还有什么持久层之类的,精通eclipse,可是却不会用命令行编译hello world,真事儿!真为我们的IT产业担心

回复:一个并发或者称为锁的问题 guosha

我也觉得很多人动不动谈什么架构设计模式很无趣,OS的常用的posix接口就那么一百多个,却不妨碍人们在上面开发出无数个程序。

回复:一个并发或者称为锁的问题 dog250

说的很对啊,接口的设计者一般都是高手,他们自己当然知道什么情况下会发生什么事,但是应用接口的人就是鱼龙混杂了,接口设计的好坏的评定标准之一就是“ 更容易被正确使用,更不容易被误用”,单进单出的接口当然最不容易引起混乱,“只做并且做好一件事”看来也是评定标准之一啊,这么看来设计接口的人要比应用接口的人考虑的事情要多得多,从这些原则上我更喜欢posix而不喜欢win32 API

回复:一个并发或者称为锁的问题 guosha

策略问题吧,最小权限原则,我们自己写接口时也该这么限定的。

回复:一个并发或者称为锁的问题 dog250

呵呵,我本身喜欢思考,又喜欢写些东西,就是手笨嘴笨脑子也不快,也只能乱吟一番,平时比较喜欢李白,鲁迅还有屈原他们,好像还有酒,呵呵

另外,想跟你交流的话,我以后就把所有文章都放到思想者和杂感里面啦,哈哈,和你交流总能让我再深入一些的考虑问题,感觉很不错


原文链接:http://blog.csdn.net/dog250/article/details/5302809
加载中
返回顶部
顶部