管程

管程               
信号量机制功能强大,但使用时对信号量的操作分散,而且难以控制,读写和维护都很困难。因此后来又提出了一种集中式同步进程——管程。其基本思想是将共享变量和对它们的操作集中在一个模块中,操作系统或并发程序就由这样的模块构成。这样模块之间联系清晰,便于维护和修改,易于保证正确性。
本节将从以下几个方面进行介绍--

一. 管程的概念

二. 实例

一. 管程的概念
1. 管程的形式

管程作为一个模块,它的类型定义如下:
    monitor_name = MoNITOR;
       共享变量说明;
       define 本管程内部定义、外部可调用的函数名表;
       use 本管程外部定义、内部可调用的函数名表;
       内部定义的函数说明和函数体
       {
         共享变量初始化语句;
       }

 


2. 管程的特点

从语言的角度看,管程主要有以下特性:
  (1)模块化。管程是一个基本程序单位,可以单独编译;
  (2)抽象数据类型。管程是中不仅有数据,而且有对数据的操作;
  (3)信息掩蔽。管程外可以调用管程内部定义的一些函数,但函数的具体实现外部不可见;
对于管程中定义的共享变量的所有操作都局限在管程中,外部只能通过调用管程的某些函数来间接访问这些变量。因此管程有很好的封装性。
为了保证共享变量的数据一致性,管程应互斥使用。 管程通常是用于管理资源的,因此管程中有进程等待队列和相应的等待和唤醒操作。在管程入口有一个等待队列,称为入口等待队列。当一个已进入管程的进程等待时,就释放管程的互斥使用权;当已进入管程的一个进程唤醒另一个进程时,两者必须有一个退出或停止使用管程。在管程内部,由于执行唤醒操作,可能存在多个等待进程(等待使用管程),称为紧急等待队列,它的优先级高于入口等待队列。
因此,一个进程进入管程之前要先申请,一般由管程提供一个enter过程;离开时释放使用权,如果紧急等待队列不空,则唤醒第一个等待者,一般也由管程提供外部过程leave。
管程内部有自己的等待机制。管程可以说明一种特殊的条件型变量:var c:condition;实际上是一个指针,指向一个等待该条件的PCB队列。对条件型变量可执行wait和signal操作:
    wait(c):若紧急等待队列不空,唤醒第一个等待者,否则释放管程使用权。执行本操作的进程进入C队列尾部;
    signal(c):若C队列为空,继续原进程,否则唤醒队列第一个等待者,自己进入紧急等待队列尾部。

 


二. 实例
1. 生产者-消费者问题(有buffer)

问题描述:(见信号量部分)
解答:
  管程:buffer=MODULE;
   (假设已实现一基本管程monitor,提供enter,leave,signal,wait等操作)
     notfull,notempty:condition;
       — notfull控制缓冲区不满,notempty控制缓冲区不空;
     count,in,out: integer;
       — count记录共有几件物品,in记录第一个空缓冲区,out记录第一个不空的缓冲区
     buf:array [0..k-1] of item_type;
     define deposit,fetch;
     use monitor.enter,monitor.leave,monitor.wait,monitor.signal;
    procedure deposit(item);
    {
       if(count=k) monitor.wait(notfull);
       buf[in]=item;
       in:=(in+1) mod k;
       count++;
       monitor.signal(notempty);
     }
    procedure fetch:Item_type;
    {
       if(count=0) monitor.wait(notempty);
       item=buf[out];
       in:=(in+1) mod k;
       count--;
       monitor.signal(notfull);
       return(item);
     }
    {
       count=0;
       in=0;
       out=0;
     }

  进程:producer,consumer;
  producer(生产者进程):
   Item_Type item;
  {
     while (true)
     {
       produce(&item);
       buffer.enter();
       buffer.deposit(item);
       buffer.leave();
     }
  }

  consumer(消费者进程):
   Item_Type item;
  {
     while (true)
     {
       buffer.enter();
       item=buffer.fetch();
        buffer.leave();
       consume(&item);
     }
   }


 


2. 第一类读-写者问题

问题描述:(见信号量部分)
解答:
  管程:bulletin=MODULE;
   (假设已实现一基本管程monitor,提供enter,leave,signal,wait等操作)
     r,w:condition;
       — r控制读者使用黑板,w控制写者;
     writing:boolean;
       — 当前是否写者使用黑板
     read_account:integer;
     define start_read,end_read,start_write,end_write;
     use monitor.enter,monitor.leave,monitor.wait,monitor.signal;
    procedure start_read();
    {
       if(writing) monitor.wait(r);
       read_account++;
       monitor.signal(r);
     }
    procedure end_read();
    {
       read_account--;
       if (read_account=0) monitor.signal(w);
     }
    procedure start_write();
    {
       if((read_account<>0) or writing) monitor.wait(w);
       writing=true;
     }
    procedure end_write();
    {
       writing=false;
       if (r<>NULL) monitor.signal(r);
       else monitor.signal(w);
     }

  进程:writer - 写者进程,reader - 读者进程
  reader - (读者进程):
  {
     while (true)
     {
       bulletin.enter();
       bulletin.start_read();
       read();
       bulletin.end_read();
       bulletin.leave();
     }
  }

  writer - (写者进程):
  {
     while (true)
     {
       bulletin.enter();
       bulletin.start_write();
       write();
       bulletin.end_write();
       bulletin.leave();
     }
   }


 


3. 哲学家问题

