Chinaunix首页 | 论坛 | 博客
  • 博客访问: 76342
  • 博文数量: 172
  • 博客积分: 2047
  • 博客等级: 大尉
  • 技术积分: 1745
  • 用 户 组: 普通用户
  • 注册时间: 2010-05-19 15:23
文章分类

全部博文(172)

文章存档

2011年(72)

2010年(100)

我的朋友

分类: C/C++

2011-04-11 11:01:49

1、从编辑器打开文件的过程是先打开临时文件写入。然后将临时文件更名为当前文件名。
2、这样造成,如果打开临时文件,文件会依然可以找到。错误。
3、如果打开改名后的文件,会建立新的文件。

4、如果文件在release 的过程中打开了。n_links==0 才会释放。如果是读取了。

5、正在被使用的文件。需要一个地方存放起来。然后我们需要根据文件的使用状况,判断一些操作是否可以进行。

6、一个对象的生命周期。许多操作都需要使用这个对象。我们要全部考虑他们的情况。"不喜欢等待",这个喜好并不好。有的是事情必须一个个来。

7、不适用dir中的file对象。我们需要定期的清除dir。我们不确定它删除的时机。使用起来有了交集。file对象本身是否可以唯一存在。

8:file 对象的生命周期。正在被操作的文件对象
   开始:open一个文件。
   结束:正常release 一个文件。其他:unlink
   生命活动:write、read、runcate
   rename:从正在活动的map 中清理出来,需要添加另外一个。最好保证filemapusing的修改是锁住的。锁的第一个想到的对抗者就是效率。但是这里需要理性的分析。在整个的大环境下,考虑效率才能真正有帮助。需要考虑我们时间的单位,需要知道我们整个活动的时间。我们锁住部分的时间。这样会很清楚我们这样做到底有多大的影响。这是需要思考的。
   它对现在活动文件列表有影响。名字改掉了。如果其他对象要使用,那么就要另外一个名字。这里注意
更名应该在文件修改完毕后。这样,如果一个文件正在处于写后的release 中,那么他应该等待这个完毕。
我们可以让大家快点。但是如果出现了后面让程序会错误的情况。那么之前该等待的就放在这里了。这种策略应该是较为常用的。对效能的改变也很可观。

   严格约束条件:保证一个文件使用的过程中,无其他线程使用。大家必须有先后,
   在read 处本身是有锁存在的。如果是读取的正在修改的。
  
   失控:文件会一直被打开修改。没有release情况。文件一直是在使用状态。不会根据服务器做改动。
   事务中间存在的几个线条。运行期间有多个线程。有的线程是交互的,有的线程是没有关系的。这样形成了一组组的线程关系。这种关系让大家的关系变得宽松。处理的事务明确下来,事务边界是确定的。
   在实际使用的环境中,可能有一部分理想的东西是没有办法完全保证的。我们可能不愿去触碰这些。我们不得不允许它们存在。但是我们需要明确它们的范围。不能让本应该清楚的部分被分配成为这样。另外,我们需要在它们真的发生后,看能提供什么样的后续处理。保证情况还是正常的。

9、它好像是随意的,无序的。好像任何情况都有可能发生。实际上他是一个序列的组合。组合是有限的。但是它不是一两种,我们思考或者分析的方式局限在一两种的范围。所以无法分析它的全部。所以造成了我们总是只见到一部分。这种情况下,就有了开始的感觉。解决的方法很简单。把所有的情况都列出来,一一分析。分成两个步骤。1、根据收集的信息,把操作单元集合分析出来。根据集合的排序来任意组合。把组合中可能发生的情况标明。在这些情况中可能发生的问题。
   通用过程是这样。具体的情况下,有些问题的细节需要考虑。

10、我们设计的部分。和其他的模块有着关联。可能我们的一部分情况由于其他模块的影响不可能出现了。
这个时候我们有两种选择:分析其他的模块,明确哪些情况是不会发生的。我们根据这种情况做处理。另外我们不假设,按照通用的方式来处理。如,系统发送过来的请求可能进行了顺序的处理。我们可能不需要保证这样一部分。但如果我们自己处理的方式中又打乱了这种顺序,那么就需要同时保证顺序。另外,就算是会这样,我们依然提供同步保证。这样会让程序本身更独立。设计不会过分依赖与其他的模块。

11、编程不是什么都不做就可以搞定的。思维分析是必须的工具。
  
              
阅读(1201) | 评论(0) | 转发(0) |
0

上一篇:多线程lock测试

下一篇:解决问题

给主人留下些什么吧!~~