日度归档:2017 年 6 月 8 日

三维、四维及多维

看了一部豆瓣评价8.0,但个人觉得比较无聊的电脑,虽然没有体会到诗意的深刻,但捕捉到了一个概念。

小时候我们学习的时候知道了长宽高三维空间,后来我们知道了加上时间的四维空间。嗯这是电影里面理解到的地步。于是我开始想五维是什么?并行空间!那么更多维呢?

于是我想到了程序中的数组概念,再多维也能转换到一维!为什么?

一维数组[5]:xxxxx

二维数组[5][5]:xxxxx xxxxx xxxxx xxxxx xxxxx

三维数组[5][5][5]:xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx

四维数组[5][5][5]:5个并行的三维线型数组。

知道吗?这就是数组在内存的表示,内存的地址是线型的,所以不可能让你表示二维空间,任何维空间都会给你转换成线性空间。

从中我们可以得到:

  1. 增加一维,就相当于将前一维复制出这一维的长度。现实情况是,只有长的时候,你是一条线,当增加宽的时候,你需要把长的这条线复制宽倍。同样,长宽组成一个平面,当遇到高的时候,就把这个平面复制高的倍数。增加了时间会把这个长方体按连续的时间复制N倍…多维空间同样的道理。
  2. 再复杂的增加,如果每一个点可以使用数字表示,那么计算机可表示的维度将是无限的。但由于每增加一个维度,所占用的空间是所有维度长度的乘积,所以空间增加上是指数上升的。

以上是一点乱想

PV操作

至少有三次机会我可以把它学好,但还是对一些概念模糊

PV操作主要分两类:互斥和同步

简单讲,互斥的PV是同一个信号量,或者讲只有一个信号量。而同步的PV在同一段代码中是不同的信号量。同步一般是两个信号量。

那么信号量是什么?具体的概念书本上有,我这边理解信号量是指示队列的。因为如果简单把信号量定义成资源的个数,同步的时候完全可以只用一个信号量,因为池的大小是固定的,两个信号量就会浪费资源嘛。

这也是我一直不理解的地方,同步的时候为什么一直使用两个信号量。把信号量定义为指示队列的就好理解了。生产者消费者模式里面,生产者如果被阻塞就会形成一个阻塞队列,消费者如果被阻塞,了会形成一个消费者的队列。那么信号量S1就指示的是生产者的队列,如果等于负数就是队列中有进程等待,否则就没有进程等待。S2指示的是消费者的队列,如果为负数就表示队列中有消费者在等待,其绝对值就是等待消费者的个数。

PV里面一个重大的特点是阻塞进队列,唤醒队列中的进程。如P(S1),表示我会无论如何先减1,占用一个资源,如果资源还有,那么我就执行接下来的操作,如果资源没有了,那么我进队列。重点是后半部分的进入队列。如果同步只有一个信号量的话,就不能完成进队列和唤醒的操作。而消费者在消费完一个商品后,会执行V(S1),这个操作里面也有一个判断,如果S1的值是负数,则在执行完之后还要去生产者的队列唤醒一个进程。

其实在想不通为什么他们会这样做的时候,可以先把我们要解决的问题拿出来,看我有没有更好的办法去解决这个问题,一旦发现自己的理论不能解决这个问题的时候,你就会发现书本上提供方法的巧妙之处了。比如我一直觉得,同步模型完全可以使用一个信号量表示缓冲池空余的个数。先不说没办法统一定义PV的操作,光是两个队列都不好表示了,因为一个信号量只能真实反应池中空余的个数,并不能并未已经阻塞了多少生产者和多少消费者。当然有办法,可以再定义一个池的大小,这样也是两个变量,表面上更好理解了,但对PV的统一性造成了破坏。

互斥模型比较好理解,因为在同一做代码中,PV操作使用的是同一个信号量,这个信号量既表示了阻塞的队列,也能表示资源剩余的个数。因为大家都是同样的并行进程,所以大家都进入一个队列。

论文写作规范

有幸参加系统架构师的考试,正好有一个千载难逢的写论文机会,我一定要好好把握,尽管这次是为了应付考试,但谁又能说不是我通向论文的入门之中呢?

​写作的两部分:理论和实践

论文的题目是4选1,每个题目都会有一段描述和三个要求,第一个要求是统一的,就是要联系自己的职位和项目论述问题。第二个是最主要的,里面涉及到架构的方方面面。第三个也是可以部分套用的,就是总结一下自己所谈项目及对第二个问题的回答后,所取得的成就和不足的总结。

那么这篇论文就从上述两个方面展开。在项目方面,需要选择一个比较有典型性的项目,并且这个项目最好能够套用大部分架构的场景。这个项目可以事先准备好,以不变应万变。如果自己的项目比较多的话,要吧多准备两个。

其实我更关注是的理论的部分,实践的部分我们已经在工作中遇到更多,但理论的部分往往是我们忽略的。如软件工程中需要分析的几种方式,架构中的软件性能瓶颈及硬件性能瓶颈。上面两个也是我乱猜的两个,具体的还要看希赛给的论文范例,里面有各个方面所准备的范例。这也是我需要从这些论文中学习的东西:这些范例论文中是如何使用理论知识回答第二个问题的。如果这方面的问题解决了,剩下的问题就都不是问题了。

写作套路总结如下:

摘要  300-400字
项目概要 400-600字
开发项目的概要
开发的体制和“我”担任的工作
项目在系统设计方面的情况
把握用户需求的重要性 100-200字
采用过的手段 1000字-1400字
采取的手段中有效果的手段,效果体现在什么地方 200-300字
采取的手段中无效果的手段,为什么没有效果 200-300字
总结 100-200字