并发0-并发概论
2016-05-26 09:27
429 查看
介绍:
在传统的单CPU时代,每个CPU在某一个时间点只能运行一个程序,后来发展到多任务阶段,任务1和任务2两个任务可以在某一个时间范围“并发执行”,比如两个个任务交替执行100ms,在1s这个时间范围内,我们就认为他们其实在并发执行,但其实在某一个特定的时间点该CPU还是只能运行一个程序,这也就是为什么我们可以在电脑上同时听歌和浏览网页的原因,听歌和浏览网页两个程序在很短的时间交替执行。
任务1和任务2之间的快速地交替执行带来了在一定时间范围内的“并发效果”。这是任务1和任务2两个不同的程序的并发。
后来发展到多进程阶段,在一个程序内可以有多个线程并发执行,我们知道,线程是程序的执行单位,一个线程的执行可以认为是一个CPU在执行此程序。当一个程序运行在多线程下,就好像有多个CPU在同时执行该程序。现在假设我们有一个程序,分为线程1和线程2,线程1和线程2交替执行100ms,在1s这个时间范围内,我们就认为他们其实在并发执行,但其实在某一个特定的时间点CPU还是只能运行一个线程,这也就是为什么我们可以在听歌软件上点击按钮达到停止的原因,听歌软件的监听时间响应和播放音乐两个线程在很短的时间交替执行。
再后来,有了多核,我们还是套用刚才的例子,那么第一个CPU执行线程1,第二个CPU执行线程2,而不需要单CPU交替执行不同的任务了,这就是所谓的并行处理。
并发会带来什么问题:
我们所说的并发编程大多数时候指代单程序内的多线程并发。
这就会带来线程之间共享程序内存的问题。会有这样一种场景。程序1有一个num数值为1,其中线程1对其读取,线程2对其减1,那么线程1读取的结果有可能会有两种情况:
1.线程2操作之前的结果(为1)
2.线程2操作之后的结果(为0)
为什么需要并发:
CPU的数量有限,一定要物尽其用,尽量让其一直在高效运转,这应该是一个好的程序的标准之一。
我们用一个例子来说明:
server服务器在某一端口接听请求,当请求到来时,他去处理整个请求,处理完请求之后才继续监听。在服务器处理请求的这段时间内,所有的请求都不能被有效监听到
这是改进之后的代码,程序不仅仅只有接受请求的线程,还有一个专门处理请求的线程work thread,当服务器监听到请求之后,立即把请求分发给work thread,然后立即回到监听状态
多线程的代价:
任何事都是一把双刃剑,有好处必然也会有一定的坏处。多线程就有以下的坏处:
编程难度更高,需要处理资源同步问题
增加了程序的消耗,体现在CPU时间片切换,上下文切换等过程
并发模型与分布式系统的相似之处:
并发系统和分布式系统有一些相似之处:
并发系统中不同线程可以相互通信,可能分布在不同CPU之上。
分布式系统中不同服务可以相互通信,可能分布在不同机器上。
在传统的单CPU时代,每个CPU在某一个时间点只能运行一个程序,后来发展到多任务阶段,任务1和任务2两个任务可以在某一个时间范围“并发执行”,比如两个个任务交替执行100ms,在1s这个时间范围内,我们就认为他们其实在并发执行,但其实在某一个特定的时间点该CPU还是只能运行一个程序,这也就是为什么我们可以在电脑上同时听歌和浏览网页的原因,听歌和浏览网页两个程序在很短的时间交替执行。
任务1和任务2之间的快速地交替执行带来了在一定时间范围内的“并发效果”。这是任务1和任务2两个不同的程序的并发。
后来发展到多进程阶段,在一个程序内可以有多个线程并发执行,我们知道,线程是程序的执行单位,一个线程的执行可以认为是一个CPU在执行此程序。当一个程序运行在多线程下,就好像有多个CPU在同时执行该程序。现在假设我们有一个程序,分为线程1和线程2,线程1和线程2交替执行100ms,在1s这个时间范围内,我们就认为他们其实在并发执行,但其实在某一个特定的时间点CPU还是只能运行一个线程,这也就是为什么我们可以在听歌软件上点击按钮达到停止的原因,听歌软件的监听时间响应和播放音乐两个线程在很短的时间交替执行。
再后来,有了多核,我们还是套用刚才的例子,那么第一个CPU执行线程1,第二个CPU执行线程2,而不需要单CPU交替执行不同的任务了,这就是所谓的并行处理。
并发会带来什么问题:
我们所说的并发编程大多数时候指代单程序内的多线程并发。
这就会带来线程之间共享程序内存的问题。会有这样一种场景。程序1有一个num数值为1,其中线程1对其读取,线程2对其减1,那么线程1读取的结果有可能会有两种情况:
1.线程2操作之前的结果(为1)
2.线程2操作之后的结果(为0)
为什么需要并发:
CPU的数量有限,一定要物尽其用,尽量让其一直在高效运转,这应该是一个好的程序的标准之一。
我们用一个例子来说明:
while(sever is active){
liseten to request //监听请求
process request //处理请求--这段时间放弃监听请求
}
server服务器在某一端口接听请求,当请求到来时,他去处理整个请求,处理完请求之后才继续监听。在服务器处理请求的这段时间内,所有的请求都不能被有效监听到
while(server is active){
liseten to request
hander request to work thread
}
这是改进之后的代码,程序不仅仅只有接受请求的线程,还有一个专门处理请求的线程work thread,当服务器监听到请求之后,立即把请求分发给work thread,然后立即回到监听状态
多线程的代价:
任何事都是一把双刃剑,有好处必然也会有一定的坏处。多线程就有以下的坏处:
编程难度更高,需要处理资源同步问题
增加了程序的消耗,体现在CPU时间片切换,上下文切换等过程
并发模型与分布式系统的相似之处:
并发系统和分布式系统有一些相似之处:
并发系统中不同线程可以相互通信,可能分布在不同CPU之上。
分布式系统中不同服务可以相互通信,可能分布在不同机器上。
相关文章推荐
- 第十一周项目训练4
- 动态定义变量名
- 第12周项目1—实现复数类中的运算符重载 (3)
- 第十周上机时间项目——项目2—储存班长信息的学生类
- 点-圆-圆柱类族的设计
- 第十三周项目1分数类的重载
- 什么是DPDK
- linux 系统监控、诊断工具之 IO wait
- 单向散列函数
- MapReduce中的Join算法
- 使用putty可以访问centos的中文内容
- CentOS of MySQL command
- 安卓gridview 网格,多行多列实现
- 安卓gridview 网格,多行多列实现
- MVC之Ajax.BeginForm使用详解之更新列表
- 第十三周实践项目-阅读、修改和运行关于交通工具类的程序(1)
- 微信扫码支付+Asp.Net MVC
- 定位
- ios 代理
- 第十三周项目1——分数类中的运算符重载