- 2
- 0
- 约6.79千字
- 约 12页
- 2019-03-17 发布于安徽
- 举报
.
..
数据结构课程设计报告
姓 名:*** 学 号:200516104** 班 级:05级04班
所选课题:5、封锁资源管理子系统
目录
TOC \o 1-3 \h \z \u HYPERLINK \l _Toc201739282 需求分析: PAGEREF _Toc201739282 \h 1
HYPERLINK \l _Toc201739283 背景介绍 PAGEREF _Toc201739283 \h 1
HYPERLINK \l _Toc201739284 功能要求 PAGEREF _Toc201739284 \h 2
HYPERLINK \l _Toc201739285 概要设计 PAGEREF _Toc201739285 \h 3
HYPERLINK \l _Toc201739286 详细设计 PAGEREF _Toc201739286 \h 4
HYPERLINK \l _Toc201739287 调试分析 PAGEREF _Toc201739287 \h 7
1、需求分析:
1.1、背景介绍
在并发操作的系统中,许多用户可能同时对同一数据进行操作。并发操作带来的问题是数据的不一致性,并发控制的主要技术是封锁。
封锁资源管理子系统就是通过加锁来控制用户对系统资源的并发使用。基本的封锁类型有S锁(共享锁)和X锁(排他锁)。共享锁:用户A对资源R加上S锁,则只允许A读取R,但不能修改R,其它的用户只能再对R加S锁,直到A释放了R上的S锁。这就保证了其它用户可以读R但在A释放R上的S锁之前不能对R进行修改。排它锁:用户A对资源R加上锁,则只允许A读取和修改R其它用户不能再对R加任何锁,直到A释放了R上的锁。
两种封锁方式的相容矩阵如图所示:
S
X
S
OK
NO
X
NO
NO
相容矩阵
用户使用系统资源前必须申请封锁,即给出申请封锁的对象资源号、封锁方式和用户名。其中资源号是取值为一正整数。子系统受封锁请求,根据所保存的封锁状态信息决定请求是否能够获得封锁,进行相应处理,并向用户反馈处理结果。如果获得封锁,则赋给该请求一个批准号,可以使用该资源;否则需要进入等待队列(赋给该请求一个批准号)。
用户结束对某资源的使用后,应释放封锁(给出封锁对象的资源号和封锁批准号)。系统受理解锁请求时必须能迅速找到有关对象的封锁状况信息,以进行相应处理。
1.2、功能要求
1)、受理用户资源请求, 把用户添加进等待队列或活动队列
2)、受理用户释放资源请求
3)、查看资源活动队列
4)、查看资源等待队列
5)、查看系统所有资源
6)、添加资源
7)、用户读取使用资源
8)、用户修改资源
9)、添加用户
用列图如下:
2、概要设计
此部分为整个核心设计的流程,包括资源结构、用户结构、锁结构、等待队列、活动队列、资源高效存储查询的设计,及请求、释放、读、写资源的实现方式设计。
为满足高效存储、查询资源的要求,可采用散列表为资源建索引,并用链表解决冲突,存储的结构如下图所示:
封锁管理子系统示意图
其中散列表的元素对应为封锁对象,以对象的资源号为散列函数的自变量(即关键码值)。散列表中元素仅为一个指向封锁对象链表的指针。LO为封锁对象结点,对应于同一散列地址的封锁对象链接到一个链表中。LR为封锁请求结点。每个封锁对象结点带两个封锁请求队列:活动队列中为当前持有对该对象的封锁请求,等待队列中为正在等待对该对象进行封锁的封锁请求。LO结点和LR结点均向子系统自己管理的可利用空间表申请。
Hash函数采用求余的方法,在这个系统中应为资源的个数是不确定的,因此hash表的大小也可以随着资源数的不同而改变,我的设计是当记录的个数大于资源个数的五倍时hash表大小翻倍。
而S锁和X锁的设计则采用了多态的方法,设计一个公共的抽象基类:Lock里面定义了三个接口,XLock和SLock类都派生自这个类,这样就可以用一个指针来操作这两个不同的锁了。
而请求的批准号则是系统自动给的,用户可以通过查看资源的请求队列和活动队列获得批准号,等待队列和活动队列都是基于链表的,这样就不会浪费空间。
用户请求资源顺序图如下:
用户释放资源顺序图如下:
3、详细设计
1)、资源结构
class Resource
{
private:
bool x_flag;//X锁标记,为真表示已加X锁
bool s_flag;//S锁标记,为真表示已加S锁
ActiveQueue *aqueue;//对应资源的活动队列
WaitQueue *wqueue;//对应资源的等待队列vb vcb
stri
原创力文档

文档评论(0)