标签：ons repos 死锁 上下 并发 说明 运行 else 内容
? 体系架构=组件+连接件+约束
? SoftwareArchitecture=Components+Connectors+Constrains
? 组件类型（例如：数据容器，过程，对象）
? 连接件类型/交互机制（例如：过程调用，事件，管道）
? 组件的拓扑分布
? 拓扑和行为的约束（例如：数据容器不能自己改变数据，管道不能是循环的）
? 风格的代价和益处（优缺点）
? 异质的风格 Heterogeneous style）： 一个系统是由不止一种风格构建的
实例：流水改卷
? 两种方法：
? 方式1：一位老师改完1分卷子，就传给下一位老师
? 方式2：一位老师改完整班卷子，再传给下一位老师
? 由数据控制计算
? 系统结构由数据在处理之间的有序移动决定
? 数据流系统的结构是比较明显的
? 在纯数据流系统中，处理之间除了数据交换，没有任何其他的交互
? 组件：
? 组件的接口是输入端口还是输出端口
? 计算模型：从输入中读取数据，计算，然后写到出口
? 连接件：单向，通常是异步有缓冲的
? 系统：
? 任意的拓扑结构
? 不同组件完成不同的功能
? 我们主要研究近似线性数据流或者是在限度内的循环数据流
? 如果一个软件系统的数据流的流向无序很可能说明该系统不应采用数据流的体系结构
?
每个组件 都有一组输入和输出，组件读取输入的数据流，经过内部处理，产生输出数据流。
这个过程通常通过对输入流的变换及增量计算来完成。
这里的组件成为过滤器，连接件像是对输入流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。
管道过滤器的通用结构：
过滤器的角色：
执行流式的转换
管道的角色
全部的操作
读取与处理数据流的方式
优点
使软件具有良好的隐蔽性和高内聚，低耦合的特点（过滤器可以看做是黑盒）
可将整个系统的I/O特性，理解为各个过滤器功能的简单合成。（多个地级过滤器可以合并成一个高级过滤器）
支持功能模块的重用（任意两个过滤器只要在相互所传输的数据格式上达成一致，就可以连接在一起）
系统易于维护和扩展（新的过滤器容易加入到系统中，旧的过滤器也可以被改进的过滤器替换）
支持某些特性属性的分析（入吞吐量和死锁检测）
支持多个过滤器的并发执行（适合多核/多线程环境）
理想情况下是组件之间只有数据依赖
缺点
批处理和管道过滤器这两种数据流风格，无法从拓扑结构上进行区分
比较：
相同点：
不同点：
| 批处理 | 管道过滤器 |
|---|---|
| 全部 | 增量 |
| 高延迟 | 立即有结果 |
| 输入随机访问 | 输入的处理是局部的 |
| 没有并发性 | 可能有反馈回路 |
| 没有交互性 | 有交互性 |
怎么选择：
考法：
开环控制
闭环控制
系统有反馈，不需要人进行反馈
两种形式：
当软件系统的运行受到外部干扰（软件不可见或不可控的力量或事件）的影响时，需要为软件体系结构考虑的一种过程控制方式。
和许多线性的数据流体系结构不同，控制环路体系结构需要有循环的拓扑结构
在什么情况下选择控制这种风格：
这种风格描绘很多系统
共同特点是共享数据
典型的例子：数据库、剪贴板、注册表
很容易增加数据的生产者和消费者
什么是黑板？
黑板的作用相当于“共享内存”，如同多位不同专长的专家在同一黑板上交流思想，每个专家都可以获得别的专家卸载黑板上的信息，同时也可以用自己的分析去更新黑板上的信息，从而影响其他专家。
解决无确定性求解策略问题
知识源（专家）
包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，他们之间的交互只通过黑板来完成，一个知识源只能解决问题的一部分
黑板数据结构
按照与应用程序相关的层次结构来组织的解决问题的数据，知识源利用黑板的借口对黑板进行读写，通过不断地改变黑板数据来解决问题
保存知识源要使用的数据
保存来自解空间的数据
分层；同层或者不同层的对象的之间的关联
与仓库的区别：
控制（仲裁者）
控制完全由黑板的状态驱动，监控黑板的变化，决定下一步选哪个知识源进行工作
Knowledge Sources
Blackboard Data Structure
Control
没有直接的算法可解
不确定性 uncertainty
问题没有唯一个解答，或者“正确”答案会变化
一种软件
创建了虚拟的环境
屏蔽了底层平台
分类：
组件：一个状态机（解释引擎）、三个存储区
连接件：过程调用/对存储区的数据访问
优点：
功能性 Functionality
测试性 Testing
灵活性 Flexibility
缺点：
效率 Efficiency
测试性 Testing
解释器和编译器的区别：
结构：
解决的问题：
基于规则的系统：一种特殊的虚拟机，使用模式匹配搜索来寻找规则，并在正确时机应用正确的规则
特点：
1引擎
3存储区
优点：
与解释器风格的不同：
常见的规则：
结构：
完成任务需要多个proc协同，proc间的协同通过msg完成，msg是显性的，即需要指明源和目的地。
组件间相对独立，依靠发消息通信。
模型：
解决方案
重要的变量
组件对事件进行订阅，并在事件被触发时得到通知。而事件并不知道都有谁订阅了自己。
隐式调用：
解决方案：
基于事件的隐式调用风格的思想：
构件不直接调用一个过程，而是触发一个或者多个时间
其他构件中的过程注册一个或多个事件，当一个事件被触发，系统自动调用在这个事件中注册的所有过程
构件是一些模块（过程，或者事件的集合）
主要特点是：事件的触发者并不知道哪些构件会被这些事件影响
优点：
问题分解：
系统维护和重用
性能
鲁棒性
核心思想：系统分解为多个低耦合的模块
缺点：
通过连接件绑定在一起的按照一组规则运行的并行构件网络。
（Heterogeneous Architectures）
聚合方式
联合放肆
混合方式
特点：
整体稳定，不会因为一点的错误影响全局
资源共享，任务分摊
对网络带宽占用极大
内容很难有效控制
?
标签：ons repos 死锁 上下 并发 说明 运行 else 内容
原文地址：https://www.cnblogs.com/share-sjb/p/8832918.html