问题描述:(见信号量部分)
解答:
  管程:dining=MODULE;
   (假设已实现一基本管程monitor,提供enter,leave,signal,wait等操作)
     queue:array [0..4] of condition;
       — 控制哲学家能否进食;
     fork:array[0..4] of (free,use);
       — 当前各个叉子的状态
     define pickup,test,putdown;
     use monitor.enter,monitor.leave,monitor.wait,monitor.signal;
    procedure pickup(i:0..4);
    {
       if(fork[i]=used) monitor.wait(queue[i]);
       fork[i]=used;
     }
    procedure putdown(i:0..4);
    {
       fork[i]=free;
       monitor.signal(queue[i]);
     }
    procedure test(i:0..4):boolean;
    {
       if(fork[i]=use) ok=false
       else { fork[i]=use; ok=true; } ;
       return ok;
     }

  管程:dining=MODULE;
  philosopher(i:0..4);
  with_two_forks:boolean;
  {
     while (true)
     {
       think();
       with_two_forks=false;;
       while(!with_two_forks) {
         dining.enter();
         dining.pickup(i);
         if(dining.test((i+1) mod 5) with_two_forks=true;
         else dining.putdown(i);
         dining.leave();
       }
       eat();
       dining.enter();
       dining.putdown(i);
       dining.putdown((i+1) mod 5));
       dining.leave();
     }
  }
<think>嗯,用户想了解管程(Monitor)在并发编程中的缺点。首先我得回忆一下管程的基本概念管程是一种同步机制,用于控制多个线程对共享资源的访问,通常通过封装共享资源及其操作,并确保互斥访问。它的优点包括结构清晰、避免竞态条件,但用户现在关心的是缺点。 首先,我需要从已有的知识中整理管程足之处。可能的缺点包括性能问题,比如在高并发情况下管程可能导致线程阻塞,增加上下文切换的开销。另外,管程的实现可能复杂,尤其是在处理嵌套锁或条件变量时容易出错。还有,死锁的风险,如果多个线程获取锁的顺序一致,可能会引发死锁。此外,管程可能支持超时机制,导致线程无限等待,影响系统响应性。 然后,查看用户提供的引用内容,看看有没有相关的点可以支持。引用[1]提到临界区和竞态条件,这可能与管程处理互斥的方式有关,但管程本身就是为了解决这些问题,所以需要更深入分析其实现的局限性。引用[2]提到多核CPU并行执行线程的效率问题,可能涉及管程在并行扩展方面的足,比如锁的争用导致无法充分利用多核性能。引用[4]提到ConcurrentHashMap的设计考虑,虽然直接相关,但间接说明并发编程中需要考虑的复杂情况,可能管程在某些场景下够灵活。 接下来,需要组织这些点,确保每个缺点都有明确的解释和可能的例子。例如,性能瓶颈部分可以提到锁的争用导致线程阻塞,上下文切换频繁。复杂性方面,条件变量的正确使用需要谨慎,否则容易出错。死锁问题需要说明多个锁的获取顺序。扩展性差可能涉及无法有效利用多核资源,尤其是在大量线程时。此外,可能还要提到调试困难,因为并发问题难以复现。 还要考虑用户可能的背景,可能是开发者或学习并发编程的学生,他们需要实际应用中的问题,所以例子和代码片段会有帮助。比如,引用中的代码可能展示临界区的问题,但管程如何影响这些情况。 最后,生成相关问题时要围绕管程的缺点,引导用户进一步学习,比如替代方案、优化方法、实际应用中的问题等。</think>### 管程(Monitor)在并发编程中的缺点 管程(Monitor)是一种用于实现线程同步的机制,通过**封装共享资源**和**互斥访问**简化并发编程。然而,其存在以下核心缺点: --- #### 1. **性能瓶颈(锁竞争)** - **锁的粒度可控**:管程通常使用单一的互斥锁保护共享资源。当多个线程频繁竞争同一锁时,会导致**线程阻塞和上下文切换开销**[^1],降低系统吞吐量。 ```java synchronized void criticalSection() { // 高并发时,多个线程在此排队等待锁 } ``` - **无法并行化**:若临界区包含耗时操作(如I/O),锁的持有时间过长会显著降低多核CPU的并行效率[^2]。 --- #### 2. **复杂性(条件变量管理)** - **条件变量的错误使用**:需要精确管理条件变量(如`wait()`/`notify()`),否则易导致: - **死锁**:线程因条件未满足而永久阻塞。 - **虚假唤醒**:线程未收到明确信号却被唤醒,需通过循环检查条件[^3]。 ```java synchronized void consume() { while (buffer.isEmpty()) { // 必须用循环而非if判断 wait(); } // 消费逻辑 } ``` --- #### 3. **扩展性差** - **嵌套锁问题**:若管程内部需要调用其他同步方法,可能引发**嵌套锁请求**,增加死锁风险。 - **支持超时机制**:线程无法在指定时间内获取锁,可能因无限等待导致系统无响应。 --- #### 4. **调试困难** - **非确定性错误**:竞态条件和死锁问题难以复现和调试,尤其在大型系统中[^1]。 --- #### 5. **与硬件优化的冲突** - **内存可见性**:需依赖`synchronized`或`volatile`确保变量可见性,增加代码复杂性[^4]。 --- ### 替代方案与优化 - **细粒度锁**:如分段锁(ConcurrentHashMap的实现)。 - **无锁编程**:使用CAS(Compare-And-Swap)或原子类(`AtomicInteger`)。 - **响应式编程**:通过消息传递(如Actor模型)避免共享状态。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值