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

我们很多人都用过标准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

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

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