第 2 章进程管理

红太狼 2022-11-05 08:58 28阅读 0赞

# 第 2 章 进程管理 #

## 1、 组成、 特征 ##

### 1.1、思维导图 ###

![image-20201218085942983][]

### 1.2、进程的概念 ###

> **程序 & 进程**

程序： 是静态的， 就是个存放在磁盘里的可执行文件， 就是一系列的指令集合。

进程（Process） ： 是动态的， 是程序的一次执行过程 （同一个程序多次执行会对应多个进程）

![image-20201218093210186][]

--------------------

思考： 操作系统是这些进程的管理者， 它要怎么区分各个进程？

### 1.3、进程的组成——PCB ###

> **PCB 需要记录哪些信息呢？**

当进程被创建时， 操作系统会为该进程分配一个唯一的、 不重复的“身份证号” ——PID（Process ID， 进程ID）

操作系统要记录PID、 进程所属用户ID（UID） ，即基本的进程描述信息， 可以让操作系统区分各个进程

还要记录给进程分配了哪些资源，可用于实现操作系统对资源的管理 （如： 分配了多少内存、 正在使用哪些I/O设备、 正在使用哪些文件 ）

还要记录进程的运行情况，可用于实现操作系统对进程的控制、 调度（如： CPU使用时间、 磁盘使用情况、 网络流量使用情况等）

--------------------

这些信息都被保存在一个数据结构PCB （Process Control Block） 中， 即进程控制块操作系统需要对各个并发运行的进程进行管理， 但凡管理时所需要的信息， 都会被放在PCB中

--------------------

PCB是进程存在的唯一标志， 当进程被创建时， 操作系统为其创建PCB， 当进程结束时， 会回收其PCB。

操作系统对进程进行管理工作所需的信息都存在PCB中

![image-20201218093815262][]

> **Linux 中 PCB 的定义**

Linux 中 `task_struct` 结构体便是进程 PCB

struct task_struct {
        
    #ifdef CONFIG_THREAD_INFO_IN_TASK
        /*
         * For reasons of header soup (see current_thread_info()), this
         * must be the first element of task_struct.
         */
        struct thread_info      thread_info;
    #endif
        /* -1 unrunnable, 0 runnable, >0 stopped: */
        volatile long           state;
     
        /*
         * This begins the randomizable portion of task_struct. Only
         * scheduling-critical items should be added above here.
         */
        randomized_struct_fields_start
     
        void                *stack;
        refcount_t          usage;
        /* Per task flags (PF_*), defined further below: */
        unsigned int            flags;
        unsigned int            ptrace;
     
    #ifdef CONFIG_SMP
        struct llist_node       wake_entry;
        int             on_cpu;
    #ifdef CONFIG_THREAD_INFO_IN_TASK
        /* Current CPU: */
        unsigned int            cpu;
    #endif
        unsigned int            wakee_flips;
        unsigned long           wakee_flip_decay_ts;
        struct task_struct      *last_wakee;
     
        /*
         * recent_used_cpu is initially set as the last CPU used by a task
         * that wakes affine another task. Waker/wakee relationships can
         * push tasks around a CPU where each wakeup moves to the next one.
         * Tracking a recently used CPU allows a quick search for a recently
         * used CPU that may be idle.
         */
        int             recent_used_cpu;
        int             wake_cpu;
    #endif
        int             on_rq;
     
        int             prio;
        int             static_prio;
        int             normal_prio;
        unsigned int            rt_priority;
     
        const struct sched_class    *sched_class;
        struct sched_entity     se;
        struct sched_rt_entity      rt;
    #ifdef CONFIG_CGROUP_SCHED
        struct task_group       *sched_task_group;
    #endif
        struct sched_dl_entity      dl;
     
    #ifdef CONFIG_UCLAMP_TASK
        /* Clamp values requested for a scheduling entity */
        struct uclamp_se        uclamp_req[UCLAMP_CNT];
        /* Effective clamp values used for a scheduling entity */
        struct uclamp_se        uclamp[UCLAMP_CNT];
    #endif
     
    #ifdef CONFIG_PREEMPT_NOTIFIERS
        /* List of struct preempt_notifier: */
        struct hlist_head       preempt_notifiers;
    #endif
     
    #ifdef CONFIG_BLK_DEV_IO_TRACE
        unsigned int            btrace_seq;
    #endif
     
        unsigned int            policy;
        int             nr_cpus_allowed;
        const cpumask_t         *cpus_ptr;
        cpumask_t           cpus_mask;
     
    #ifdef CONFIG_PREEMPT_RCU
        int             rcu_read_lock_nesting;
        union rcu_special       rcu_read_unlock_special;
        struct list_head        rcu_node_entry;
        struct rcu_node         *rcu_blocked_node;
    #endif /* #ifdef CONFIG_PREEMPT_RCU */
     
    #ifdef CONFIG_TASKS_RCU
        unsigned long           rcu_tasks_nvcsw;
        u8              rcu_tasks_holdout;
        u8              rcu_tasks_idx;
        int             rcu_tasks_idle_cpu;
        struct list_head        rcu_tasks_holdout_list;
    #endif /* #ifdef CONFIG_TASKS_RCU */
     
        struct sched_info       sched_info;
     
        struct list_head        tasks;
    #ifdef CONFIG_SMP
        struct plist_node       pushable_tasks;
        struct rb_node          pushable_dl_tasks;
    #endif
     
        struct mm_struct        *mm;
        struct mm_struct        *active_mm;
     
        /* Per-thread vma caching: */
        struct vmacache         vmacache;
     
    #ifdef SPLIT_RSS_COUNTING
        struct task_rss_stat        rss_stat;
    #endif
        int             exit_state;
        int             exit_code;
        int             exit_signal;
        /* The signal sent when the parent dies: */
        int             pdeath_signal;
        /* JOBCTL_*, siglock protected: */
        unsigned long           jobctl;
     
        /* Used for emulating ABI behavior of previous Linux versions: */
        unsigned int            personality;
     
        /* Scheduler bits, serialized by scheduler locks: */
        unsigned            sched_reset_on_fork:1;
        unsigned            sched_contributes_to_load:1;
        unsigned            sched_migrated:1;
        unsigned            sched_remote_wakeup:1;
    #ifdef CONFIG_PSI
        unsigned            sched_psi_wake_requeue:1;
    #endif
     
        /* Force alignment to the next boundary: */
        unsigned            :0;
     
        /* Unserialized, strictly 'current' */
     
        /* Bit to tell LSMs we're in execve(): */
        unsigned            in_execve:1;
        unsigned            in_iowait:1;
    #ifndef TIF_RESTORE_SIGMASK
        unsigned            restore_sigmask:1;
    #endif
    #ifdef CONFIG_MEMCG
        unsigned            in_user_fault:1;
    #endif
    #ifdef CONFIG_COMPAT_BRK
        unsigned            brk_randomized:1;
    #endif
    #ifdef CONFIG_CGROUPS
        /* disallow userland-initiated cgroup migration */
        unsigned            no_cgroup_migration:1;
        /* task is frozen/stopped (used by the cgroup freezer) */
        unsigned            frozen:1;
    #endif
    #ifdef CONFIG_BLK_CGROUP
        /* to be used once the psi infrastructure lands upstream. */
        unsigned            use_memdelay:1;
    #endif
     
        unsigned long           atomic_flags; /* Flags requiring atomic access. */
     
        struct restart_block        restart_block;
     
        pid_t               pid;
        pid_t               tgid;
     
    #ifdef CONFIG_STACKPROTECTOR
        /* Canary value for the -fstack-protector GCC feature: */
        unsigned long           stack_canary;
    #endif
        /*
         * Pointers to the (original) parent process, youngest child, younger sibling,
         * older sibling, respectively.  (p->father can be replaced with
         * p->real_parent->pid)
         */
     
        /* Real parent process: */
        struct task_struct __rcu    *real_parent;
     
        /* Recipient of SIGCHLD, wait4() reports: */
        struct task_struct __rcu    *parent;
     
        /*
         * Children/sibling form the list of natural children:
         */
        struct list_head        children;
        struct list_head        sibling;
        struct task_struct      *group_leader;
     
        /*
         * 'ptraced' is the list of tasks this task is using ptrace() on.
         *
         * This includes both natural children and PTRACE_ATTACH targets.
         * 'ptrace_entry' is this task's link on the p->parent->ptraced list.
         */
        struct list_head        ptraced;
        struct list_head        ptrace_entry;
     
        /* PID/PID hash table linkage. */
        struct pid          *thread_pid;
        struct hlist_node       pid_links[PIDTYPE_MAX];
        struct list_head        thread_group;
        struct list_head        thread_node;
     
        struct completion       *vfork_done;
     
        /* CLONE_CHILD_SETTID: */
        int __user          *set_child_tid;
     
        /* CLONE_CHILD_CLEARTID: */
        int __user          *clear_child_tid;
     
        u64             utime;
        u64             stime;
    #ifdef CONFIG_ARCH_HAS_SCALED_CPUTIME
        u64             utimescaled;
        u64             stimescaled;
    #endif
        u64             gtime;
        struct prev_cputime     prev_cputime;
    #ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
        struct vtime            vtime;
    #endif
     
    #ifdef CONFIG_NO_HZ_FULL
        atomic_t            tick_dep_mask;
    #endif
        /* Context switch counts: */
        unsigned long           nvcsw;
        unsigned long           nivcsw;
     
        /* Monotonic time in nsecs: */
        u64             start_time;
     
        /* Boot based time in nsecs: */
        u64             start_boottime;
     
        /* MM fault and swap info: this can arguably be seen as either mm-specific or thread-specific: */
        unsigned long           min_flt;
        unsigned long           maj_flt;
     
        /* Empty if CONFIG_POSIX_CPUTIMERS=n */
        struct posix_cputimers      posix_cputimers;
     
        /* Process credentials: */
     
        /* Tracer's credentials at attach: */
        const struct cred __rcu     *ptracer_cred;
     
        /* Objective and real subjective task credentials (COW): */
        const struct cred __rcu     *real_cred;
     
        /* Effective (overridable) subjective task credentials (COW): */
        const struct cred __rcu     *cred;
     
    #ifdef CONFIG_KEYS
        /* Cached requested key. */
        struct key          *cached_requested_key;
    #endif
     
        /*
         * executable name, excluding path.
         *
         * - normally initialized setup_new_exec()
         * - access it with [gs]et_task_comm()
         * - lock it with task_lock()
         */
        char                comm[TASK_COMM_LEN];
     
        struct nameidata        *nameidata;
     
    #ifdef CONFIG_SYSVIPC
        struct sysv_sem         sysvsem;
        struct sysv_shm         sysvshm;
    #endif
    #ifdef CONFIG_DETECT_HUNG_TASK
        unsigned long           last_switch_count;
        unsigned long           last_switch_time;
    #endif
        /* Filesystem information: */
        struct fs_struct        *fs;
     
        /* Open file information: */
        struct files_struct     *files;
     
        /* Namespaces: */
        struct nsproxy          *nsproxy;
     
        /* Signal handlers: */
        struct signal_struct        *signal;
        struct sighand_struct       *sighand;
        sigset_t            blocked;
        sigset_t            real_blocked;
        /* Restored if set_restore_sigmask() was used: */
        sigset_t            saved_sigmask;
        struct sigpending       pending;
        unsigned long           sas_ss_sp;
        size_t              sas_ss_size;
        unsigned int            sas_ss_flags;
     
        struct callback_head        *task_works;
     
    #ifdef CONFIG_AUDIT
    #ifdef CONFIG_AUDITSYSCALL
        struct audit_context        *audit_context;
    #endif
        kuid_t              loginuid;
        unsigned int            sessionid;
    #endif
        struct seccomp          seccomp;
     
        /* Thread group tracking: */
        u32             parent_exec_id;
        u32             self_exec_id;
     
        /* Protection against (de-)allocation: mm, files, fs, tty, keyrings, mems_allowed, mempolicy: */
        spinlock_t          alloc_lock;
     
        /* Protection of the PI data structures: */
        raw_spinlock_t          pi_lock;
     
        struct wake_q_node      wake_q;
     
    #ifdef CONFIG_RT_MUTEXES
        /* PI waiters blocked on a rt_mutex held by this task: */
        struct rb_root_cached       pi_waiters;
        /* Updated under owner's pi_lock and rq lock */
        struct task_struct      *pi_top_task;
        /* Deadlock detection and priority inheritance handling: */
        struct rt_mutex_waiter      *pi_blocked_on;
    #endif
     
    #ifdef CONFIG_DEBUG_MUTEXES
        /* Mutex deadlock detection: */
        struct mutex_waiter     *blocked_on;
    #endif
     
    #ifdef CONFIG_DEBUG_ATOMIC_SLEEP
        int             non_block_count;
    #endif
     
    #ifdef CONFIG_TRACE_IRQFLAGS
        unsigned int            irq_events;
        unsigned long           hardirq_enable_ip;
        unsigned long           hardirq_disable_ip;
        unsigned int            hardirq_enable_event;
        unsigned int            hardirq_disable_event;
        int             hardirqs_enabled;
        int             hardirq_context;
        unsigned long           softirq_disable_ip;
        unsigned long           softirq_enable_ip;
        unsigned int            softirq_disable_event;
        unsigned int            softirq_enable_event;
        int             softirqs_enabled;
        int             softirq_context;
    #endif
     
    #ifdef CONFIG_LOCKDEP
    # define MAX_LOCK_DEPTH         48UL
        u64             curr_chain_key;
        int             lockdep_depth;
        unsigned int            lockdep_recursion;
        struct held_lock        held_locks[MAX_LOCK_DEPTH];
    #endif
     
    #ifdef CONFIG_UBSAN
        unsigned int            in_ubsan;
    #endif
     
        /* Journalling filesystem info: */
        void                *journal_info;
     
        /* Stacked block device info: */
        struct bio_list         *bio_list;
     
    #ifdef CONFIG_BLOCK
        /* Stack plugging: */
        struct blk_plug         *plug;
    #endif
     
        /* VM state: */
        struct reclaim_state        *reclaim_state;
     
        struct backing_dev_info     *backing_dev_info;
     
        struct io_context       *io_context;
     
    #ifdef CONFIG_COMPACTION
        struct capture_control      *capture_control;
    #endif
        /* Ptrace state: */
        unsigned long           ptrace_message;
        kernel_siginfo_t        *last_siginfo;
     
        struct task_io_accounting   ioac;
    #ifdef CONFIG_PSI
        /* Pressure stall state */
        unsigned int            psi_flags;
    #endif
    #ifdef CONFIG_TASK_XACCT
        /* Accumulated RSS usage: */
        u64             acct_rss_mem1;
        /* Accumulated virtual memory usage: */
        u64             acct_vm_mem1;
        /* stime + utime since last update: */
        u64             acct_timexpd;
    #endif
    #ifdef CONFIG_CPUSETS
        /* Protected by ->alloc_lock: */
        nodemask_t          mems_allowed;
        /* Seqence number to catch updates: */
        seqcount_t          mems_allowed_seq;
        int             cpuset_mem_spread_rotor;
        int             cpuset_slab_spread_rotor;
    #endif
    #ifdef CONFIG_CGROUPS
        /* Control Group info protected by css_set_lock: */
        struct css_set __rcu        *cgroups;
        /* cg_list protected by css_set_lock and tsk->alloc_lock: */
        struct list_head        cg_list;
    #endif
    #ifdef CONFIG_X86_CPU_RESCTRL
        u32             closid;
        u32             rmid;
    #endif
    #ifdef CONFIG_FUTEX
        struct robust_list_head __user  *robust_list;
    #ifdef CONFIG_COMPAT
        struct compat_robust_list_head __user *compat_robust_list;
    #endif
        struct list_head        pi_state_list;
        struct futex_pi_state       *pi_state_cache;
        struct mutex            futex_exit_mutex;
        unsigned int            futex_state;
    #endif
    #ifdef CONFIG_PERF_EVENTS
        struct perf_event_context   *perf_event_ctxp[perf_nr_task_contexts];
        struct mutex            perf_event_mutex;
        struct list_head        perf_event_list;
    #endif
    #ifdef CONFIG_DEBUG_PREEMPT
        unsigned long           preempt_disable_ip;
    #endif
    #ifdef CONFIG_NUMA
        /* Protected by alloc_lock: */
        struct mempolicy        *mempolicy;
        short               il_prev;
        short               pref_node_fork;
    #endif
    #ifdef CONFIG_NUMA_BALANCING
        int             numa_scan_seq;
        unsigned int            numa_scan_period;
        unsigned int            numa_scan_period_max;
        int             numa_preferred_nid;
        unsigned long           numa_migrate_retry;
        /* Migration stamp: */
        u64             node_stamp;
        u64             last_task_numa_placement;
        u64             last_sum_exec_runtime;
        struct callback_head        numa_work;
     
        /*
         * This pointer is only modified for current in syscall and
         * pagefault context (and for tasks being destroyed), so it can be read
         * from any of the following contexts:
         *  - RCU read-side critical section
         *  - current->numa_group from everywhere
         *  - task's runqueue locked, task not running
         */
        struct numa_group __rcu     *numa_group;
     
        /*
         * numa_faults is an array split into four regions:
         * faults_memory, faults_cpu, faults_memory_buffer, faults_cpu_buffer
         * in this precise order.
         *
         * faults_memory: Exponential decaying average of faults on a per-node
         * basis. Scheduling placement decisions are made based on these
         * counts. The values remain static for the duration of a PTE scan.
         * faults_cpu: Track the nodes the process was running on when a NUMA
         * hinting fault was incurred.
         * faults_memory_buffer and faults_cpu_buffer: Record faults per node
         * during the current scan window. When the scan completes, the counts
         * in faults_memory and faults_cpu decay and these values are copied.
         */
        unsigned long           *numa_faults;
        unsigned long           total_numa_faults;
     
        /*
         * numa_faults_locality tracks if faults recorded during the last
         * scan window were remote/local or failed to migrate. The task scan
         * period is adapted based on the locality of the faults with different
         * weights depending on whether they were shared or private faults
         */
        unsigned long           numa_faults_locality[3];
     
        unsigned long           numa_pages_migrated;
    #endif /* CONFIG_NUMA_BALANCING */
     
    #ifdef CONFIG_RSEQ
        struct rseq __user *rseq;
        u32 rseq_sig;
        /*
         * RmW on rseq_event_mask must be performed atomically
         * with respect to preemption.
         */
        unsigned long rseq_event_mask;
    #endif
     
        struct tlbflush_unmap_batch tlb_ubc;
     
        union {
        
            refcount_t      rcu_users;
            struct rcu_head     rcu;
        };
     
        /* Cache last used pipe for splice(): */
        struct pipe_inode_info      *splice_pipe;
     
        struct page_frag        task_frag;
     
    #ifdef CONFIG_TASK_DELAY_ACCT
        struct task_delay_info      *delays;
    #endif
     
    #ifdef CONFIG_FAULT_INJECTION
        int             make_it_fail;
        unsigned int            fail_nth;
    #endif
        /*
         * When (nr_dirtied >= nr_dirtied_pause), it's time to call
         * balance_dirty_pages() for a dirty throttling pause:
         */
        int             nr_dirtied;
        int             nr_dirtied_pause;
        /* Start of a write-and-pause period: */
        unsigned long           dirty_paused_when;
     
    #ifdef CONFIG_LATENCYTOP
        int             latency_record_count;
        struct latency_record       latency_record[LT_SAVECOUNT];
    #endif
        /*
         * Time slack values; these are used to round up poll() and
         * select() etc timeout values. These are in nanoseconds.
         */
        u64             timer_slack_ns;
        u64             default_timer_slack_ns;
     
    #ifdef CONFIG_KASAN
        unsigned int            kasan_depth;
    #endif
     
    #ifdef CONFIG_FUNCTION_GRAPH_TRACER
        /* Index of current stored address in ret_stack: */
        int             curr_ret_stack;
        int             curr_ret_depth;
     
        /* Stack of return addresses for return function tracing: */
        struct ftrace_ret_stack     *ret_stack;
     
        /* Timestamp for last schedule: */
        unsigned long long      ftrace_timestamp;
     
        /*
         * Number of functions that haven't been traced
         * because of depth overrun:
         */
        atomic_t            trace_overrun;
     
        /* Pause tracing: */
        atomic_t            tracing_graph_pause;
    #endif
     
    #ifdef CONFIG_TRACING
        /* State flags for use by tracers: */
        unsigned long           trace;
     
        /* Bitmask and counter of trace recursion: */
        unsigned long           trace_recursion;
    #endif /* CONFIG_TRACING */
     
    #ifdef CONFIG_KCOV
        /* See kernel/kcov.c for more details. */
     
        /* Coverage collection mode enabled for this task (0 if disabled): */
        unsigned int            kcov_mode;
     
        /* Size of the kcov_area: */
        unsigned int            kcov_size;
     
        /* Buffer for coverage collection: */
        void                *kcov_area;
     
        /* KCOV descriptor wired with this task or NULL: */
        struct kcov         *kcov;
     
        /* KCOV common handle for remote coverage collection: */
        u64             kcov_handle;
     
        /* KCOV sequence number: */
        int             kcov_sequence;
    #endif
     
    #ifdef CONFIG_MEMCG
        struct mem_cgroup       *memcg_in_oom;
        gfp_t               memcg_oom_gfp_mask;
        int             memcg_oom_order;
     
        /* Number of pages to reclaim on returning to userland: */
        unsigned int            memcg_nr_pages_over_high;
     
        /* Used by memcontrol for targeted memcg charge: */
        struct mem_cgroup       *active_memcg;
    #endif
     
    #ifdef CONFIG_BLK_CGROUP
        struct request_queue        *throttle_queue;
    #endif
     
    #ifdef CONFIG_UPROBES
        struct uprobe_task      *utask;
    #endif
    #if defined(CONFIG_BCACHE) || defined(CONFIG_BCACHE_MODULE)
        unsigned int            sequential_io;
        unsigned int            sequential_io_avg;
    #endif
    #ifdef CONFIG_DEBUG_ATOMIC_SLEEP
        unsigned long           task_state_change;
    #endif
        int             pagefault_disabled;
    #ifdef CONFIG_MMU
        struct task_struct      *oom_reaper_list;
    #endif
    #ifdef CONFIG_VMAP_STACK
        struct vm_struct        *stack_vm_area;
    #endif
    #ifdef CONFIG_THREAD_INFO_IN_TASK
        /* A live task holds one reference: */
        refcount_t          stack_refcount;
    #endif
    #ifdef CONFIG_LIVEPATCH
        int patch_state;
    #endif
    #ifdef CONFIG_SECURITY
        /* Used by LSM modules for access restriction: */
        void                *security;
    #endif
     
    #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
        unsigned long           lowest_stack;
        unsigned long           prev_lowest_stack;
    #endif
     
        /*
         * New fields for task_struct should be added above here, so that
         * they are included in the randomized portion of task_struct.
         */
        randomized_struct_fields_end
     
        /* CPU-specific state of this task: */
        struct thread_struct        thread;
     
        /*
         * WARNING: on x86, 'thread_struct' contains a variable-sized
         * structure.  It *MUST* be at the end of 'task_struct'.
         *
         * Do not put anything below here!
         */
    };

### 1.4、程序是如何运行的？ ###

> **源文件 → 可执行文件 → 载入内存**

一个进程实体（进程映像） 由PCB、 程序段、 数据段组成。

进程是动态的， 进程实体（进程映像） 是静态的。

进程实体反应了进程在某一时刻的状态（如： x++后， x=2）

![image-20201218094011860][]

### 1.5、进程的组成 ###

> **PCB & 程序段 & 数据段**

更确切的说， 应该是“进程实体(进程映像)的组成”

PCB 是给操作系统用的

程序段、 数据段是给进程自己用的，与进程自身的运行逻辑有关

![image-20201218094042707][]

> **进程实体的概念**

1.  程序段、 数据段、 PCB三部分组成了进程实体（进程映像）
2.  引入进程实体的概念后， 可把进程定义为：进程是进程实体的运行过程， 是系统进行资源分配和调度（一个进程被“调度” ， 就是指操作系统决定让这个进程上CPU运行）的一个独立单位
3.  注意： PCB是进程存在的唯一标志！ 同时挂三个QQ号， 会对应三个QQ进程， 它们的PCB、 数据段各不相同， 但程序段的内容都是相同的（都是运行着相同的QQ程序）

### 1.6、进程的特征 ###

> **动态性 & 异步性**

程序是静态的， 进程是动态的， 相比于程序， 进程拥有以下特征：

1.  动态性是进程最基本的特征
2.  异步性会导致并发程序执行结果的不确定性。具体会在“进程同步”相关小节进行学习

![image-20201218094234026][]

### 1.7、本节课小结 ###

**注意事项**

1.  严谨的说应该是：进程实体（进程映像） 的组成
2.  PCB是进程存在的唯一标志
3.  进程的管理者（操作系统）所需的数据都在PCB中

![image-20201218094321580][]

## 2、进程的状态与转换 ##

### 2.1、思维导图 ###

![image-20201218094556826][]

### 2.2、进程的五种状态 ###

**思考**：什么情况下需要转换进程状态？

![image-20201218132154347][]

#### 2.2.1、进程的状态——三种基本状态 ####

> **进程状态的划分**

**为什么需要对进程的状态进行划分？**

进程是程序的一次执行。 在这个执行过程中， 有时进程正在被CPU处理， 有时又需要等待CPU服务， 可见，进程的状态是会有各种变化。 为了方便对各个进程的管理， 操作系统需要将进程合理地划分为几种状态。

--------------------

**进程的三种基本状态**

进程的三种基本状态（进程的整个生命周期中， 大部分时间都处于三种基本状态）：

1.  运行态：注意： 单核处理机环境下， 每一时刻最多只有一个进程处于运行态。 （双核环境下可以同时有两个进程处于运行态）
2.  就绪态：进程已经拥有了除处理机之外所有需要的资源， 一旦获得处理机，即可立即进入运行态开始运行。即： 万事俱备， 只欠CPU
3.  阻塞态：如： 等待操作系统分配打印机、 等待读磁盘操作的结果。 CPU是计算机中最昂贵的部件， 为了提高CPU的利用率， 需要先将其他进程需要的资源分配到位， 才能得到CPU的服务

![image-20201218132009062][]

--------------------

**如何表示进程的状态 → state 变量记录**

进程PCB中， 会有一个变量 state 来表示进程的当前状态。 如： 1表示创建态、 2表示就绪态、 3表示运行态…

> **1、进程的状态——运行态**

系统中可能会有很多个进程都处于就绪态，当CPU空闲时， 操作系统就会选择一个就绪进程，让它上处理机运行

如果一个进程此时在CPU上运行， 那么这个进程处于“运行态” 。CPU会执行该进程对应的程序（执行指令序列）

> **2、进程的状态——阻塞态**

当处理机上运行的进程需要请求系统资源时，比如执行某条指令发出系统调用，请求使用打印机资源，而此时打印机正处于忙碌状态，那么在获得所需资源之前， 进程无法再往下执行

![image-20201218134618372][]

--------------------

**进入阻塞态**：

在进程运行的过程中， 可能会请求等待某个事件的发生（如等待某种系统资源的分配， 或者等待其他进程的响应） 。

在这个事件发生之前， 进程无法继续往下执行， 此时操作系统会让这个进程下CPU， 并让它进入“阻塞态”

--------------------

**进入就绪态**：

当CPU空闲时， 又会选择另一个“就绪态” 进程上CPU运行

当等待的事件发生时， 进程从“阻塞态”回到“就绪态”

![image-20201218135012834][]

> **3、进程的状态——终止态**

一个进程可以执行 exit 系统调用， 请求操作系统终止该进程。此时该进程会进入“终止态” ， 操作系统会让该进程下CPU，并回收内存空间等资源， 最后还要回收该进程的PCB。当终止进程的工作完成之后， 这个进程就彻底消失了。

![image-20201218135038780][]

#### 2.2.2、进程的状态——另外两种状态 ####

> **创建态与终止态**

1.  创建态：操作系统需要完成创建进程。 操作系统为该进程分配所需的内存空间等系统资源， 并为其创建、初始化PCB（如： 为进程分配 PID）
2.  终止态：进程运行结束（或者由于bug导致进程无法继续执行下去， 比如数组越界错误） ， 需要撤销进程。操作系统需要完成创建进程。 操作系统需要完成撤销进程相关的工作。 完成将分配给进程的资源回收， 撤销进程PCB等工作

![image-20201218132112376][]

> **1、创建态**

进程正在被创建时， 它的状态是“创建态” ， 在这个阶段操作系统会为进程分配资源、 初始化PCB

![image-20201218132726292][]

> **2、就绪态**

当进程创建完成后， 便进入“就绪态” ，处于就绪态的进程已经具备运行条件，但由于没有空闲CPU， 就暂时不能运行

![image-20201218132739661][]

### 2.3、进程状态的转换 ###

> **进程五状态模型**

1.  新建一个进程后，这个进程就处于创建态
2.  当系统完成创建进程的一系列工作之后，便会进入就绪态，处于就绪态的进程只差处理机资源，其他资源一应俱全
3.  当执行进行调度，处于就绪态的进程就有可能获得处理机资源，变为运行态
4.  当进程使用系统调用的方式申请系统资源时或者请求等待某件事情发生时（一句话，需要等待），便会从运行态变为阻塞态，这是一种进程自身做出的主动退让处理机资源的行为
5.  当申请的资源被分配或者等待的时间发生时（一句话，资源到位），进程便会从阻塞太变为就绪态，这不是进城自身能控制的（进程都没有在运行，它哪有能力去控制），是一种被动的行为
6.  当时间片到或者处理机被其他进程抢占时，进程会直接从运行态转变为就绪态（其他资源都不差，就差处理机资源）

![image-20201218135136328][]

--------------------

**注意**：

不能由阻塞态直接转换为运行态，也不能由就绪态直接转换为阻塞态（因为进入阻塞态是进程主动请求的， 必然需要进程在运行时才能发出这种请求）

### 2.4、进程的组织 ###

**导图**

![image-20201218142556495][]

#### 2.4.1、进程的组织——链接方式 ####

**通过队列管理进程**

1.  为了对同一个状态下的各个进程进行统一的管理， 操作系统会将各个进程的PCB组织起来。大多数操作系统使用率链接方式管理进程，链接方式将同一种状态的进程放在队列中进行管理
2.  执行指针：指向当前处于运行态（执行态） 的进程，单CPU计算机中， 同一时刻只会有一个进程处于运行态
3.  就绪队列指针：指向当前处于就绪态的进程，通常会把优先级高的进程放在队头
4.  阻塞队列指针：指向当前处于阻塞态的进程，很多操作系统还会根据阻塞原因不同， 再分为多个阻塞队列

![image-20201218141927600][]

--------------------

**根据阻塞原因不同**，将阻塞队列进行分类

![image-20201218142229188][]

#### 2.4.2、进程的组织——索引方式 ####

**通过索引的方式管理进程**

![image-20201218142310200][]

### 2.5、本节课小结 ###

![image-20201218142608986][]

## 3、进程控制 ##

### 3.1、思维导图 ###

![image-20201218143322931][]

### 3.2、什么是进程控制？ ###

> **进程控制的功能**

进程控制的主要功能是对系统中的所有进程实施有效的管理， 它具有创建新进程、 撤销已有进程、 实现进程状态转换等功能。

简化理解： 反正进程控制就是要实现进程状态转换

![image-20201218143404330][]

### 3.3、如何实现进程控制？ ###

> **原语实现进程控制**

用“原语” 实现进程控制，原语的执行具有“原子性” ， 一气呵成

原语是一种特殊的程序，它的执行具有原子性。也就是说， 这段程序的运行必须一气呵成， 不可中断

![image-20201218143446378][]

--------------------

**思考**： 为何进程控制（状态转换） 的过程要“一气呵成” ？

**解答**：如果不能“一气呵成” ， 就有可能导致操作系统中的某些关键数据结构信息不统一的情况，这会影响操作系统进行别的管理工作，可以用“原语”来实现“一气呵成” 啊汪！

--------------------

**举个栗子：**

Eg： 假设PCB中的变量 state 表示进程当前所处状态， 1表示就绪态， 2表示阻塞态…

![image-20201218143732086][]

假设此时进程2等待的事件发生， 则操作系统中， 负责进程控制的内核程序至少需要做这样两件事：

1.  将PCB2的 state 设为 1（假设完成了第一步后收到中断信号， 那么PCB2的state=1， 但是它却被放在阻塞队列里 ）
2.  将PCB2从阻塞队列放到就绪队列

也即上述两件事情必须一同执行，不能被打断

![image-20201218143748962][]

### 3.4、如何实现原语的“原子性” ？ ###

> **开关中断保证原子性**

原语的执行具有原子性， 即执行过程只能一气呵成， 期间不允许被中断。可以用 “关中断指令” 和“开中断指令” 这两个特权指令实现原子性

--------------------

**正常情况**：

CPU每执行完一条指令都会例行检查是否有中断信号需要处理， 如果有，则暂停运行当前这段程序， 转而执行相应的中断处理程序。

![image-20201218143938249][]

--------------------

**关闭中断的情况下**：

CPU执行了关中断指令之后， 就不再例行检查中断信号， 直到执行开中断指令之后才会恢复检查。这样， 关中断、 开中断 之间的这些指令序列就是不可被中断的， 这就实现了“原子性”

![image-20201218144017799][]

--------------------

**思考**： 如果这两个特权指令允许用户程序使用的话， 会发生什么情况？

**解答**：如果在应用程序的开始部分执行关中断指令，然后在程序的结束部分执行开中断指令，那么应用程序就能独占 CPU 了，仿佛在想 peach。所以只能让内核程序使用 “关中断指令” 和“开中断指令” ，绝不能让应用程序使用这两个特权指令

### 3.5、进程控制相关的原语 ###

#### 3.5.1、进程的创建 ####

> **创建原语：操作系统创建一个进程时使用的原语**

将进程 PCB 插入到就绪队列时，就证明进程已经从创建态转变为用户态了

![image-20201218144256367][]

#### 3.5.2、进程的终止 ####

> **撤销原语：进程由就绪态/阻塞态/运行态 → 终止态 → 无**

进程之间的关系为树形结构的关系，在终止进程时需要终止其所有子进程

![image-20201218144407550][]

> **引起进程终止的事件：**

1.  正常终止：进程自己请求终止（exit系统调用）
2.  异常结束：整数除以0、 非法使用特权指令，然后被操作系统强行杀掉
3.  外界干预：Ctrl+Alt+delete， 用户选择杀掉进程

#### 3.5.3、进程的阻塞和唤醒 ####

> **阻塞原语 & 唤醒原语**

阻塞原语：运行态 → 阻塞态

唤醒原语：阻塞态 → 运行态

因为何事阻塞，就应该由何事唤醒，因此阻塞原语唤醒原语必须成对使用

![image-20201218144639414][]

#### 3.5.4、进程的切换 ####

> **切换原语**

1.  运行态 → 就绪态
2.  就绪态 → 运行态

![image-20201218144902747][]

--------------------

**保存进程上下文至 PCB 中**

切换时需要将运行环境，即将进程上下文 Context）保存至进程的 PCB 中，主要就是存储寄存器的值。当需要切换回来时，再根据 PCB 恢复运行所需的环境即可

### 3.6、知识滚雪球： 程序是如何运行的？ ###

> **中间计算结果由寄存器暂存**

我们编写的一条高级语言，经编译后往往会生成多条机器语言

CPU 中会设置很多寄存器的值，用于存放中间计算结果

![image-20201218145252330][]

--------------------

**比如**：

1.  PSW 程序状态字寄存器：内核态 & 用户态
2.  PC 程序计数器：存放下一条指令的地址
3.  IR 指令寄存器：存放当前正在执行的指令
4.  通用寄存器：存储一些其他的必要信息，比如运算的中间结果

![image-20201218145345123][]

当执行指令 2 的时候，IR 中存储指令 2，PC 中存储指令 3 的地址，通用寄存器临时存储变量 x 的值

![image-20201218145715294][]

在通用寄存器中执行完加 1 操作后，将寄存器中的值写回内存变量中

![image-20201218150502718][]

--------------------

**问**：为什么需要保存运行环境？

**答**：寄存器是所有进程所共享的资源，并不单独属于某个进程

--------------------

**思考**： 执行完指令3后，另一个进程开始上CPU运行。

**注意**： 另一个进程在运行过程中也会使用各个寄存器

**灵魂拷问**： 之后还怎么切换回之前的进程？ ？ ？ ？ 寄存器的值已经被另一个进程覆盖了

**解决办法**： 在进程切换时先在PCB中保存这个进程的运行环境（保存一些必要的寄存器信息），当原来的进程再次投入运行时， 可以通过PCB恢复它的运行环境

![image-20201218150505631][]

### 3.7、本节课小结 ###

> **进程控制所需要完成的三件事情**

进程控制会导致进程状态的转换。 无论哪个进程控制原语， 要做的无非三类事情：

1.  更新PCB中的信息
    
    1.  所有的进程控制原语一定都会修改进程状态标志
    2.  剥夺当前运行进程的CPU使用权必然需要保存其运行环境
    3.  某进程开始运行前必然要恢复期运行环境
2.  将PCB插入合适的队列
3.  分配/回收资源

![image-20201218145145641][]

## 4、进程通信 ##

### 4.1、思维导图 ###

![image-20201218150802851][]

### 4.2、什么是进程通信？ ###

> **进程通信需要完成什么任务？**

顾名思义， 进程通信就是指进程之间的信息交换。

进程是分配系统资源的单位（包括内存地址空间） ， 因此各进程拥有的内存地址空间相互独立。

为了保证安全， 一个进程不能直接访问另一个进程的地址空间。但是进程之间的信息交换又是必须实现的。为了保证进程间的安全通信， 操作系统提供了一些方法。

![image-20201218150837380][]

--------------------

**进程通信的方式**

![image-20201218150855646][]

### 4.3、进程通信——共享存储 ###

> **互斥访问共享存储区**

两个进程对共享空间的访问必须是互斥的（互斥访问通过操作系统提供的工具实现） 。

操作系统只负责提供共享空间和同步互斥工具（如P、 V操作）

![image-20201218150953309][]

> **共享存储的两种方式：**

1.  基于数据结构的共享：只能存放固定的数据结构，比如共享空间里只能放一个长度为10的数组。 这种共享方式速度慢、限制多， 是一种低级通信方式
2.  基于存储区的共享： 在内存中画出一块共享存储区， 数据的形式、 存放位置都由进程控制，而不是操作系统。 相比之下， 这种共享方式速度更快， 是一种高级通信方式。

![image-20201218151016526][]

### 4.4、进程通信——管道通信 ###

> **管道通信**

“管道” 是指用于连接读写进程的一个共享文件， 又名pipe文件。 其实就是在内存中开辟一个大小固定的缓冲区（特殊的共享空间），一般管道大小等于内存页面大小，在 Linux 中为 4KB

![image-20201218151228124][]

> **管道通信的特点**

1.  管道只能采用半双工通信（数据可双向通信，但同一时刻只能一发一收）， 某一时间段内只能实现单向的传输。 如果要实现双向同时通信， 则需要设置两个管道。
2.  各进程要互斥地访问管道。
3.  数据以字符流的形式写入管道， 当管道写满时， 写进程的write()系统调用将被阻塞， 等待读进程将数据取走。 当读进程将数据全部取走后， 管道变空， 此时读进程的read()系统调用将被阻塞。
4.  如果没写满， 就不允许读。 如果没读空， 就不允许写。
5.  数据一旦被读出， 就从管道中被抛弃（再也找不回来咯）， 这就意味着读进程最多只能有一个， 否则可能会有读错数据的情况。

### 4.5、进程通信——消息传递 ###

> **消息通信**

进程间的数据交换以格式化的消息（Message） 为单位。 进程通过操作系统提供的“发送消息/接收消息” 两个原语进行数据交换。

消息由消息头和消息体组成，消息头包括： 发送进程ID、 接受进程ID、 消息类型、 消息长度等格式化的信息（计算机网络中发送的“报文” 其实就是一种格式化的消息）

> **消息传递的两种方式**

1.  直接通信方式：消息直接挂到接收进程的消息缓冲队列上（发送方通过发送原语将消息挂到接收方消息换从队列的尾部，接收方通过接收原语接收消息）
2.  间接通信方式：消息要先发送到中间实体（信箱） 中， 因此也称“信箱通信方式” （发送方通过发送原语将消息发送到信箱中，接收方通过接收原语从信箱中接收消息）。 Eg： 计网中的电子邮件系统

![image-20201218151445286][]

### 4.6、本节课小结 ###

![image-20201218151839546][]

## 5、线程概念多线程模型 ##

### 5.1、思维导图 ###

![image-20201218151903125][]

### 5.2、什么是线程，为什么要引入线程？ ###

> **进程的弊端**

还没引入进程之前，系统中各个程序只能串行执行。 想象下，如果我们聊 QQ 的时候，并不能听音乐，这你能忍？？？

引入了进程之后… 虽然可知并发地执行进程，但是进程是程序的一次执行。但这些功能显然不可能是由一个程序顺序处理就能实现的。

那么 QQ 是如何做到边视频聊天，边文字聊天，还能边传送文件呢？？？

> **引入线程的好处**

有的进程可能需要“同时”做很多事，而传统的进程只能串行地执行一系列程序。为此，引入了“线程”，来增加并发度。

传统的进程是程序执行流的最小单位，引入线程后，线程成为了程序执行流的最小单位，即 CPU 的服务调度对象变为线程

> **可以把线程理解为“轻量级进程”。**

线程是一个基本的CPU执行单元，也是程序执行流的最小单位。引入线程之后，不仅是进程之间可以并发，进程内的各线程之间也可以并发，从而进一步提升了系统的并发度，使得一个进程内也可以并发处理各种任务（如QQ视频、文字聊天、传文件）

引入线程后，进程只作为除CPU之外的系统资源的分配单元（如打印机、内存地址空间等都是分配给进程的）。线程则作为处理机的分配单元。

### 5.3、引入线程机制后，有什么变化？ ###

> **类比图书馆看书**

去图书馆看书。桌子=处理机，人=进程，看不同的书=线程

切换进程运行环境：有一个不认识的人要用桌子，你需要你的书收走，他把自己的书放到桌上

同一进程内的线程切换=你的舍友要用这张书桌，可以不把桌子上的书收走

![image-20201218152437336][]

### 5.4、本节课总结 ###

![image-20201218152512650][]

## 6、线程的实现方式多线程模型 ##

### 6.1、思维导图 ###

![image-20201218152539820][]

### 6.2、线程的实现方式 ###

#### 6.2.1、用户级线程 ####

> **用户级线程（User-Level Thread, ULT）**

历史背景： 早期的操作系统（如： 早期Unix） 只支持进程，不支持线程。 当时的“线程” 是由线程库实现的

对于操作系统而言，只能看到进程，对于用户级线程，操作系统不能看见

![image-20201218152649895][]

> **理解用户级线程**

线程其实就是一段代码逻辑。下面三段代码逻辑上可以看作三个“线程” 。while 循环就是一个最弱智的“线程库” ， 线程库完成了对线程的管理工作（如调度） 。

![image-20201218152840806][]

> **灵魂拷问**

很多编程语言提供了强大的线程库， 可以实现线程的创建、 销毁、 调度等功能。

1.  线程的管理工作由谁来完成？线程库，不管操作系统的事
2.  线程切换是否需要CPU变态？不需要，都没有进到内核，变啥态。。。
3.  操作系统是否能意识到用户级线程的存在？在操作系统看来，用户级线程就是一坨代码，只有用户才能感知到用户级线程，操作系统感知不到

> **用户级线程的特点**

1.  用户级线程由应用程序通过线程库实现，所有的线程管理工作都由应用程序负责（包括线程切换）
2.  用户级线程中， 线程切换可以在用户态下即可完成， 无需操作系统干预。
3.  在用户看来， 是有多个线程。 但是在操作系统内核看来， 并意识不到线程的存在。“用户级线程” 就是“从用户视角看能看到的线程”

--------------------

> **用户级线程的优缺点**

**优点**： 用户级线程的切换在用户空间即可完成， 不需要切换到核心态， 线程管理的系统开销小， 效率高

**缺点**： 当一个用户级线程被阻塞后， 整个进程都会被阻塞（ 比如当视频聊天申请摄像头资源被阻塞时，其他用户线程也会被阻塞）， 并发度不高。 多个线程不可在多核处理机上并行运行（操作系统调度的基本单位仍然是进程）。

#### 6.2.2、内核级线程 ####

> **内核级线程（Kernel-Level Thread, KLT, 又称“内核支持的线程” ）**

内核级线程是由操作系统支持的线程

大多数现代操作系统都实现了内核级线程， 如 Windows、 Linux

![image-20201218153410524][]

> **灵魂拷问**

1.  线程的管理工作由谁来完成？操作系统呀
2.  线程切换是否需要CPU变态？进入了操作系统内核，会由用户态变为内核态
3.  操作系统是否能意识到内核级线程的存在？当然能看见呀

> **内核级线程的特点**

内核级线程的管理工作由操作系统内核完成。

线程调度、 切换等工作都由内核负责， 因此内核级线程的切换必然需要在核心态下才能完成。

操作系统会为每个内核级线程建立相应的TCB（Thread Control Block， 线程控制块） ，通过TCB对线程进行管理。 “内核级线程” 就是“从操作系统内核视角看能看到的线程”

> **内核级线程的优缺点**

**优点**： 当一个线程被阻塞后， 别的线程还可以继续执行， 并发能力强。 多线程可在多核处理机上并行执行。

**缺点**： 一个用户进程会占用多个内核级线程，线程切换由操作系统内核完成， 需要切换到核心态， 因此线程管理的成本高， 开销大。

### 6.3、多线程模型 ###

> **何为多线程模型？**

在支持内核级线程的系统中， 根据用户级线程和内核级线程的映射关系， 可以划分为几种多线程模型

#### 6.3.1、一对一模型 ####

> **一对一模型**

一个用户级线程映射到一个内核级线程。 每个用户进程有与用户级线程同数量的内核级线程。

> **一对一模型的优缺点**

**优点**： 当一个线程被阻塞后， 别的线程还可以继续执行， 并发能力强。 多线程可在多核处理机上并行执行。

**缺点**： 一个用户进程会占用多个内核级线程，线程切换由操作系统内核完成， 需要切换到核心态， 因此线程管理的成本高， 开销大。

![image-20201218153716209][]

#### 6.3.2、多对一模型 ####

> **多对一模型**

多个用户级线程映射到一个内核级线程。 且一个进程只被分配一个内核级线程。

优点： 用户级线程的切换在用户空间即可完成， 不需要切换到核心态， 线程管理的系统开销小， 效率高

> **多对一模型的缺点**

**缺点**： 当一个用户级线程被阻塞后， 整个进程都会被阻塞， 并发度不高。 多个线程不可在多核处理机上并行运行

**重点重点重点**：操作系统只“看得见” 内核级线程， 因此只有内核级线程才是处理机分配的单位。 该模型退化成了纯用户级线程模型，一个进程对应于一个内核级线程，对应于多个用户级线程

![image-20201218153809063][]

#### 6.3.3、多对多模型 ####

> **多对多模型**

n 用户及线程映射到 m 个内核级线程（n >= m） 。 每个用户进程对应 m 个内核级线程。

> **多对多模型的优点**

克服了多对一模型并发度不高的缺点（一个阻塞全体阻塞） ， 又克服了一对一模型中一个用户进程占用太多内核级线程， 开销太大的缺点。

![image-20201218154003391][]

> **形象理解多对多模型**

用户级线程是“代码逻辑” 的载体

内核级线程是“运行机会” 的载体（内核级线程才是处理机分配的单位。 例如： 多核CPU环境下， 左边这个进程最多能被分配两个核）

> **多对多模型的灵活性**

一段“代码逻辑” 只有获得了“运行机会” 才能被CPU执行

因为内核级线程中可以运行任意一个有映射关系的用户级线程代码， 只有两个内核级线程中正在运行的代码逻辑都阻塞时， 这个进程才会阻塞

使用多对多模型可以灵活为用户级线程分配内核级线程

### 6.4、本节课小结 ###

![image-20201218154153062][]

## 7、层次 ##

### 7.1、思维导图 ###

![image-20201221102853214][]

### 7.2、调度的基本概念 ###

> **调度要研究什么东东？**

当有一堆任务要处理，但由于资源有限，这些事情没法同时处理。这就需要确定某种规则来决定处理这些任务的顺序，这就是“调度”研究的问题。

--------------------

**举个栗子**

1.  银行排队调度
    
    ![image-20201221104423839][]
2.  厕所排队调度
    
    ![image-20201221104439086][]

### 7.3、调度的三个层次——高级调度 ###

> **作业的概念**

作业：一个具体的任务。用户向系统提交一个作业 ≈ 用户让操作系统启动一个程序（来处理一个具体的任务）

![image-20201221104546598][]

> **高级调度（作业调度）**

按一定的原则从外存的作业后备队列中挑选一个作业调入内存，并创建进程。每个作业只调入一次，调出一次。作业调入时会建立PCB，调出时才撤销PCB。

简单理解高级调度：好几个程序需要启动，到底先启动哪个

--------------------

**问**：为什么需要作业调度？

**答**：内存空间有限，有时无法将用户提交的作业全部放入内存

![image-20201221104619839][]

### 7.4、调度的三个层次——低级调度 ###

> **低级调度（进程调度/处理机调度）**

按照某种策略从就绪队列中选取一个进程，将处理机分配给它。

进程调度是操作系统中最基本的一种调度，在一般的操作系统中都必须配置进程调度。进程调度的频率很高，一般几十毫秒一次。

![image-20201221104658737][]

### 7.5、调度的三个层次——中级调度 ###

> **中级调度**

内存不够时，可将某些进程的数据调出外存。等内存空闲或者进程需要运行时再重新调入内存。

暂时调到外存等待的进程状态为挂起状态。被挂起的进程PCB会被组织成挂起队列

中级调度（内存调度）——按照某种策略决定将哪个处于挂起状态的进程重新调入内存。一个进程可能会被多次调出、调入内存，因此中级调度发生的频率要比高级调度更高。

![image-20201221104908339][]

### 7.6、补充知识：进程的挂起态与七状态模型 ###

> **就绪挂起态 & 阻塞挂起**

暂时调到外存等待的进程状态为挂起状态（挂起态，suspend），挂起态又可以进一步细分为就绪挂起、阻塞挂起两种状态。因此五状态模型 → 七状态模型

![image-20201221105014716][]

> **几种牵涉到挂起的状态转换**

1.  创建态 → 就绪挂起：创建进程后，内存空间不足，进程状态直接变为就绪挂起
2.  就绪态 ⇄ 就绪挂起：内存不够时，将就绪态的进程数据调入外存中，变为就绪挂起
3.  运行态 → 就绪挂起：进程运行过程中被剥夺处理机资源，同时内存资源不足，进程变为就绪挂起
4.  阻塞态 ⇄ 阻塞挂起：由于内存空间不足，进程在等待事件发生时，数据被调入外存中，变为阻塞挂起
5.  阻塞挂起 → 就绪挂起：当等待的事件发生后，进程由阻塞挂起变为就绪挂起

> **注意事项**

注意“挂起”和“阻塞”的区别，两种状态都是暂时不能获得CPU的服务，但挂起态是将进程映像调到外存去了，而阻塞态下进程映像还在内存中。

有的操作系统会把就绪挂起、阻塞挂起分为两个挂起队列，甚至会根据阻塞原因不同再把阻塞挂起进程进一步细分为多个队列。

### 7.7、对比 ###

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>要做什么</th> 
   <th>调度发生在…</th> 
   <th>发生频率</th> 
   <th>对进程状态的影响</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>高级调度 （作业调度）</td> 
   <td>按照某种规则，从后备队列 中选择合适的作业将其调入 内存，并为其创建进程</td> 
   <td>外存→内存 （面向作业）</td> 
   <td>最低</td> 
   <td>无→创建态→就绪态</td> 
  </tr> 
  <tr> 
   <td>中级调度 （内存调度）</td> 
   <td>按照某种规则，从挂起队列 中选择合适的进程将其数据 调回内存</td> 
   <td>外存→内存 （面向进程）</td> 
   <td>中等</td> 
   <td>挂起态→就绪态 （阻塞挂起→阻塞态）</td> 
  </tr> 
  <tr> 
   <td>低级调度 （进程调度）</td> 
   <td>按照某种规则，从就绪队列 中选择一个进程为其分配处 理机</td> 
   <td>内存→CPU</td> 
   <td>最高</td> 
   <td>就绪态→运行态</td> 
  </tr> 
 </tbody> 
</table>

### 7.8、本节课总结 ###

![image-20201221105138627][]

## 8、进程调度的时机切换与过程调度方式 ##

### 8.1、思维导图 ###

![image-20201221110444114][]

### 8.2、进程调度的时机 ###

> **哪些情况下需要进行进程调度？**

进程调度（低级调度） ， 就是按照某种算法从就绪队列中选择一个进程为其分配处理机。

![image-20201221112734910][]

### 8.3、进程调度的时机 ###

> **看一道考题**

正确的说法：进程在操作系统内核程序临界区中不能进行调度与切换

错误的说法：（2012年联考真题） 进程处于临界区时不能进行处理机调度

> **临界资源 & 临界区**

临界资源： 一个时间段内只允许一个进程使用的资源。 各进程需要互斥地访问临界资源。

临界区： 访问临界资源的那段代码。

> **临界区的分类**

**1、内核临界区**

如果还没退出临界区（还没解锁）就进行进程调度， 但是进程调度相关的程序也需要访问就绪队列，但此时就绪队列被锁住了， 因此又无法顺利进行进程调度

内核程序临界区访问的临界资源如果不尽快释放的话， 极有可能影响到操作系统内核的其他管理工作。 因此在访问内核程序临界区期间不能进行调度与切换

--------------------

**2、普通临界区**

在打印机打印完成之前， 进程一直处于临界区内， 临界资源不会解锁。 但打印机又是慢速设备， 此时如果一直不允许进程调度的话就会导致CPU一直空闲

普通临界区访问的临界资源不会直接影响操作系统内核的管理工作。 因此在访问普通临界区时可以进行调度与切换。

### 8.4、进程调度的方式 ###

**两种进程调度的方式**

有的系统中， 只允许进程主动放弃处理机；有的系统中， 进程可以主动放弃处理机， 当有更紧急的任务需要处理时， 也会强行剥夺处理机（被动放弃），因此可将进程调度分为如下两种方式：

> **1、非剥夺调度方式**

非剥夺调度方式， 又称非抢占方式。 即， 只允许进程主动放弃处理机。 在运行过程中即便有更紧迫的任务到达， 当前进程依然会继续使用处理机， 直到该进程终止或主动要求进入阻塞态。

特点：实现简单， 系统开销小但是无法及时处理紧急任务， 适合于早期的批处理系统

> **2、剥夺调度方式**

剥夺调度方式， 又称抢占方式。 当一个进程正在处理机上执行时， 如果有一个更重要或更紧迫的进程需要使用处理机， 则立即暂停正在执行的进程， 将处理机分配给更重要紧迫的那个进程。

特点：可以优先处理更紧急的进程， 也可实现让各进程按时间片轮流执行的功能（通过时钟中断） 。 适合于分时操作系统、 实时操作系统

### 8.5、进程的切换与过程 ###

“狭义的进程调度” 与“进程切换” 的区别：

> **1、狭义的进程调度**

狭义的进程调度指的是从就绪队列中选中一个要运行的进程。 （这个进程可以是刚刚被暂停执行的进程，也可能是另一个进程， 后一种情况就需要进程切换）

进程切换是指一个进程让出处理机， 由另一个进程占用处理机的过程。

> **2、广义的进程调**

广义的进程调度包含了选择一个进程和进程切换两个步骤。进程切换的过程主要完成了：

1.  对原来运行进程各种数据的保存
2.  对新的进程各种数据的恢复

（如： 程序计数器、 程序状态字、 各种数据寄存器等处理机现场信息， 这些信息一般保存在进程控制块）

**注意**： 进程切换是有代价的， 因此如果过于频繁的进行进程调度、 切换， 必然会使整个系统的效率降低，使系统大部分时间都花在了进程切换上， 而真正用于执行进程的时间减少。

### 8.6、本节课总结 ###

![image-20201221122253142][]

## 9、调度算法的评价指标 ##

### 9.1、思维导图 ###

![image-20201221141114922][]

### 9.2、CPU利用率 ###

> **CPU 利用率计算公式**

由于早期的CPU造价极其昂贵， 因此人们会希望让CPU尽可能多地工作，CPU利用率： 指CPU “忙碌” 的时间占总时间的比例。  
 利 用 率 = 忙 碌 的 时 间 总 时 间 利用率 = \\frac\{忙碌的时间\}\{总时间\} 利用率=总时间忙碌的时间  
注：有的题目还会要求计算某种设备的利用率

> **举个栗子**

Eg： 某计算机只支持单道程序， 某个作业刚开始需要在CPU上运行5秒，再用打印机打印输出5秒， 之后再执行5秒， 才能结束。 在此过程中，CPU利用率、 打印机利用率分别是多少？

CPU 利用率  
 C P U 利 用 率 = 5 + 5 5 + 5 + 5 = 66.66 % CPU利用率 = \\frac\{5 + 5\}\{5 + 5 + 5\} = 66.66\\% CPU利用率=5\+5\+55\+5=66.66%  
打印机利用率  
 打 印 机 利 用 率 = 5 15 = 33.33 % 打印机利用率 = \\frac\{5\}\{15\} = 33.33\\% 打印机利用率=155=33.33%  
注：通常会考察多道程序并发执行的情况， 可以用“甘特图” 来辅助计算

### 9.3、系统吞吐量 ###

> **系统吞吐量计算公式**

对于计算机来说， 希望能用尽可能少的时间处理完尽可能多的作业。系统吞吐量： 单位时间内完成作业的数量，计算公式为  
 系 统 吞 吐 量 = 总 共 完 成 了 多 少 道 作 业 总 共 花 了 多 少 时 间 系统吞吐量 = \\frac\{总共完成了多少道作业\}\{总共花了多少时间\} 系统吞吐量=总共花了多少时间总共完成了多少道作业

> **举个栗子**

Eg： 某计算机系统处理完10道作业， 共花费100秒， 则系统吞吐量为？

答：10/100 = 0.1 道/秒

### 9.4、周转时间 ###

> **周转时间的定义**

对于计算机的用户来说， 他很关心自己的作业从提交到完成花了多少时间。

周转时间， 是指从作业被提交给系统开始， 到作业完成为止的这段时间间隔。它包括四个部分：

1.  作业在外存后备队列上等待作业调度（高级调度） 的时间
2.  进程在就绪队列上等待进程调度（低级调度） 的时间
3.  进程在CPU上执行的时间
4.  进程等待I/O操作完成的时间

后三项在一个作业的整个处理过程中， 可能发生多次。

> **周转时间的计算公式**

周转时间计算公式为（对于用户来说，更关心自己单个作业的周转时间 ）：  
 （ 作 业 ） 周 转 时 间 = 作 业 完 成 时 间 – 作 业 提 交 时 间 （作业） 周转时间 = 作业完成时间 – 作业提交时间 （作业）周转时间=作业完成时间–作业提交时间  
平均周转时间计算公式为（对于操作系统来说， 更关心系统的整体表现，因此更关心所有作业周转时间的平均值 ）：  
 平 均 周 转 时 间 = 各 作 业 周 转 时 间 之 和 作 业 数 平均周转时间 = \\frac\{各作业周转时间之和\}\{作业数\} 平均周转时间=作业数各作业周转时间之和

> **举个栗子**

**思考**： 有的作业运行时间短， 有的作业运行时间长， 因此在周转时间相同的情况下， 运行时间不同的作业， 给用户的感觉肯定是不一样的

**举个有味道的栗子**：有两个人上厕所，一个人等待了 1 分钟，拉了 9 分钟的屎，另一个人等了 9 分钟，拉了 1 分钟得屎，对于他们来说，周转时间都是 10 分钟，但是他们的体验是完全不一样的。其原因在于周转时间既包含了等待时间又包含了运行时间

> **带权周转时间**

**1、用户关心的带权周转时间**：  
 带 权 周 转 时 间 = 作 业 周 转 时 间 作 业 实 际 运 行 的 时 间 = 作 业 完 成 时 间 – 作 业 提 交 时 间 作 业 实 际 运 行 的 时 间 带权周转时间 = \\frac\{作业周转时间\}\{作业实际运行的时间\} = \\frac\{作业完成时间 – 作业提交时间\}\{作业实际运行的时间\} 带权周转时间=作业实际运行的时间作业周转时间=作业实际运行的时间作业完成时间–作业提交时间

可见带权周转时间必定 ≥ 1，并且带权周转时间越小越好。带权周转时间表示进程的周转时间比实际运行时间大多少倍

**2、系统关心的平均带权周转时间**：  
 平 均 带 权 周 转 时 间 = 各 作 业 带 权 周 转 时 间 之 和 作 业 数 平均带权周转时间 = \\frac\{各作业带权周转时间之和\}\{作业数\} 平均带权周转时间=作业数各作业带权周转时间之和

--------------------

**带权周转时间指标的含义**

对于周转时间相同的两个作业， 实际运行时间长的作业在相同时间内被服务的时间更多，带权周转时间更小， 用户满意度更高。

对于实际运行时间相同的两个作业， 周转时间短的带权周转时间更小， 用户满意度更高。

### 9.5、等待时间 ###

> **等待时间的定义**

计算机的用户希望自己的作业尽可能少的等待处理机。等待时间， 指进程/作业处于等待处理机状态时间之和， 等待时间越长， 用户满意度越低

![image-20201221142917250][]

> **注意事项**

对于进程来说， 等待时间就是指进程建立后等待被服务的时间之和， 在等待I/O完成的期间其实进程也是在被服务的（因为该期间进程在被I/O设备服务）， 所以不计入等待时间。

对于作业来说， 不仅要考虑建立进程后的等待时间， 还要加上作业在外存后备队列中等待的时间。

一个作业总共需要被CPU服务多久， 被I/O设备服务多久一般是确定不变的， 因此调度算法其实只会影响作业/进程的等待时间。 与前面指标类似， 也有“平均等待时间” 来评价整体性能。

### 9.6、响应时间 ###

> **响应时间的定义**

对于计算机用户来说， 会希望自己的提交的请求（比如通过键盘输入了一个调试命令） 尽早地开始被系统服务、 回应。

响应时间， 指从用户提交请求到首次产生响应所用的时间。

### 9.7、本节课总结 ###

![image-20201221143124793][]

## 10、调度算法第一讲 ##

### 10.1、思维导图 ###

> **本节要讲的三个调度算法**

1.  先来先服务
2.  最短作业优先
3.  最高响应比优先

![image-20201221143158555][]

> **Tips： 各种调度算法的学习思路**

1.  算法思想
2.  算法规则
3.  这种调度算法是用于 作业调度 还是 进程调度？
4.  抢占式？ 非抢占式？
5.  优点和缺点
6.  是否会导致饥饿（某进程/作业长期得不到服务）

### 10.2、先来先服务 ###

先来先服务（FCFS, First Come First Serve）

#### 10.2.1、算法介绍 ####

> **1、算法思想**

主要从“公平” 的角度考虑（类似于我们生活中排队买东西的例子）

> **2、算法规则**

按照作业/进程到达的先后顺序进行服务

> **3、用于作业/进程调度**

用于作业调度时， 考虑的是哪个作业先到达后备队列； 用于进程调度时， 考虑的是哪个进程先到达就绪队列

> **4、是否可抢占？**

非抢占式的算法（进程主动放弃处理机资源）

> **5、优缺点**

**优点**： 公平、 算法实现简单

**缺点**： 排在长作业（进程） 后面的短作业需要等待很长时间， 带权周转时间很大， 对短作业来说用户体验不好。 即FCFS算法对长作业有利， 对短作业不利

**Eg**： 排队买奶茶，我（短作业）在排队买奶茶，我前面那个人（长作业）要买 20 杯奶茶，我的体验及其不好~~~

> 6、是否会导致饥饿

不会

#### 10.2.2、例题讲解 ####

> **题目要求**

**例题**： 各进程到达就绪队列的时间、 需要的运行时间如下表所示。 使用先来先服务调度算法， 计算各进程的等待时间、 平均等待时间、 周转时间、 平均周转时间、 带权周转时间、 平均带权周转时间。

> **调度顺序 & 指标计算**

**先来先服务调度算法**：

按照到达的先后顺序调度， 事实上就是等待时间越久的越优先得到服务。因此， 调度顺序为： P1 → P2 → P3 → P4

![image-20201221143735352][]

--------------------

**计算各项评价指标**

1.  周转时间 = 完成时间 - 到达时间：P1=7-0=7； P2=11-2=9； P3=12-4=8； P4=16-5=11
2.  带权周转时间 = 周转时间/运行时间：P1=7/7=1； P2=9/4=2.25； P3=8/1=8； P4=11/4=2.75
3.  等待时间 = 周转时间 – 运行时间：P1=7-7=0； P2=9-4=5； P3=8-1=7； P4=11-4=7
4.  平均周转时间 = (7+9+8+11)/4 = 8.75
5.  平均带权周转时间 = (1+2.25+8+2.75)/4 = 3.5
6.  平均等待时间 = (0+5+7+7)/4 = 4.75

--------------------

**注意**：

P3 进程的带权周转时间非常大，使用进程 3 的用户体检极其不好

本例中的进程都是纯计算型的进程， 一个进程到达后要么在等待， 要么在运行。 如果是又有计算、 又有I/O操作的进程， 其等待时间就是周转时间 - 运行时间 -I/O操作的时间

### 10.3、短作业优先 ###

短作业优先（SJF, Shortest Job First）

#### 10.3.1、算法介绍 ####

> **1、算法思想**

追求最少的平均等待时间， 最少的平均周转时间、 最少的平均平均带权周转时间（为了解决 FCFS 对短作业不理的弊端）

> **2、算法规则**

最短的作业/进程优先得到服务（所谓“最短” ， 是指要求服务时间最短）

> **3、用于作业/进程调度**

即可用于作业调度， 也可用于进程调度。 用于进程调度时称为“短进程优先（SPF, Shortest Process First） 算法”

> **4、是否可抢占？**

SJF和SPF是非抢占式的算法。 但是也有抢占式的版本——最短剩余时间优先算法（SRTN, Shortest Remaining Time Next）

> **5、优缺点**

**优点**： “最短的” 平均等待时间、 平均周转时间

**缺点**： 不公平。 对短作业有利， 对长作业不利。 可能产生饥饿现象。 另外， 作业/进程的运行时间是由用户提供的，并不一定真实， 不一定能做到真正的短作业优先

> **6、是否会导致饥饿**

会。如果源源不断地有短作业/进程到来，可能使长作业/进程长时间得不到服务，产生“饥饿”现象。如果一直得不到服务，则称为“饿死”现象

#### 10.3.2、非抢占式短作业优先 ####

> **题目要求**

**例题**： 各进程到达就绪队列的时间、 需要的运行时间如下表所示。 使用非抢占式的短作业优先调度算法（严格来说， 用于进程调度应该称为短进程优先调度算法（SPF））， 计算各进程的等待时间、 平均等待时间、 周转时间、 平均周转时间、 带权周转时间、 平均带权周转时间。

> **调度顺序 & 指标计算**

**短作业/进程优先调度算法**：

每次调度时选择当前已到达且运行时间最短的作业/进程。因此， 调度顺序为： P1 → P3 → P2 → P4

![image-20201221144427924][]

--------------------

**计算各项评价指标**

1.  周转时间 = 完成时间 - 到达时间：P1=7-0=7； P3=8-4=4； P2=12-2=10； P4=16-5=11
2.  带权周转时间 = 周转时间/运行时间：P1=7/7=1； P3=4/1=4； P2=10/4=2.5； P4=11/4=2.75
3.  等待时间 = 周转时间 – 运行时间：P1=7-7=0； P3=4-1=3； P2=10-4=6； P4=11-4=7
4.  平均周转时间 = (7+4+10+11)/4 = 8
5.  平均带权周转时间 = (1+4+2.5+2.75)/4 = 2.56
6.  平均等待时间 = (0+3+6+7)/4 = 4

--------------------

**注意**：

对比FCFS算法的结果， 显然SPF算法的平均等待/周转/带权周转时间都要更低

#### 10.3.3、抢占式短作业优先 ####

> **题目要求**

例题： 各进程到达就绪队列的时间、 需要的运行时间如下表所示。 使用抢占式的短作业优先调度算法（抢占式的短作业优先算法，又称最短剩余时间优先算法（SRTN）），计算各进程的等待时间、 平均等待时间、 周转时间、 平均周转时间、 带权周转时间、 平均带权周转时间。

> **调度顺序 & 指标计算**

**最短剩余时间优先算法**：

每当有进程加入就绪队列改变时就需要调度， 如果新到达的进程剩余时间比当前运行的进程剩余时间更短， 则由新进程抢占处理机， 当前运行进程重新回到就绪队列。 另外， 当一个进程完成时也需要调度

--------------------

**调度流程讲解**：需要注意的是， 当有新进程到达时就绪队列就会改变， 就要按照上述规则进行检查。 以下 Pn（m）表示当前 Pn进程剩余时间为 m。 各个时刻的情况如下：

1.  0时刻（P1到达） ： P1（7），执行 P1 进程
2.  2时刻（P2到达） ： P1（5） 、 P2（4），P2 进程时间短，执行 P2 进程
3.  4时刻（P3到达） ： P1（5） 、 P2（2） 、 P3（1），P3 进程时间短，执行 P3 进程
4.  5时刻（P3完成且P4刚好到达） ： P1（5） 、 P2（2） 、 P4（4），P2 进程时间短，执行 P2 进程
5.  7时刻（P2完成） ： P1（5） 、 P4（4），P4 进程时间短，执行 P4 进程
6.  11时刻（P4完成） ： P1（5），执行 P5 进程

![image-20201221144730287][]

--------------------

**计算各项评价指标**

1.  周转时间 = 完成时间 - 到达时间 P1=16-0=16； P2=7-2=5； P3=5-4=1； P4=11-5=6
2.  带权周转时间 = 周转时间/运行时间 P1=16/7=2.28； P2=5/4=1.25； P3=1/1=1； P4=6/4=1.5
3.  等待时间 = 周转时间 – 运行时间 P1=16-7=9； P2=5-4=1； P3=1-1=0； P4=6-4=2
4.  平均周转时间 = (16+5+1+6)/4 = 7
5.  平均带权周转时间 = (2.28+1.25+1+1.5)/4 = 1.50
6.  平均等待时间 = (9+1+0+2)/4 = 3

--------------------

**注意**：对比非抢占式的短作业优先算法， 显然抢占式的的平均等待/周转/带权周转时间都要更低

#### 10.3.4、注意事项 ####

> **注意几个小细节**

1.  如果题目中未特别说明， 所提到的“短作业/进程优先算法” 默认是非抢占式的
2.  很多书上都会说“SJF 调度算法的平均等待时间、 平均周转时间最少”
    
    1.  严格来说， 这个表述是错误的， 不严谨的。 之前的例子表明， 最短剩余时间优先算法得到的平均等待时间、 平均周转时间还要更少
    2.  应该加上一个条件“在所有进程同时可运行时， 采用SJF调度算法的平均等待时间、 平均周转时间最少” ；
    3.  或者说“在所有进程都几乎同时到达时， 采用SJF调度算法的平均等待时间、 平均周转时间最少” ；
    4.  如果不加上述前提条件， 则应该说“抢占式的短作业/进程优先调度算法（最短剩余时间优先, SRNT算法） 的平均等待时间、 平均周转时间最少”
3.  虽然严格来说， SJF的平均等待时间、 平均周转时间并不一定最少， 但相比于其他算法（如 FCFS） ，SJF依然可以获得较少的平均等待时间、 平均周转时间
4.  如果选择题中遇到“SJF 算法的平均等待时间、 平均周转时间最少” 的选项， 那最好判断其他选项是不是有很明显的错误， 如果没有更合适的选项， 那也应该选择该选项

### 10.4、对FCFS和SJF算法的思考 ###

> **无法同时兼顾各个作业的运行时间和等待时间**

FCFS 算法是在每次调度的时候选择一个等待时间最长的作业（进程） 为其服务。 但是没有考虑到作业的运行时间， 因此导致了对短作业不友好的问题

SJF 算法是选择一个执行时间最短的作业为其服务。 但是又完全不考虑各个作业的等待时间， 因  
此导致了对长作业不友好的问题， 甚至还会造成饥饿问题

能不能设计一个算法， 即考虑到各个作业的等待时间， 也能兼顾运行时间呢？接下来讲解高响应比优先算法

### 10.5、高响应比优先 ###

高响应比优先（HRRN, Highest Response Ratio Next）

#### 10.5.1、算法介绍 ####

> **1、算法思想**

要综合考虑作业/进程的等待时间和要求服务的时间

> **2、算法规则**

在每次调度时先计算各个作业/进程的响应比， 选择响应 比最高的作业/进程为其服务  
 响 应 比 = 等 待 时 间 + 要 求 服 务 时 间 要 求 服 务 时 间 响应比 = \\frac\{等待时间 + 要求服务时间\}\{要求服务时间\} 响应比=要求服务时间等待时间\+要求服务时间  
响应比永远 ≥ 1

> **3、用于作业/进程调度**

既可用于作业调度， 也可用于进程调度

> **4、是否可抢占？**

非抢占式的算法。 因此只有当前运行的作业/进程主动放弃处理机时， 才需要调度， 才需要计算响应比

> **5、优缺点**

综合考虑了等待时间和运行时间（要求服务时间）等待时间相同时， 要求服务时间短的优先（SJF 的优点）要求服务时间相同时， 等待时间长的优先（FCFS 的优点）对于长作业来说， 随着等待时间越来越久， 其响应比也会越来越大， 从而避免了长作业饥饿的问题

> **6、是否会导致饥饿**

不会

#### 10.5.2、例题讲解 ####

> **题目要求**

**例题**： 各进程到达就绪队列的时间、 需要的运行时间如下表所示。 使用高响应比优先调度算法， 计算各进程的等待时间、 平均等待时间、 周转时间、 平均周转时间、 带权周转时间、 平均带权周转时间。

> **调度顺序 & 指标计算**

**高响应比优先算法**：

非抢占式的调度算法， 只有当前运行的进程主动放弃CPU时（正常/异常完成， 或主动阻塞） ， 才需要进行调度， 调度时计算所有就绪进程的响应比， 选响应比最高的进程上处理机。

--------------------

**计算过程讲解**

1.  0时刻： 只有 P1到达就绪队列， P1上处理机
2.  7时刻（P1主动放弃CPU） ： 就绪队列中有 P2 (响应比=(5+4)/4=2.25)、 P3((3+1)/1=4)、 P4((2+4)/4=1.5)，P3 响应比最高，执行 P3 进程
3.  8时刻（P3完成） ： P2(2.5)、 P4(1.75)，P2 响应比最高，执行 P2 进程
4.  12时刻（P2完成） ： 就绪队列中只剩下 P4，执行 P4 进程

![image-20201221145841914][]

### 10.6、本节课小结 ###

> **本节三种调度算法的对比**

这几种算法主要关心对用户的公平性、 平均周转时间、 平均等待时间等评价系统整体性能的指标， 但是不关心“响应时间” ， 也并不区分任务的紧急程度， 因此对于用户来说， 交互性很糟糕。 因此这三种算法一般适合用于早期的批处理系统， 当然， FCFS算法也常结合其他的算法使用， 在现在也扮演着很重要的角色。 而适合用于交互式系统的调度算法将在下个小节介绍…

![image-20201221150146784][]

## 11、调度算法第二讲 ##

### 11.1、思维导图 ###

> **本节要讲的三个调度算法**

1.  时间片轮转
2.  优先级调度
3.  多级反馈队列

![image-20201221150229550][]

### 11.2、时间片轮转 ###

时间片轮转（RR, Round-Robin），适用于分时操作系统

#### 11.2.1、算法介绍 ####

> **1、算法思想**

公平地、 轮流地为各个进程服务， 让每个进程在一定时间间隔内都可以得到响应

> **2、算法规则**

按照各进程到达就绪队列的顺序， 轮流让各个进程执行一个时间片（如 100ms） 。 若进程未在一个时间片内执行完，则剥夺处理机， 将进程重新放到就绪队列队尾重新排队。

> **3、用于作业/进程调度**

用于进程调度（只有作业放入内存建立了相应的进程后，才能被分配处理机时间片）

> **4、是否可抢占？**

若进程未能在时间片内运行完， 将被强行剥夺处理机使用权， 因此时间片轮转调度算法属于抢占式的算法。 由时钟装置发出时钟中断来通知CPU时间片已到

> **5、优缺点**

**优点**： 公平； 响应快， 适用于分时操作系统；

**缺点**： 由于高频率的进程切换， 因此有一定开销； 不区分任务的紧急程度。

> **6、是否会导致饥饿**

不会

#### 11.2.2、时间片大小等于 2 ####

> **题目要求**

**例题**： 各进程到达就绪队列的时间、 需要的运行时间如下表所示。 使用时间片轮转调度算法， 分析时间片大小分别是2、 5时的进程运行情况。

时间片轮转调度算法常用于分时操作系统， 更注重“响应时间” ， 因而此处不计算周转时间

> **调度流程讲解**

**时间片轮转调度算法**：

轮流让就绪队列中的进程依次执行一个时间片（每次选择的都是排在就绪队列队头的进程）

--------------------

**时间片大小为 2** （注： 以下括号内表示当前时刻就绪队列中的进程、 进程的剩余运行时间）

1.  0时刻（P1(5)）：0时刻只有P1到达就绪队列， 让P1上处理机运行一个时间片
    
    ![image-20201221151112946][]
2.  2时刻（P2(4) → P1(3)）：2时刻P2到达就绪队列， P1运行完一个时间片， 被剥夺处理机， 重新放到队尾。此时P2排在队头， 因此让P2上处理机。 （注意： 2时刻， P1下处理机， 同一时刻新进程P2到达， 如果在题目中遇到这种情况， 默认新到达的进程先进入就绪队列）
    
    ![image-20201221151136965][]
3.  4时刻（P1(3) → P3(1) → P2(2)）：4时刻， P3到达， 先插到就绪队尾， 紧接着， P2下处理机也插到队尾
    
    ![image-20201221151154206][]
4.  5时刻（P3(1) → P2(2) → P4(6)）：5时刻， P4到达插到就绪队尾（注意： 由于P1的时间片还没用完， 因此暂时不调度。 另外， 此时P1处于运行态， 并不在就绪队列中）
5.  6时刻（P3(1) → P2(2) → P4(6) → P1(1)） ： 6时刻， P1时间片用完， 下处理机， 重新放回就绪队尾， 发生调度
    
    ![image-20201221151218737][]
6.  7时刻（P2(2) → P4(6) → P1(1)） ： 虽然P3的时间片没用完， 但是由于P3只需运行1个单位的时间， 运行完了会主动放弃处理机， 因此也会发生调度。 队头进程P2上处理机。
    
    ![image-20201221151256786][]
7.  9时刻（P4(6) → P1(1)） ： 进程P2时间片用完， 并刚好运行完， 发生调度， P4上处理机
    
    ![image-20201221151308131][]
8.  11时刻（P1(1) → P4(4)） ： P4时间片用完， 重新回到就绪队列。 P1上处理机
    
    ![image-20201221151318331][]
9.  12时刻（P4(4)） ： P1运行完， 主动放弃处理机， 此时就绪队列中只剩P4， P4上处理机
    
    ![image-20201221151329879][]
10. 14时刻（） ： 就绪队列为空， 因此让P4接着运行一个时间片。
    
    ![image-20201221151548254][]
11. 16时刻： 所有进程运行结束
    
    ![image-20201221151341561][]

#### 11.2.3、时间片大小等于 5 ####

> **题目要求**

例题： 各进程到达就绪队列的时间、 需要的运行时间如下表所示。 使用时间片轮转调度算法， 分析时间片大小分别是2、 5时的进程运行情况。

时间片轮转调度算法常用于分时操作系统， 更注重“响应时间” ， 因而此处不计算周转时间

> **调度流程讲解**

**时间片轮转调度算法**：

轮流让就绪队列中的进程依次执行一个时间片（每次选择的都是排在就绪队列队头的进程）

--------------------

**时间片大小为** 5

1.  0时刻（P1(5) ） ： 只有P1到达， P1上处理机。
2.  2时刻（P2(4)） ： P2到达， 但P1时间片尚未结束， 因此暂不调度
3.  4时刻（P2(4) → P3(1)） ： P3到达， 但P1时间片尚未结束， 因此暂不调度
4.  5时刻（ P2(4) → P3(1) → P4(6) ） ： P4到达， 同时， P1运行结束。 发生调度， P2上处理机。
5.  9时刻（ P3(1) → P4(6) ） ： P2运行结束， 虽然时间片没用完， 但是会主动放弃处理机。 发生调度。
6.  10时刻（ P4(6) ） ： P3运行结束， 虽然时间片没用完， 但是会主动放弃处理机。 发生调度。
7.  15时刻（ ） ： P4时间片用完， 但就绪队列为空， 因此会让P4继续执行一个时间片。
8.  16时刻（ ） ： P4运行完， 主动放弃处理机。 所有进程运行完。

![image-20201221151700354][]

> **思考：时间片太大或太小分别有什么影响？**

1.  如果时间片太大，使得每个进程都可以在一个时间片内就完成，则时间片轮转调度算法退化为先来先服务调度算法，并且会增大进程响应时间。因此时间片不能太大。比如：系统中有10个进程在并发执行，如果时间片为1秒，则一个进程被响应可能需要等9秒.…也就是说，如果用户在自己进程的时间片外通过键盘发出调试命令，可能需要等待9秒才能被系统响应
2.  另一方面，进程调度、切换是有时间代价的（保存、恢复运行环境），因此如果时间片太小，会导致进程切换过于频繁，系统会花大量的时间来处理进程切换，从而导致实际用于进程执行的时间比例减少。可见时间片也不能太小。一般来说， 设计时间片时要让切换进程的开销占比不超过 1%

### 11.3、优先级调度算法 ###

优先级调度算法

#### 11.3.1、算法介绍 ####

> **1、算法思想**

随着计算机的发展， 特别是实时操作系统的出现， 越来越多的应用场景需要根据任务的紧急程度来决定处理顺序

> **2、算法规则**

每个作业/进程有各自的优先级， 调度时选择优先级最高的作业/进程

> **3、用于作业/进程调度**

既可用于作业调度， 也可用于进程调度。 甚至还会用于在之后会学习的I/O调度中

> **4、是否可抢占？**

抢占式、 非抢占式都有。 做题时的区别在于： 非抢占式只需在进程主动放弃处理机时进行调度即可， 而抢占式还需在就绪队列变化时， 检查是否会发生抢占。

> **5、优缺点**

**优点**： 用优先级区分紧急程度、 重要程度， 适用于实时操作系统。 可灵活地调整对各种作业/进程的偏好程度。

**缺点**： 若源源不断地有高优先级进程到来， 则可能导致饥饿

> **6、是否会导致饥饿**

会

#### 11.3.2、非抢占式的优先级调度 ####

> **题目要求**

例题： 各进程到达就绪队列的时间、 需要的运行时间、 进程优先数如下表所示。 使用非抢占式的优先级调度算法， 分析进程运行情况。 （注： 优先数越大， 优先级越高）

> **调度流程讲解**

**非抢占式的优先级调度算法**：

每次调度时选择当前已到达且优先级最高的进程。 当前进程主动放弃处理机时发生调度。

--------------------

**注： 以下括号内表示当前处于就绪队列的进程**

1.  0时刻（P1） ： 只有P1到达， P1上处理机。
2.  7时刻（P2、 P3、 P4） ： P1运行完成主动放弃处理机， 其余进程都已到达， P3优先级最高， P3上处理机。
3.  8时刻（P2、 P4） ： P3完成， P2、 P4优先级相同， 由于P2先到达， 因此P2优先上处理机
4.  12时刻（P4） ： P2完成， 就绪队列只剩P4， P4上处理机。
5.  16时刻（ ） ： P4完成， 所有进程都结束

![image-20201221152917160][]

#### 11.3.3、抢占式的优先级调度 ####

> **题目要求**

例题： 各进程到达就绪队列的时间、 需要的运行时间、 进程优先数如下表所示。 使用抢占式的优先级调度算法， 分析进程运行情况。 （注： 优先数越大， 优先级越高）

> **调度流程讲解**

**抢占式的优先级调度算法**：

每次调度时选择当前已到达且优先级最高的进程。 当前进程主动放弃处理机时发生调度。 另外， 当就绪队列发生改变时也需要检查是会发生抢占。

--------------------

**注： 以下括号内表示当前处于就绪队列的进程**

1.  0时刻（P1） ： 只有P1到达， P1上处理机。
2.  2时刻（P2） ： P2到达就绪队列， 优先级比P1更高， 发生抢占。 P1回到就绪队列， P2上处理机。
3.  4时刻（P1、 P3） ： P3到达， 优先级比P2更高， P2回到就绪队列， P3抢占处理机。
4.  5时刻（P1、 P2、 P4） ： P3完成， 主动释放处理机， 同时， P4也到达， 由于P2比P4更先进入就绪队列，因此选择P2上处理机
5.  7时刻（P1、 P4） ： P2完成， 就绪队列只剩P1、 P4， P4上处理机。
6.  11时刻（P1 ） ： P4完成， P1上处理机
7.  16时刻（） ： P1完成， 所有进程均完成

![image-20201221153003786][]

#### 11.3.4、注意事项 ####

> **根据优先级是否可以动态改变， 可将优先级分为静态优先级和动态优先级两种。**

**1、静态优先级： 创建进程时确定， 之后一直不变。**

如何合理地设置各类进程的优先级？

通常： 系统进程优先级高于用户进程前台进程优先级高于后台进程操作系统更偏好 I/O型进程（或称 I/O繁忙型进程）。原因是：I/O设备和CPU可以并行工作。 如果优先让I/O繁忙型进程优先运行的话，则越有可能让I/O设备尽早地投入工作， 则资源利用率、 系统吞吐量都会得到提升

注： 与I/O型进程相对的是计算型进程（或称 CPU繁忙型进程）

**2、动态优先级： 创建进程时有一个初始值， 之后会根据情况动态地调整优先级。**

如果采用的是动态优先级， 什么时候应该调整？ 可以从追求公平、 提升资源利用率等角度考虑：

1.  如果某进程在就绪队列中等待了很长时间， 则可以适当提升其优先级
2.  如果某进程占用处理机运行了很长时间， 则可适当降低其优先级
3.  如果发现一个进程频繁地进行I/O操作， 则可适当提升其优先级

**注**：哇哦，感觉和高响应优先比的原理很类似哦，兼顾了进程的等待时间和运行时间

> **就绪队列的分类**

就绪队列未必只有一个， 可以按照不同优先级来组织。 另外， 也可以把优先级高的进程排在更靠近队头的位置

### 11.4、思考一波 ###

> **各个调度算法的比较**

1.  FCFS算法的优点是公平
2.  SJF 算法的优点是能尽快处理完短作业，平均等待/周转时间等参数很优秀
3.  时间片轮转调度算法可以让各个进程得到及时的响应
4.  优先级调度算法可以灵活地调整各种进程被服务的机会
5.  能否对其他算法做个折中权衡？ 得到一个综合表现优秀平衡的算法呢？ 见如下的多级反馈队列调度算法

### 11.5、多级反馈队列调度算法 ###

多级反馈队列调度算法

#### 11.5.1、算法介绍 ####

> **1、算法思想**

对其他调度算法的折中权衡

> **2、算法规则**

设置多级就绪队列， 各级队列优先级从高到低， 时间片从小到大

新进程到达时先进入第1级队列， 按FCFS原则排队等待被分配时间片， 若用完时间片进程还未结束， 则进程进入下一级队列队尾。如果此时已经是在最下级的队列， 则重新放回该队列队尾

只有第 k 级队列为空时， 才会为 k+1 级队头的进程分配时间片

> **3、用于作业/进程调度**

用于进程调度

> **4、是否可抢占？**

抢占式的算法。 在 k 级队列的进程运行过程中， 若更上级的队列（1~k-1级） 中进入了一个新进程， 则由于新进程处于优先级更高的队列中， 因此新进程会抢占处理机， 原来运行的进程放回 k 级队列队尾。

> **5、优缺点**

对各类型进程相对公平（FCFS的优点） ； 每个新到达的进程都可以很快就得到响应（RR的优点） ； 短进程只用较少的时间就可完成（SPF的优点） ； 不必实现估计进程的运行时间（避免用户作假） ；可灵活地调整对各类进程的偏好程度， 比如CPU密集型进程、 I/O密集型进程（拓展： 可以将因I/O而阻塞的进程重新放回原队列， 这样I/O型进程就可以保持较高优先级）

> **6、是否会导致饥饿**

会

#### 11.5.2、例题讲解 ####

> **题目要求**

例题： 各进程到达就绪队列的时间、 需要的运行时间如下表所示。 使用多级反馈队列调度算法， 分析进程运行的过程。

> **调度流程讲解**

**多级反馈队列调度算法的规则**

1.  设置多级就绪队列， 各级队列优先级从高到低， 时间片从小到大
2.  新进程到达时先进入第1级队列， 按FCFS原则排队等待被分配时间片。 若用完时间片进程还  
    未结束， 则进程进入下一级队列队尾。 如果此时已经在最下级的队列， 则重新放回最下级  
    队列队尾
3.  只有第 k 级队列为空时， 才会为 k+1 级队头的进程分配时间片
4.  被抢占处理机的进程重新放回原队列队尾

--------------------

**算法流程解析**

1.  P1 进程最先进入第 1 级队列
    
    ![image-20201221154520333][]
2.  P1 进程获得 CPU 资源
    
    ![image-20201221154705993][]
3.  当 P1 进程执行完 1 个时间片后，被分配到第 2 级队列，此时 P2 进程到达，被放入第 1 级队列
    
    ![image-20201221154710765][]
4.  P2 进程获得 CPU 资源
    
    ![image-20201221154823449][]
5.  当 P2 进程执行完 1 个时间片后，被分配到第 2 级队列
    
    ![image-20201221154845541][]
6.  此时没有更高优先级的进程，P1 进程获得 CPU 资源，获得 2 个时间片的执行时间
    
    ![image-20201221154907864][]
7.  当 P1 进程执行完 2 个时间片后，被分配到第 3 级队列
    
    ![image-20201221154946207][]
8.  此时还是没有更高优先级的进程，P2 进程获得 CPU 资源，获得 2 个时间片的执行时间
    
    ![image-20201221155051824][]
9.  此时 P3 进程到达，被放入第 1 级队列中，打断 P2 进程的执行，获得 CPU 资源
    
    ![image-20201221155100496][]
10. P3 进程只需要执行 1 个时间片，执行完就溜了，此时 P2 进程继续执行，P2 进程执行完也溜了
    
    ![image-20201221155300015][]
11. 现在只剩 P1 进程了，P1 进程获得 CPU 资源，继续执行
    
    ![image-20201221155316894][]
12. P1 进程执行所需时间较长，当使用完 2 个时间片后，又被放回到第 3 级队列中（因为第 3 级队列是最下级的队列）
    
    ![image-20201221155347385][]

### 11.6、本节课小结 ###

> **本节三种调度算法的对比**

比起早期的批处理操作系统来说， 由于计算机造价大幅降低， 因此之后出现的交互式操作系统（包括分时操作系统、 实时操作系统等） 更注重系统的响应时间、 公平性、 平衡性等指标。 而这几种算法恰好也能较好地满足交互式系统的需求。 因此这三种算法适合用于交互式系统。 （比如UNIX使用的就是多级反馈队列调度算法）

![image-20201221153805755][]

## 12、进程同步 & 进程互斥 ##

### 12.1、思维导图 ###

![image-20201221160652620][]

### 12.2、什么是进程同步 ###

> **进程的异步性 & 进程通信 & 进程同步带**

**进程的异步性：**

进程具有异步性的特征。 异步性是指， 各并发执行的进程以各自独立的、 不可预知的速度向前推进。

--------------------

**看一个例子： 进程通信——管道通信**

读进程和写进程并发地运行， 由于并发必然导致异步性， 因此“写数据” 和“读数据” 两个操作执  
行的先后顺序是不确定的。 而实际应用中， 又必须按照“写数据 → 读数据” 的顺序来执行的。如何解决这种异步问题， 就是 “进程同步” 所讨论的内容。

![image-20201221185048122][]

--------------------

**进程的同步**

同步亦称直接制约关系， 它是指为完成某种任务而建立的两个或多个进程， 这些进程因为需要在某些位置上协调它们的工作次序而产生的制约关系。 进程间的直接制约关系就是源于它们之间的相互合作。

### 12.3、什么是进程互斥 ###

> **进程互斥：为解决并发共享问题**

**并发共享问题**

进程的“并发” 需要“共享” 的支持。 各个并发执行的进程不可避免的需要共享一些系统资源（比如内存， 又比如打印机、 摄像头这样的I/O设备）

--------------------

**两种共享方式**

互斥共享方式：系统中的某些资源， 虽然可以提供给多个进程使用， 但一个时间段内只允许一个进程访问该资源

同时共享方式：系统中的某些资源， 允许一个时间段内由多个进程“同时” 对它们进行访问

![image-20201221185229814][]

--------------------

**互斥访问临界资源**

我们把一个时间段内只允许一个进程使用的资源称为临界资源。 许多物理设备（比如摄像头、 打印机） 都属于临界资源。 此外还有许多变量、 数据、 内存缓冲区等都属于临界资源。

对临界资源的访问， 必须互斥地进行。 互斥， 亦称间接制约关系。 进程互斥指当一个进程访问某临界资源时， 另一个想要访问该临界资源的进程必须等待。 当前访问临界资源的进程访问结束， 释放该资源之后，另一个进程才能去访问临界资源。

### 12.4、临界区 ###

> **对临界资源的互斥访问， 可以在逻辑上分为如下四个部分：**

1.  进入区： 负责检查是否可进入临界区， 若可进入， 则应设置正在访问临界资源的标志（可理解为“上锁”） ， 以阻止其他进程同时进入临界区
2.  临界区： 访问临界资源的那段代码
3.  退出区： 负责解除正在访问临界资源的标志（可理解为“解锁”）
4.  剩余区： 做其他处理

![image-20201221185344073][]

--------------------

**注意事项**

1.  临界区是进程中访问临界资源的代码段。
2.  进入区和退出区是负责实现互斥的代码段。
3.  临界区也可称为“临界段” 。

> **灵魂拷问**

**思考**：如果一个进程暂时不能进入临界区，那么该进程是否应该一直占着处理机？ 该进程有没有可能一直进不了临界区？ 为了实现对临界资源的互斥访问， 同时保证系统整体性能， 需要遵循以下原则：

1.  空闲让进。 临界区空闲时， 可以允许一个请求进入临界区的进程立即进入临界区；
2.  忙则等待。 当已有进程进入临界区时， 其他试图进入临界区的进程必须等待；
3.  有限等待。 对请求访问的进程， 应保证能在有限时间内进入临界区（保证不会饥饿） ；
4.  让权等待。 当进程不能进入临界区时， 应立即释放处理机， 防止进程忙等待。

### 12.5、本节课小结 ###

> **直接制约 & 间接制约**

进程同步为进程之间的直接制约关系，因为进程之间又相互的协同合作需求

进程互斥为进程之间的间接制约关系，这些进程只是想访问同一个共享资源

![image-20201221185545963][]

## 13、进程互斥的软件实现方法 ##

### 13.1、思维导图 ###

> **学习提示**

1.  理解各个算法的思想、 原理
2.  结合上小节学习的“实现互斥的四个逻辑部分” ， 重点理解各算法在进入区、 退出区都做了什么
3.  分析各算法存在的缺陷（结合“实现互斥要遵循的四个原则” 进行分析）

![image-20201221190117340][]

### 13.2、如果没有注意进程互斥？ ###

> **如果让进程放肆地执行**

进程A、 进程B在系统中并发地运行

先调度A上处理机运行，当A在使用打印机的过程中， 分配给它的时间片用完了，操作系统剥夺 A 的 CPU 使用权， 接下来操作系统调度B让它上处理机运行进程B也在使用打印机

结局： A、 B 的打印内容混在一起了 → 互斥的必要性

![image-20201221190159687][]

那么如何实现进程互斥？

### 13.3、单标志法 ###

> **算法思想**

两个进程在访问完临界区后会把使用临界区的权限转交给另一个进程。 也就是说每个进程进入临界区的权限只能被另一个进程赋予

--------------------

`turn` 的含义：表示想要将临界区礼让给第 `turn` 个进程

![image-20201221190337082][]

> **算法执行流程**：

1.  turn 的初值为 0， 即刚开始只允许 0 号进程进入临界区。
2.  若 P1 先上处理机运行， 则会一直卡在 ⑤。 直到 P1 的时间片用完， 发生调度， 切换 P0 上处理机运行。代码 ① 不会卡住 P0， P0 可以正常访问临界区， 在 P0 访问临界区期间即时切换回 P1， P1依然会卡在 ⑤。只有 P0 在退出区将 turn 改为 1 后， P1才能进入临界区。
3.  因此， 该算法可以实现“同一时刻最多只允许一个进程访问临界区”

![image-20201221190405613][]

> **举个栗子**

以小渣和老渣蹲马桶为例，进行讲解：

![image-20201221190516527][]

> **单标志法的缺点**

只能按 P0 → P1 → P0 → P1 → ……这样轮流访问。 这种必须“轮流访问” 带来的问题是， 如果此时允许进入临界区的进程是 P0， 而 P0 一直不访问临界区， 那么虽然此时临界区空闲， 但是并不允许 P1 访问。因此， 单标志法存在的主要问题是： 违背“空闲让进” 原则

### 13.4、双标志先检查法 ###

> **算法思想**

设置一个布尔型数组 flag\[\]， 数组中各个元素用来标记各进程想进入临界区的意愿， 比如“flag\[0\] = ture” 意味着 0 号进程 P0 现在想要进入临界区。 每个进程在进入临界区之前先检查当前有没有别的进程想进入临界区， 如果没有， 则把自身对应的标志 flag\[i\] 设为 true， 之后开始访问临界区。

--------------------

`flag[i]` 的含义：第 i 个进程表达自己想要进入临界区的意愿

![image-20201221190656026][]

> **算法执行流程**

![image-20201221190722806][]

> **举个栗子**

以小渣和老渣蹲马桶为例，进行讲解：

![image-20201221190743655][]

> **双标志前检查法的缺点**

若按照 ①⑤②⑥③⑦….的顺序执行， P0 和 P1 将会同时访问临界区。

因此， 双标志先检查法的主要问题是： 违反“忙则等待” 原则。原因在于， 进入区的“检查” 和“上锁” 两个处理不是一气呵成的。 “检查” 后， “上锁” 前可能发生进程切换。

### 13.5、双标志后检查法 ###

> **算法思想**

双标志先检查法的改版。 前一个算法的问题是先“检查” 后“上锁” ， 但是这两个操作又无法一气呵成， 因此导致了两个进程同时进入临界区的问题。 因此， 人们又想到先“上锁” 后“检查”的方法， 来避免上述问题。

--------------------

`flag[i]` 的含义：第 i 个进程表达自己想要进入临界区的意愿

![image-20201221190825843][]

--------------------

> **算法执行流程**

![image-20201221191115134][]

> **举个栗子**

以小渣和老渣蹲马桶为例，进行讲解：

![image-20201221191135495][]

> **双标志后检查法的缺点**

若按照 ①⑤②⑥….的顺序执行， P0 和 P1 将都无法进入临界区

因此， 双标志后检查法虽然解决了“忙则等待” 的问题， 但是又违背了“空闲让进” 和“有限等待”  
原则， 会因各进程都长期无法访问临界资源而产生“饥饿” 现象。两个进程都争着想进入临界区， 但是谁也不让谁， 最后谁都无法进入临界区。

### 13.6、Peterson 算法 ###

> **算法思想**

结合双标志法、 单标志法的思想。 如果双方都争着想进入临界区， 那可以让进程尝试“孔融让梨” （谦让） 。 做一个有礼貌的进程。

--------------------

`flag[i]` 的含义：第 i 个进程表达自己想要进入临界区的意愿

`turn` 的含义：表示想要将临界区礼让给第 `turn` 个进程

![image-20201221191214390][]

> **算法执行流程**

先表示自己想要进入临界区，为了礼貌起见，再问问别人需要需要进入临界区

![image-20201221191500747][]

![image-20201221191505991][]

> **举个栗子**

以小渣和老渣蹲马桶为例，进行讲解：

![image-20201221191524585][]

> **Peterson 算法进入临界区的核心思想为**：

1.  主动争取，表示我想进入临界区
2.  主动谦让，问问别人需不需要进入临界区
3.  检查对方是否也想使用，且最后一次是不是自己说了“客气话”

谁最后设置了 turn 变量的值，谁就会做出谦让的动作

> **Peterson 算法的优缺点**

Peterson 算法用软件方法解决了进程互斥问题， 遵循了空闲让进、 忙则等待、 有限等待三个原则， 但是依然未遵循让权等待的原则。

Peterson 算法相较于之前三种软件解决方案来说， 是最好的， 但依然不够好。

--------------------

动手推导：按不同的顺序穿插执行会发生什么？

①②③⑥⑦⑧…

①⑥②③…

①③⑥⑦⑧…

①⑥②⑦⑧…

### 13.7、本节课小结 ###

![image-20201221191728953][]

## 14、进程互斥的硬件实现方法 ##

### 14.1、思维导图 ###

> **学习提示**

1.  理解各方法的原理
2.  了解各方法的优缺点

![image-20201221192305605][]

### 14.2、中断屏蔽方法 ###

> **开关中断保证原子性**

利用“开/关中断指令” 实现（与原语的实现思想相同， 即在某进程开始访问临界区到结束访问为  
止都不允许被中断， 也就不能发生进程切换， 因此也不可能发生两个同时访问临界区的情况）

关中断后即不允许当前进程被中断， 也必然不会发生进程切换，直到当前进程访问完临界区， 再执行开中断指令， 才有可能有别的进程上处理机并访问临界区

...
    关中断;
    临界区
    开中断;
    ...

> **中断屏蔽方法的优缺点**

**优点**： 简单、 高效

**缺点**： 不适用于多处理机； 只适用于操作系统内核进程， 不适用于用户进程（因为开/关中断指令是特权指令，只能运行在内核态， 这组指令如果能让用户随意使用会很危险）

### 14.3、TestAndSet指令 ###

> **TSL 指令（硬件实现）**

TestAndSet指令简称 TS 指令， 也有地方称为 TestAndSetLock 指令， 或 TSL 指令

TSL 指令是用硬件实现的， 执行的过程不允许被中断， 只能一气呵成。 以下是用C语言描述的逻辑

![image-20201221192446256][]

--------------------

**执行流程分析**

若刚开始 lock 是 false， 则 TSL 返回的 old 值为 false， while 循环条件不满足， 直接跳过循环， 进入临界区。 若刚开始 lock 是 true， 则执行 TLS 后 old 返回的值为 true， while 循环条件满足， 会一直循环， 直到当前访问临界区的进程在退出区进行“解锁” 。

相比软件实现方法， TSL 指令把“上锁” 和“检查” 操作用硬件的方式变成了一气呵成的原子操作。

> **TSL 指令的优缺点**

**优点**： 实现简单， 无需像软件实现方法那样严格检查是否会有逻辑漏洞； 适用于多处理机环境

**缺点**： 不满足“让权等待” 原则， 暂时无法进入临界区的进程会占用CPU并循环执行TSL指令， 从而导致“忙等” 。

### 14.4、Swap指令 ###

> **Swap指令（硬件实现）**

有的地方也叫 Exchange 指令， 或简称 XCHG 指令。

Swap 指令是用硬件实现的， 执行的过程不允许被中断， 只能一气呵成。 以下是用C语言描述的逻辑

![image-20201221192544628][]

逻辑上来看 Swap 和 TSL 并无太大区别， 都是先记录下此时临界区是否已经被上锁（记录在 old 变量上） ， 再将上锁标记 lock 设置为 true， 最后检查 old， 如果 old 为 false 则说明之前没有别的进程对临界区上锁， 则可跳出循环， 进入临界区。

> **Swap指令的优缺点**

**优点**： 实现简单， 无需像软件实现方法那样严格检查是否会有逻辑漏洞； 适用于多处理机环境

**缺点**： 不满足“让权等待” 原则， 暂时无法进入临界区的进程会占用CPU并循环执行TSL指令， 从而导致“忙等” 。

### 14.5、本节课总结 ###

![image-20201221192620487][]

## 15、信号量机制 ##

### 15.1、思维导图 ###

> **复习回顾+思考： 之前学习的这些进程互斥的解决方案分别存在哪些问题？**

1.  进程互斥的四种软件实现方式（单标志法、 双标志先检查、 双标志后检查、 Peterson算法）
2.  进程互斥的三种硬件实现方式（中断屏蔽方法、 TS/TSL指令、 Swap/XCHG指令）

> **之前的同步方法存在的问题**

1.  在双标志先检查法中， 进入区的“检查” 、 “上锁” 操作无法一气呵成， 从而导致了两个进程有可能同时进入临界区的问题；
2.  所有的解决方案都无法实现“让权等待”
3.  1965年， 荷兰学者Dijkstra提出了一种卓有成效的实现进程互斥、 同步的方法——信号量机制

![image-20201221195057854][]

### 15.2、信号量机制概述 ###

> **信号量的实现原理**

用户进程可以通过使用操作系统提供的一对原语来对信号量进行操作， 从而很方便的实现了进程互斥、 进程同步。

信号量其实就是一个变量（可以是一个整数， 也可以是更复杂的记录型变量） ， 可以用一个信号量来表示系统中某种资源的数量， 比如： 系统中只有一台打印机， 就可以设置一个初值为 1 的信号量。

原语是一种特殊的程序段， 其执行只能一气呵成， 不可被中断。 原语是由关中断/开中断指令实现的。 软件解决方案的主要问题是由“进入区的各种操作无法一气呵成” ， 因此如果能把进入区、 退出区的操作都用“原语” 实现， 使这些操作能“一气呵成” 就能避免问题。

一对原语： wait(S) 原语和 signal(S) 原语， 可以把原语理解为我们自己写的函数， 函数名分别为 wait 和 signal， 括号里的信号量 S 其实就是函数调用时传入的一个参数。

wait、 signal 原语常简称为 P、 V操作（来自荷兰语 proberen 和 verhogen） 。 因此， 做题的时候常把 wait(S)、 signal(S) 两个操作分别写为 P(S)、 V(S)

### 15.3、信号量机制——整型信号量 ###

> **整型信号量概念**

整型信号量：用一个整数型的变量作为信号量， 用来表示系统中某种资源的数量。

与普通整数变量的区别：对信号量的操作只有三种，即 初始化、 P操作、 V操作

> **举个栗子**

Eg ： 某计算机系统中有一台打印机

在信号量中，“检查” 和“上锁” 一气呵成，避免了并发、 异步导致的问题

整型信号量采用先检查和后上锁的操作，和双标志先检查法类似，只不过采用了原语，保证检查和上锁操作一起完成，不会被其他进程所打断

整型信号量存在的问题： 不满足“让权等待”原则， 会发生“忙等”

![image-20201225220028296][]

各进程使用整型信号量互斥使用打印机

![image-20201225220115364][]

### 15.4、信号量机制——记录型信号量 ###

> **纪录型信号量概念**

整型信号量的缺陷是存在“忙等” 问题， 因此人们又提出了“记录型信号量” ， 即用记录型数据结构表示的信号量。

1.  纪录型信号量的定义
    
    ![image-20201225220214426][]
2.  使用 wait 原语申请对共享资源的使用，如果剩余资源数不够，使用block原语使进程从运行态进入阻塞态， 并把挂到信号量 S 的等待队列（即阻塞队列） 中
    
    ![image-20201225220243851][]
3.  使用 signal 原语释放共享资源的使用权，释放资源后，若还有别的进程在等待这种资源，则使用 wakeup 原语唤醒等待队列中的一个进程，该进程从阻塞态变为就绪态

![image-20201225220311940][]

> **举个栗子**

Eg： 某计算机系统中有2台打印机， 则可在初始化信号量 S 时将 S.value 的值设为 2， 队列 S.L 设置为空

1.  P0 进程和 P1 进程获得对打印机资源的使用，此时 S.value = 0，表示没有打印机资源可用。当 P2 进程执行 wait 原语时，发现没有打印机资源可用，执行 S.value-- 操作，并将自己挂在等待队列
    
    ![image-20201225220512184][]
2.  当 P3 进程执行 wait 原语时，发现没有打印机资源可用，执行 S.value-- 操作，并将自己挂在等待队列
    
    ![image-20201225220922141][]
3.  P0 进程使用完打印机，执行 signal 原语释放对打印机资源的占用，首先执行 S.value++ 操作，执行完后发现 S.value == -1，于是就唤醒等待队列头部的进程。之后 P2 就可以得到打印机资源
    
    ![image-20201225221105765][]
4.  P1 进程使用完打印机，执行 signal 原语释放对打印机资源的占用，首先执行 S.value++ 操作，执行完后发现 S.value == 0，于是就唤醒等待队列头部的进程。之后 P3 就可以得到打印机资源
    
    ![image-20201225221249464][]

> **记录型信号量的优缺点分析**

S.value 的初值表示系统中某种资源的数目。

![image-20201225221348531][]

--------------------

对信号量 S 的一次 P 操作意味着进程请求一个单位的该类资源， 因此需要执行 S.value–， 表示资源数减1， 当 S.value < 0 时表示该类资源已分配完毕， 因此进程应调用 block 原语进行自我阻塞（当前运行的进程从运行态 → 阻塞态） ， 主动放弃处理机， 并插入该类资源的等待队列 S.L 中。 可见， 该机制遵循了“让权等待” 原则，不会出现“忙等” 现象。

![image-20201225221423403][]

--------------------

对信号量 S 的一次 V 操作意味着进程释放一个单位的该类资源， 因此需要执行 S.value++， 表示资源数加1，若加1后仍是 S.value <= 0， 表示依然有进程在等待该类资源， 因此应调用 wakeup 原语唤醒等待队列中的第一个进程（被唤醒进程从阻塞态 → 就绪态） 。

![image-20201225221441148][]

--------------------

**注**：在考研题目中 wait(S)、 signal(S) 也可以记为 P(S)、 V(S)，这对原语可用于实现系统资源的“申请” 和“释放” 。

### 15.5、本节课小结 ###

![image-20201225221529735][]

## 16、同 步、前驱关系 ##

### 16.1、思维导图 ###

> **学习提示**

Tips： 不要一头钻到代码里， 要注意理解信号量背后的含义， 一个信号量对应一种资源

信号量的值 = 这种资源的剩余数量（信号量的值如果小于0， 说明此时有进程在等待这种资源）

1.  P( S ) —— 申请一个资源S， 如果资源不够就阻塞等待
2.  V( S ) —— 释放一个资源S， 如果有进程在等待该资源， 则唤醒一个进程

![image-20201225221547140][]

### 16.2、信号量机制实现进程互斥 ###

> **信号量机制实现进程互斥的步骤**

1.  分析并发进程的关键活动， 划定临界区（如： 对临界资源打印机的访问就应放在临界区）
2.  设置互斥信号量 mutex（理解： 信号量 mutex 表示“进入临界区的名额” ）， 初值为 1
3.  在进入区 P(mutex)——申请资源
4.  在退出区 V(mutex)——释放资源

> **进程互斥的代码**

**纪录型信号量的定义**

![image-20201225221736623][]

**进程互斥的实现**（定义初始值为 1 的信号量）

1.  执行 `P(mutex)` 操作可以看作是进程向操作系统申请一个名额
2.  执行 `V(mutex)` 操作可以看作是进程将名额归还给操作系统

![image-20201225221739634][]

> **注意事项**

1.  对不同的临界资源需要设置不同的互斥信号量。
2.  P、 V操作必须成对出现。 缺少P(mutex) 就不能保证临界资源的互斥访问。 缺少 V(mutex) 会导致资源永不被释放， 等待进程永不被唤醒。

![image-20201225221829066][]

### 16.3、信号量机制实现进程同步 ###

> **进程同步的概念**

进程同步： 要让各并发进程按要求有序地推进。

--------------------

比如， P1、 P2 并发执行， 由于存在异步性， 因此二者交替推进的次序是不确定的。

若 P2 的“代码4” 要基于 P1 的“代码1” 和“代码2” 的运行结果才能执行， 那么我们就必须保证“代码4” 一定是在“代码2” 之后才会执行。

这就是进程同步问题， 让本来异步并发的进程互相配合， 有序推进。

![image-20201225221924183][]

> **信号量机制实现进程同步**

1.  分析什么地方需要实现“同步关系” ， 即必须保证“一前一后” 执行的两个操作（或两句代码）
2.  设置同步信号量 S，初始为 0
3.  在“前操作” 之后执行 V(S)
4.  在“后操作” 之前执行 P(S)

**技巧口诀**： 前V后P

> **举个栗子：保证“代码4” 一定是在“代码2” 之后才会执行**

定义初始值为 0 的信号量

![image-20201225222056991][]

以下信号量操作保证了代码4 一定是在 代码2 之后执行

1.  若先执行到 V(S) 操作， 则 S++ 后 S=1。 之后当执行到 P(S) 操作时， 由于 S=1， 表示有可用资源， 会执行 S–， S 的值变回 0，P2 进程不会执行 block 原语， 而是继续往下执行代码4。
2.  若先执行到 P(S) 操作， 由于 S=0， S-- 后 S=-1， 表示此时没有可用资源， 因此P操作中会执行 block 原语， 主动请求阻塞。之后当执行完代码2， 继而执行 V(S) 操作， S++， 使 S 变回 0，由于此时有进程在该信号量对应的阻塞队列中， 因此会在 V操作中执行 wakeup 原语， 唤醒 P2 进程。 这样 P2 就可以继续执行 代码4 了

![image-20201225222133163][]

### 16.4、信号量机制实现前驱关系 ###

> **题目要求**

进程 P1 中有句代码 S1， P2 中有句代码 S2 ， P3中有句代码S3 …… P6 中有句代码 S6。 这些代码要求按如下前驱图所示的顺序来执行：

![image-20201225222221417][]

> **思路分析**

其实每一对前驱关系都是一个进程同步问题（需要保证一前一后的操作），因此：

1.  要为每一对前驱关系各设置一个同步信号量
2.  在“前操作” 之后对相应的同步信号量执行 V 操作
3.  在“后操作” 之前对相应的同步信号量执行 P 操作

> **代码实现**

1.  首先定义初始值为 0 的信号量
    
    ![image-20201225222354720][]
2.  然后按序执行 PV 操作即可
    
    ![image-20201225222455883][]
3.  完整代码
    
    ![image-20201225222511090][]

### 16.5、本节课小结 ###

> **将资源数看作是信号量的初始值**

有多少资源就把信号量初值设为多少。 申请资源时进行P操作， 释放资源时进行 V 操作即可

1.  互斥问题， 信号量初值为1
2.  同步问题， 信号量初值为0
3.  前驱关系问题，本质上就是多级同步问题

![image-20201225222526386][]

## 17、生产者消费者问题 ##

### 17.1、问题描述 ###

> **生产者消费者问题描述**

系统中有一组生产者进程和一组消费者进程， 生产者进程每次生产一个产品放入缓冲区， 消费者进程每次从缓冲区中取出一个产品并使用。 （注： 这里的“产品” 理解为某种数据）

1.  生产者、消费者共享一个初始为空、大小为n的缓冲区。
2.  只有缓冲区没满时，生产者才能把产品放入缓冲区，否则必须等待（缓冲区没满 建 → 生产者生产）。
3.  只有缓冲区不空时，消费者才能从中取出产品，否则必须等待（缓冲区没空 → 消费者消费）。
4.  缓冲区是临界资源，各进程必须互斥地访问（互斥关系）。

> **生产者消费者问题图解**

1.  生产者生产，消费者消费
    
    ![image-20201225222946839][]
2.  缓冲区满时， 生产者必须等待。
    
    ![image-20201225223015377][]
3.  缓冲区空时，消费者必须等待
    
    ![image-20201225223102458][]
4.  各进程必须互斥地访问，比如生产者进程同时访问缓冲区，则会出现写覆盖问题
    
    ![image-20201225223124665][]

### 17.2、问题分析 ###

> **PV操作题目分析步骤**

1.  关系分析。 找出题目中描述的各个进程， 分析它们之间的同步、 互斥关系。
2.  整理思路。 根据各进程的操作流程确定P、 V操作的大致顺序。
3.  设置信号量。 并根据题目条件确定信号量初值。 （互斥信号量初值一般为1， 同步信号量的初始值要看对应资源的初始值是多少）

![image-20201225223249870][]

### 17.3、如何实现 ###

> **解决思路**

1.  生产者、 消费者共享一个初始为空、 大小为n的缓冲区。
2.  只有缓冲区没满时， 生产者才能把产品放入缓冲区， 否则必须等待。
3.  只有缓冲区不空时， 消费者才能从中取出产品， 否则必须等待。
4.  缓冲区是临界资源， 各进程必须互斥地访问

> **代码实现**

1.  定义信号量
    
        semaphore mutex = 1; //互斥信号量，实现对缓冲区的互斥访问
        semaphore empty = n; //同步信号量，表示空闲缓冲区的数量
        semaphore full = 0; //同步信号量，表示产品的数量，也即非空缓冲区的数量
2.  生产者代码
    
        producer (){
              
            while(1){
              
                生产一个产品;
                P(empty); // 消耗一个空闲缓冲区
                P(mutex);
                把产品放入缓冲区;
                V(mutex);
                V(full); // 增加一个产品
            }
        }
3.  消费者代码
    
        consumer (){
              
            while(1){
              
                P(full); // 消耗一个产品（非空缓冲区）
                P(mutex);
                从缓冲区取出一个产品;
                V(mutex);
                V(empty); // 增加一个空闲缓冲区
                使用产品;
            }
        }

实现缓冲区的互斥是在同一进程中进行一对PV操作

实现两进程的同步关系， 是在其中一个进程中执行P， 另一进程中执行V（一个进程的 V 操作会唤醒另一个进程的 P 操作）

![image-20201225224134383][]

### 17.4、改变相邻PV操作的顺序 ###

> **思考**

能否改变相邻P、 V操作的顺序？

![image-20201225224210643][]

> **分析**

若此时缓冲区内已经放满产品， 则 empty=0， full=n。

则生产者进程执行① 使mutex变为0， 再执行②， 由于已没有空闲缓冲区， 因此生产者被阻塞。由于生产者阻塞， 因此切换回消费者进程。 消费者进程执行③， 由于mutex为0， 即生产者还没释放对临界资源的“锁” ， 因此消费者也被阻塞。

这就造成了生产者等待消费者释放空闲缓冲区， 而消费者又等待生产者释放临界区的情况， 生产者和消费者循环等待被对方唤醒， 出现“死锁” 。

同样的， 若缓冲区中没有产品， 即full=0， empty=n。 按③④① 的顺序执行就会发生死锁。

> **结论**

综上， 实现互斥的P操作一定要在实现同步的P操作之后。

V操作不会导致进程阻塞， 因此两个V操作顺序可以交换。

--------------------

【使用产品】可以放在 PV 操作之间，但不建议这样做，这样会增加临界区的代码，导致临界区代码边的臃肿，是的临界区代码执行时间增加

### 17.5、本节课小结 ###

> **PV 操作题目的解题思路**

1.  关系分析。 找出题目中描述的各个进程， 分析它们之间的同步、 互斥关系。
2.  整理思路。 根据各进程的操作流程确定P、 V操作的大致顺序。
3.  设置信号量。 设置需要的信号量， 并根据题目条件确定信号量初值。 （互斥信号量初值一般为1， 同步信号量的初始值要看对应资源的初始值是多少）

--------------------

生产者消费者问题是一个互斥、 同步的综合问题。

对于初学者来说最难的是发现题目中隐含的两对同步关系。

有时候是消费者需要等待生产者生产， 有时候是生产者要等待消费者消费， 这是两个不同的“一前一后问题” ， 因此也需要设置两个同步信号量。

易错点： 实现互斥和实现同步的两个P操作的先后顺序（死锁问题）

![image-20201225224440709][]

## 18、多生产者多消费者问题 ##

### 18.1、问题描述 ###

> **多生产者多消费者问题描述**

桌子上有一只盘子， 每次只能向其中放入一个水果。 爸爸专向盘子中放苹果， 妈妈专向盘子中放橘子， 儿子专等着吃盘子中的橘子， 女儿专等着吃盘子中的苹果。 只有盘子空时， 爸爸或妈妈才可向盘子中放一个水果。 仅当盘子中有自己需要的水果时， 儿子或女儿可以从盘子中取出水果。用PV操作实现上述过程。

> **多生产者多消费者问题图解**

1.  爸爸专向盘子中放苹果，女儿专等着吃盘子中的苹果

![image-20201225224615547][]

1.  妈妈专向盘子中放橘子， 儿子专等着吃盘子中的橘子
    
    ![image-20201225224706818][]

--------------------

可以将爸爸和妈妈看做是两个不同的生产者，将儿子和女儿看做是两个不同的消费者

![image-20201225224827782][]

### 18.2、问题分析 ###

> **多生产者多消费者问题分析**

1.  关系分析。 找出题目中描述的各个进程， 分析它们之间的同步、 互斥关系。
2.  整理思路。 根据各进程的操作流程确定P、 V操作的大致顺序。
    
    1.  互斥：在临界区前后分别进行 PV 操作
    2.  同步：前 V 后 P
3.  设置信号量。 设置需要的信号量， 并根据题目条件确定信号量初值。 （互斥信号量初值一般为1， 同步信号量的初始值要看对应资源的初始值是多少）

> **互斥与同步关系分析**

**互斥关系**：

对缓冲区（盘子） 的访问要互斥地进行

--------------------

**同步关系**（一前一后） ：

1.  父亲将苹果放入盘子后， 女儿才能取苹果
2.  母亲将橘子放入盘子后， 儿子才能取橘子
3.  只有盘子为空时（“盘子为空” 这个事件可以由儿子或女儿触发， 事件发生后才允许父亲或母亲放水果 ）， 父亲或母亲才能放入水果

![image-20201225225007075][]

### 18.3、如何实现 ###

> **多生产者多消费者问题的解决**

1.  定义信号量
    
        semaphore mutex = 1; //实现互斥访问盘子（缓冲区）
        semaphore apple = 0; //盘子中有几个苹果
        semaphore orange = 0; //盘子中有几个橘子
        semaphore plate = 1; //盘子中还可以放多少个水果
2.  爸爸负责生产苹果
    
        dad (){
              
            while(1){
              
                准备一个苹果;
                P(plate);
                P(mutex);
                把苹果放入盘子;
                V(mutex);
                V(apple);
            }
        }
3.  妈妈负责生产橘子
    
        mom (){
              
            while(1){
              
                准备一个橘子;
                P(plate);
                P(mutex);
                把橘子放入盘子;
                V(mutex);
                V(orange);
            }
        }
4.  女儿负责消费橘子
    
        daughter (){
              
        	while(1){
              
                P(apple);
                P(mutex);
                从盘中取出苹果;
                V(mutex);
                V(plate);
                吃掉苹果;
            }
        }
5.  儿子负责消费苹果
    
        son (){
              
            while(1){
              
                P(orange);
                P(mutex);
                从盘中取出橘子;
                V(mutex);
                V(plate);
                吃掉橘子;
            }
        }
6.  放在一张图里
    
    ![image-20201225225438679][]

> **思考：可不可以不用互斥信号量？**

1.  将互斥信号量去掉
    
    ![image-20201225225521551][]
2.  去掉互斥信号量之后的代码
    
    ![image-20201225225542467][]

--------------------

**执行流程分析**

女儿进程即使上处理机运行也会被阻塞。 如果刚开始是父亲进程先上处理机运行， 则：盘子 → 母亲 P(plate)， 阻塞等待盘子 → 父亲放入苹果 V(apple)， 女儿进程被唤醒， 其他进暂时不可能访问临界资源（盘子） → 女儿 P(apple)， 访问盘子， V(plate)， 等待盘子的母程访问盘子（其他进程暂时都无法进入临界区） → …

--------------------

**结论**：

即使不设置专门的互斥变量mutex， 也不会出现多个进程同时访问盘子的现象

--------------------

**原因在于**：

本题中的缓冲区大小为1， 在任何时刻， apple、 orange、 plate 三个同步信号量中最多只有一个是1。 因此在任何时刻，最多只有一个进程的P操作不会被阻塞， 并顺利地进入临界区…

> **思考：如果盘子（缓冲区） 容量为2**

父亲 P(plate)， 可以访问盘子 → 母亲 P(plate)， 可以访问盘子 → 父亲在往盘子里放苹果， 同时母亲也可以往盘子里放橘子。 于是就出现了两个进程同时访问缓冲区的情况， 有可能导致两个进程写入缓冲区的数据相互覆盖的情况。

父亲 P(plate)， 可以访问盘子 → 母亲 P(plate)， 可以访问盘子 → 父亲在往盘子里放苹果， 同时母亲也可以往盘子里放橘子。 于是就出现了两个进程同时访问缓冲区的情况， 有可能导致两个进程写入缓冲区的数据相互覆盖的情况。因此， 如果缓冲区大小大于1， 就必须专门设置一个互斥信号量 mutex 来保证互斥访问缓冲区。

![image-20201225225542467][image-20201225225542467 1]

### 18.4、本节课小结 ###

> **关于是否添加互斥量？**

**总结**： 在生产者-消费者问题中， 如果缓冲区大小为1， 那么有可能不需要设置互斥信号量就可以实现互斥访问缓冲区的功能。 当然， 这不是绝对的， 要具体问题具体分析。

**建议**： 在考试中如果来不及仔细分析， 可以加上互斥信号量， 保证各进程一定会互斥地访问缓冲区。但需要注意的是， 实现互斥的P操作一定要在实现同步的P操作之后， 否则可能引起“死锁” 。

--------------------

> **PV 操作题目的解题思路**

> **解决“多生产者-多消费者问题” 的关键**

解决“多生产者-多消费者问题” 的关键在于理清复杂的同步关系。在分析同步问题（一前一后问题） 的时候不能从单个进程行为的角度来分析， 要把“一前一后” 发生的事看做是两种“事件” 的前后关系。

比如， 如果从单个进程行为的角度来考虑的话， 我们会有以下结论：

如果盘子里装有苹果， 那么一定要女儿取走苹果后父亲或母亲才能再放入水果

如果盘子里装有橘子， 那么一定要儿子取走橘子后父亲或母亲才能再放入水果

这么看是否就意味着要设置四个同步信号量分别实现这四个“一前一后” 的关系了？

![image-20201225230039724][]

正确的分析方法应该从“事件” 的角度来考虑， 我们可以把上述四对“进程行为的前后关系” 抽象为一对“事件的前后关系”盘子变空事件 → 放入水果事件。 “盘子变空事件” 既可由儿子引发， 也可由女儿引发； “放水果事件”既可能是父亲执行， 也可能是母亲执行。 这样的话， 就可以用一个同步信号量解决问题了

![image-20201225230052499][]

## 19、吸烟者问题 ##

### 19.1、问题描述 ###

> **吸烟者问题描述**

假设一个系统有三个抽烟者进程和一个供应者进程。 每个抽烟者不停地卷烟并抽掉它， 但是要卷起并抽掉一支烟， 抽烟者需要有三种材料： 烟草、 纸和胶水。 三个抽烟者中， 第一个拥有烟草、第二个拥有纸、 第三个拥有胶水。 供应者进程无限地提供三种材料， 供应者每次将两种材料放桌子上， 拥有剩下那种材料的抽烟者卷一根烟并抽掉它， 并给供应者进程一个信号告诉完成了， 供应者就会放另外两种材料再桌上， 这个过程一直重复（让三个抽烟者轮流地抽烟）

> **吸烟者问题图解**

1.  组合一： 纸+胶水
    
    ![image-20201226195915492][]
2.  组合二： 烟草+胶水
    
    ![image-20201226195929687][]
3.  组合三： 烟草+纸
    
    ![image-20201226195944641][]

### 19.2、问题分析 ###

> **分析生产者消费者问题的步骤**

本质上这题也属于“生产者-消费者” 问题， 更详细的说应该是“可生产多种产品的单生产者-多  
消费者” 。

1.  关系分析。 找出题目中描述的各个进程， 分析它们之间的同步、 互斥关系。
2.  整理思路。 根据各进程的操作流程确定P、 V操作的大致顺序
3.  设置信号量。 设置需要的信号量， 并根据题目条件确定信号量初值。 （互斥信号量初值一般为1， 同步信号量的初始值要看对应资源的初始值是多少）

> **分析吸烟者问题**

**三种组合**：桌子可以抽象为容量为1的缓冲区，要互斥访问，桌上上可以放三种组合

1.  组合一： 纸+胶水
2.  组合二： 烟草+胶水
3.  组合三： 烟草+纸

--------------------

**同步关系**（从事件的角度来分析） ：

1.  桌上有组合一 → 第一个抽烟者取走东西
2.  桌上有组合二 → 第二个抽烟者取走东西
3.  桌上有组合三 → 第三个抽烟者取走东西
4.  发出完成信号 → 供应者将下一个组合放到桌上

![image-20201226200425454][]

--------------------

PV操作顺序： “前V后P”

### 19.3、如何实现 ###

> **解决吸烟者问题**

1.  定义信号量：因为缓冲区大小为1， 同一时刻， 四个同步信号量中至多有一个的值为1，所以无需设置一个专门的互斥信号量
    
        semaphore offer1 = 0; //桌上组合一的数量
        semaphore offer2 = 0; //桌上组合二的数量
        semaphore offer3 = 0; //桌上组合三的数量
        semaphore finish = 0; //抽烟是否完成
        int i = 0; //用于实现“三个抽烟者轮流抽烟”
2.  生产者进程：
    
    1.  发按顺序依次生产组合一、组合二、组合三
    2.  每生产完指定组合后，就执行 `V(offerX)` 操作唤醒相应的消费者，并执行 `P(finish)` 操作标记抽烟未完成，等待消费者消费完成之后再继续生产
    
        provider (){
              
            while(1){
              
                if(i==0) {
              
                    将组合一放桌上;
                    V(offer1);
                } else if(i==1){
              
                    将组合二放桌上;
                    V(offer2);
                } else if(i==2){
              
                    将组合三放桌上;
                    V(offer3);
                } 
                i = (i+1)%3;
                P(finish);
            }
        }
3.  消费者一：执行 `P(offer1)` 操作消费组合一，并执行 `V(finish)` 操作标记消费已经完成，提醒生产者可以继续生产产品
    
        smoker1 (){
              
            while(1){
              
                P(offer1);
                从桌上拿走组合
                一；卷烟；抽掉；
                V(finish);
            }
        }
4.  消费者二：执行 `P(offer2)` 操作消费组合二，并执行 `V(finish)` 操作标记消费已经完成，提醒生产者可以继续生产产品
    
        smoker2 (){
              
            while(1){
              
                P(offer2);
                从桌上拿走组合
                二；卷烟；抽掉；
                V(finish);
            }
        }
5.  消费者三：执行 `P(offer3)` 操作消费组合三，并执行 `V(finish)` 操作标记消费已经完成，提醒生产者可以继续生产产品
    
        smoker3 (){
              
            while(1){
              
                P(offer3);
                从桌上拿走组合
                三；卷烟；抽掉；
                V(finish);
            }
        }

### 19.4、本节课小结 ###

> **多消费者单生产者问题的解决思路**

吸烟者问题可以为我们解决“可以生产多个产品的单生产者” 问题提供一个思路。

值得吸取的精华是： “轮流让各个吸烟者吸烟” 必然需要“轮流的在桌上放上组合一、 二、 三” ， 注意体会我们是如何用一个整型变量 i 实现这个“轮流” 过程的。

如果题目改为“每次随机地让一个吸烟者吸烟” ， 我们有应该如何用代码写出这个逻辑呢？答：将 `i` 设置为 `0~2` 之间的随机数

若一个生产者要生产多种产品（或者说会引发多种前驱事件） ， 那么各个V操作应该放在各自对应的“事件” 发生之后的位置。

## 20、读者-写者问题 ##

### 20.1、问题描述 ###

> **读者-写者问题描述**

有读者和写者两组并发进程， 共享一个文件， 当两个或两个以上的读进程同时访问共享数据时不会产生副作用， 但若某个写进程和其他进程（读进程或写进程） 同时访问共享数据时则可能导致数据不一致的错误。 因此要求： ①允许多个读者可以同时对文件执行读操作； ②只允许一个写者往文件中写信息； ③任一写者在完成写操作之前不允许其他读者或写者工作； ④写者执行写操作前， 应让已有的读者和写者全部退出。

![image-20201227210928554][]

### 20.2、问题分析 ###

> **问题分析的步骤**

关系分析。 找出题目中描述的各个进程， 分析它们之间的同步、 互斥关系。

整理思路。 根据各进程的操作流程确定P、 V操作的大致顺序

设置信号量。 设置需要的信号量， 并根据题目条件确定信号量初值。 （互斥信号量初值一般为1，同步信号量的初始值要看对应资源的初始值是多少）

> **理清楚进程之间的护持关系**

两类进程： 写进程、 读进程

互斥关系： 写进程—写进程、 写进程—读进程。 读进程与读进程不存在互斥问题。

### 20.3、如何解决 ###

> **1、实现读写进程的互斥**

1.  定义 `rw` 信号量，用于实现读写进程的互斥
    
        semaphore rw = 1; //用于实现对共享文件的互斥访问
2.  写进程
    
        writer (){
              
            while(1){
              
                P(rw); //写之前“加锁”
                写文件…
                V(rw); //写完了“解锁”
            }
        }
3.  读进程
    
        reader (){
              
            while(1){
              
                P(rw); //读之前“加锁”
                读文件…
                V(rw); //读完了“解锁”
            }
        }

--------------------

**待改进的地方**：读进程之间无法实现共享读

> **2、实现读读进程的共享**

1.  定义 `rw` 信号量，用于实现读写进程的互斥；定义 `count` 变量记录当前正在执行读操作的进程
    
        semaphore rw = 1; //用于实现对共享文件的互斥访问
        int count = 0; //记录当前有几个读进程在访问文件
2.  写进程
    
        writer (){
              
            while(1){
              
                P(rw); //写之前“加锁”
                写文件…
                V(rw); //写完了“解锁”
            }
        }
3.  读进程
    
        reader (){
              
        	while(1){
              
                if(count==0) //由第一个读进程负责
                	P(rw); //读之前“加锁”
                count++; //访问文件的读进程数+1
                读文件…
                count--; //访问文件的读进程数-1
                if(count==0) //由最后一个读进程负责
                	V(rw); //读完了“解锁”
            }
        }

--------------------

**思考**： 若两个读进程并发执行， 则 `count=0` 时两个进程也许都能满足 `if` 条件， 都会执行`P(rw)`， 从而使第二个读进程阻塞的情况。

**如何解决**： 出现上述问题的原因在于对 `count` 变量的检查和赋值无法一气呵成， 因此可以设置另一个互斥信号量来保证各读进程对 `count` 的访问是互斥的。

> **3、实现 count++ 操作的 “原子性”**

1.  定义 `rw` 信号量，用于实现读写进程的互斥；定义 `count` 变量记录当前正在执行读操作的进程；定义 `mutex` 信号量用于保证对 `count` 变量的互斥访问
    
        semaphore rw = 1; //用于实现对共享文件的互斥访问
        int count = 0; //记录当前有几个读进程在访问文件
        semaphore mutex = 1;//用于保证对count变量的互斥访问
2.  写进程
    
        writer (){
              
            while(1){
              
                P(rw); //写之前“加锁”
                写文件…
                V(rw); //写完了“解锁”
            }
        }
3.  读进程
    
        reader (){
              
            while(1){
              
                P(mutex); //各读进程互斥访问count
                if(count==0) //由第一个读进程负责
                	P(rw); //读之前“加锁”
                count++; //访问文件的读进程数+1
                V(mutex);
                读文件…
                P(mutex); //各读进程互斥访问count
                count--; //访问文件的读进程数-1
                if(count==0) //由最后一个读进程负责
                	V(rw); //读完了“解锁”
                V(mutex);
            }
        }

--------------------

**潜在的问题**： 只要有读进程还在读， 写进程就要一直阻塞等待， 可能“饿死” 。因此， 这种算法中， 读进程是优先的

**原因分析**：如果当前有读进程正在读取文件，此时 `rw` 互斥量是被占有的状态，但由于设置了 `count` 变量实现了读进程之间可以共享文件，因此但凡有读进程获取了 `rw` 的互斥量，其他读进程进入可以不用获取 `rw` 互斥量直接进行读取操作。但是写进程就不一样了，但凡有读进程在执行读操作，写进程就会一直卡在 `P(rw)` 处等待读进程释放 `rw` 互斥量（但读进程数量为 0 才会执行 `V(rw)` 释放 `rw` 互斥量）

> **4、实现读写公平**

1.  定义 `rw` 信号量，用于实现读写进程的互斥；定义 `count` 变量记录当前正在执行读操作的进程；定义 `mutex` 信号量用于保证对 `count` 变量的互斥访问；定义 `w` 信号量用于实现写优先
    
        semaphore rw=1; //用于实现对共享文件的互斥访问
        int count = 0; //记录当前有几个读进程在访问文件
        semaphore mutex = 1; //用于保证对count变量的互斥访问
        semaphore w = 1; //用于实现“写优先”
2.  写进程
    
        writer (){
              
            while(1){
              
                P(w); // 用于实现读写公平的操作
                P(rw);
                写文件…
                V(rw);
                V(w); // 用于实现读写公平的操作
            }
        }
3.  读进程
    
        reader (){
              
            while(1){
              
                P(w); // 用于实现读写公平的操作
                P(mutex);
                if(count==0)
                	P(rw);
                count++;
                V(mutex);
                V(w); // 用于实现读写公平的操作
                读文件…
                P(mutex);
                count--;
                if(count==0)
                	V(rw);
                V(mutex);
            }
        }

--------------------

**分析以下并发执行 P(w) 的情况**：

1.  读者1 → 读者2：读者 1 执行读操作的时候将占用 `rw` 互斥量，但是读者 1 获取了 `w` 互斥量之后又将其释放，因此读进程之间可以实现并发读
2.  写者1 → 写者2：写者 1 执行写操作时将占用 `rw` 和 `w` 互斥量，此时写者 2 只能等待写者 1 将 `rw` 和 `w` 互斥量释放之后，才能执行写操作
3.  写者1 → 读者1：写者 1 执行写操作时将占用 `rw` 和 `w` 互斥量，此时读者 1 只能等待写者 1 将 `rw` 和 `w` 互斥量释放之后，才能执行读操作
4.  读者1 → 写者1 → 读者2：读者 1 执行读操作的时候将占用 `rw` 互斥量，此时写者 1 将占用 `w` 互斥量，并且等待读者 1 释放 `rw` 互斥量，由于写者 1 占用了 `w` 互斥量，因此读者 2 无法获取 `w` 互斥量，执行 `P(w)` 操作等待写者 1 释放 `w` 互斥量。当读者 1 执行完成后释放 `rw` 互斥量，写者 1 才得以执行，等到写者 1 执行完成之后，读者 2 才得以执行
5.  写者1 → 读者1 → 写者2：写者 1 执行写操作时将占用 `rw` 和 `w` 互斥量，此时读者 1 只能等待写者 1 将 `rw` 和 `w` 互斥量释放之后，才能执行读操作，写者 2 也只能等待写者 1 将 `rw` 和 `w` 互斥量释放之后，才能执行写操作。等待写者 1 执行完毕之后，读者 1 和 写者 2 才能继续得以执行

--------------------

**结论**：

在这种算法中， 连续进入的多个读者可以同时读文件； 写者和其他进程不能同时访问文件； 写者不会饥饿， 但也并不是真正的“写优先” ， 而是相对公平的先来先服务原则。

当有读进程（readers1）在执行读操作时，这时（t1 时刻）卡进来一个写进程，在 t 时刻之后新建的读进程（readers2）与前面的读进程（readers1）其实无法做到共享读，readers2 必须等待写进程将 `w` 互斥量释放之后才能进行读操作

有的书上把这种算法称为“读写公平法” 。

### 20.4、本节课小结 ###

> **读者-写者问题解决思路**

读者-写者问题为我们解决复杂的互斥问题提供了一个参考思路。

其核心思想在于设置了一个计数器 count 用来记录当前正在访问共享文件的读进程数。 我们可以用 count 的值来判断当前进入的进程是否是第一个/最后一个读进程， 从而做出不同的处理。

另外， 对 count 变量的检查和赋值不能一气呵成导致了一些错误， 如果需要实现“一气呵成” ， 自然应该想到用互斥信号量。

最后， 还要认真体会我们是如何解决“写进程饥饿” 问题的。

绝大多数的考研PV操作大题都可以用之前介绍的几种生产者-消费者问题的思想来解决， 如果遇到更复杂的问题， 可以想想能否用读者写者问题的这几个思想来解决。

## 21、哲学家进餐问题 ##

### 21.1、问题描述 ###

> **哲学家进餐问题描述**

一张圆桌上坐着5名哲学家， 每两个哲学家之间的桌上摆一根筷子， 桌子的中间是一碗米饭。 哲学家们倾注毕生的精力用于思考和进餐， 哲学家在思考时， 并不影响他人。 只有当哲学家饥饿时，才试图拿起左、 右两根筷子（一根一根地拿起） 。 如果筷子已在他人手上， 则需等待。 饥饿的哲学家只有同时拿起两根筷子才可以开始进餐， 当进餐完毕后， 放下筷子继续思考。

![image-20201228182716414][]

### 21.2、问题分析 ###

> **分析哲学家进餐问题**

1.  关系分析。 系统中有5个哲学家进程， 5位哲学家与左右邻居对其中间筷子的访问是互斥关系。
2.  整理思路。 这个问题中只有互斥关系， 但与之前遇到的问题不同的事， 每个哲学家进程需要同时持有两个临界资源才能开始吃饭。 如何避免临界资源分配不当造成的死锁现象， 是哲学家问题的精髓。
3.  信号量设置。 定义互斥信号量数组 `chopstick[5]={1,1,1,1,1}` 用于实现对5个筷子的互斥访问。 并对哲学家按0~4编号， 哲学家 i 左边的筷子编号为 i， 右边的筷子编号为 `(i+1)%5`。

### 21.3、如何解决 ###

> **1、错误的解决方法**

先看看代码，再说错在哪儿。代码大致的意思就是每个哲学家进餐时，先拿起左手边的筷子，再拿起右手边的筷子，进餐完毕再将两只筷子放下

semaphore chopstick[5]={
        1,1,1,1,1};
    Pi (){
         //i号哲学家的进程
        while(1){
        
            P(chopstick[i]); //拿左
            P(chopstick[(i+1)%5]); //拿右
            吃饭…
            V(chopstick[i]); //放左
            V(chopstick[(i+1)%5]); //放右
            思考…
        }
    }

--------------------

**错误原因分析**：

1.  假设当五个哲学家都同时拿起了他左边的筷子（哲学家 0 拿起了他左边的筷子，发生了进程切换；哲学家 1 拿起了他左边的筷子，发生了进程切换；… ；一切都是这么巧）即 5 个哲学家并发地拿起了自己左手边的筷子
    
    ![image-20201228183456427][]
2.  于是每个哲学家都在等待他右手边的哲学家放下筷子（阻塞），这样就形成了死锁。圈圈圆圆圈圈。。。
    
    ![image-20201228183903441][]

> **2、正确的解决方法一：最多允许四个哲学家同时进餐**

思路：可以对哲学家进程施加一些限制条件， 比如最多允许四个哲学家同时进餐。 这样可以保证至少有一个哲学家是可以拿到左右两只筷子的

--------------------

比如最多只允许哲学家 0~3 号同时进餐

1.  假设哲学家 0~3 号同时拿起了他左手边的筷子，我们规定最多只允许 4 个哲学家同时进餐，因此哲学家 4 不能拿起筷子
    
    ![image-20201228184300557][]
2.  这时哲学家 3 就能拿起他右手边的筷子，完成进餐后放下筷子。接着哲学家 2 可以拿起他右手边的筷子，完成进餐。。。以此类推
    
    ![image-20201228184929253][]
3.  这样就能保证有一个哲学家先吃上饭，然后将筷子还回桌上，这样其他哲学家也才能吃上饭，不至于僵持不下（死锁）

代码思路：设置一个初始值为 4 的信号量，即最多允许四个哲学家同时进餐。 这样可以保证至少有一个哲学家是可以拿到左右两只筷子的

> **3、正确的解决方法二：根据哲学家序号规定其拿起筷子的顺序**

思路：要求奇数号哲学家先拿左边的筷子， 然后再拿右边的筷子， 而偶数号哲学家刚好相反。 用这种方法可以保证如果相邻的两个奇偶号哲学家都想吃饭， 那么只会有其中一个可以拿起第一只筷子， 另一个会直接阻塞。 这就避免了占有一支后再等待另一只的情况。

--------------------

1.  假设哲学家 0 和哲学家 1 同时想要进餐，哲学家 0 需要拿起他右手边的筷子，哲学家 1 需要拿起他左手边的筷子，因此哲学家 0 和哲学家 1 中只能有一个拿起筷子，进行用餐
    
    ![image-20201228185358901][]
2.  假设哲学家 1 和哲学家 2 同时想要进餐，哲学家 1 需要拿起他右手边的筷子，哲学家 2 需要拿起他左手边的筷子，因此哲学家 1 和哲学家 2 中只能有一个拿起筷子，进行用餐
    
    ![image-20201228185603219][]
3.  假设哲学家 4 进餐需要先拿起他右手边的筷子
    
    ![image-20201228185837821][]
4.  相邻的奇偶号哲学家优先争抢他们之间的筷子，这样能保证抢到筷子的哲学家，可以拿起他另一边的筷子，不会出现哲学家拿到筷子又在等待另一只筷子被释放的问题。最终的目的还是保证了某些哲学家能先吃上饭，然后将筷子还回桌上，这样其他哲学家也才能吃上饭，不至于僵持不下（死锁）
5.  举个栗子：哲学家 0 和哲学家 1 争抢 1号筷子
    
    1.  假设哲学家 0 抢到了 1 号筷子，此时哲学家 0 会尝试去拿起 1 号筷子
        
        1.  假设哲学家 4 没有占用 0 号筷子，哲学家 0 能够顺利拿起 0 号筷子，完成进餐
        2.  假设哲学家 4 正在占用 0 号筷子，由于 4 号筷子不会被争抢（哲学家 2 和 哲学家 3 只会争抢 3 号筷子），因此哲学家 4 能够顺利拿起 4 号筷子，完成进餐，然后将 0 号筷子释放，交由哲学家 0 使用
    2.  假设哲学家 1 抢到了 1 号筷子，由于 2 号筷子不会被争抢（哲学家 2 和 哲学家 3 只会争抢 3 号筷子），因此哲学家 1 能够顺利拿起 2 号筷子，完成进餐

--------------------

**代码思路**：拿筷子之前先判断哲学家的序号，奇数号哲学家先拿左边的筷子， 然后再拿右边的筷子， 偶数号哲学家先拿右边的筷子，然后再拿左边的筷子

> **4、正确的解决方法三：让哲学家互斥地拿起筷子**

**思路**：保证哲学家拿筷子的动作“一气呵成”，不会被打断

semaphore chopstick[5]={
        1,1,1,1,1};
    semaphore mutex = 1; //互斥地取筷子
    Pi (){
         //i号哲学家的进程
        while(1){
        
            P(mutex);
            P(chopstick[i]); //拿左
            P(chopstick[(i+1)%5]); //拿右
            V(mutex);
            吃饭…
            V(chopstick[i]); //放左
            V(chopstick[(i+1)%5]); //放右
            思考…
    	}
    }

--------------------

**情况 1**：

1.  假设哲学家 0 拿起他左手边的筷子，哲学家 2 无法获取到 `mutex` 互斥量的使用权，因此他拿筷子的动作将被阻塞
    
    ![image-20201228191734900][]
2.  等到哲学家 0 拿起了两只筷子进行用餐之后，哲学家 2 才能获取到 `mutex` 互斥量的使用权
    
    ![image-20201228191911837][]
3.  此时哲学家 2 可以拿起他左右两边的筷子进行用餐
    
    ![image-20201228192008894][]

--------------------

**情况 2**：

1.  哲学家 0 拿起了两只筷子进行用餐之后，哲学家 1 虽然可以获取到 `mutex` 互斥量的使用权，但是哲学家 1 无法获取到 1 号筷子的使用权，被阻塞
    
    ![image-20201228192059068][]
2.  哲学家 2 虽然可以获取其两边筷子的使用权，但是哲学家 2 无法获取到 `mutex` 互斥量的使用权（`1mutex` 互斥量被哲学家 1 占用），被阻塞
    
    ![image-20201228192451465][]
3.  等到哲学家 0 进餐完成，释放 1 号筷子的使用权。哲学家 1 才能拿起 1 号筷子和 2 号筷子完成进餐。等到哲学家 1 进餐完成之后，释放 `mutex` 互斥量的使用权，哲学家 2 才不会被阻塞
4.  结论：即使哲学家 2 左右两边的筷子都在， 也暂时无法取得筷子的使用权

--------------------

**情况 3**：

1.  哲学家 0 拿起了两只筷子进行用餐之后，哲学家 4 可以获取到 `mutex` 互斥量的使用权，也可以拿起他左边的筷子
    
    ![image-20201228192835544][]
2.  但是由于哲学 0 占用了 0 号筷子，因此哲学家 4 暂时无法使用 0 号筷子
    
    ![image-20201228192840501][]
3.  当哲学家 0 放下 0 号筷子后，哲学家 4 才能拿起 0 号筷子完成进餐

--------------------

**结论**： 各哲学家拿筷子这件事必须互斥的执行。 这就保证了即使一个哲学家在拿筷子拿到一半时被阻塞， 也不会有别的哲学家会继续尝试拿筷子。 这样的话，当前正在吃饭的哲学家放下筷子后， 被阻塞的哲学家就可以获得等待的筷子了

### 21.4、本节课小结 ###

> **哲学家问题的解决思路**

哲学家进餐问题的关键在于解决进程死锁。

这些进程之间只存在互斥关系， 但是与之前接触到的互斥关系不同的是， 每个进程都需要同时持有两个临界资源， 因此就有“死锁” 问题的隐患。

如果在考试中遇到了一个进程需要同时持有多个临界资源的情况， 应该参考哲学家问题的思想， 分析题中给出的进程之间是否会发生循环等待， 是否会发生死锁。可以参考哲学家就餐问题解决死锁的三种思路。

## 22、管程 ##

### 22.1、思维导图 ###

![image-20201228214014375][]

### 22.2、为什么要引入管程 ###

> **信号量机制的弊端**

信号量机制存在的问题： 编写程序困难、 易出错。比如之前编写的生产者消费者问题，将进程互斥的 P 操作与进程同步的 P 操作顺序写反了，直接 GG 导致死锁

![image-20201228214137563][]

--------------------

能不能设计一种机制， 让程序员写程序时不需要再关注复杂的PV操作， 让写代码更轻松呢？ 1973年， Brinch Hansen 首次在程序设计语言 (Pascal) 中引入了“管程” 成分——一种高级同步机制

### 22.3、管程的定义和基本特征 ###

> **管程的组成**

管程是一种特殊的软件模块， 有这些部分组成：

1.  局部于管程的共享数据结构（共享缓冲区）说明；
2.  对该数据结构进行操作的一组过程（“过程” 其实就是“函数”）；
3.  对局部于管程的共享数据设置初始值的语句；
4.  管程有一个名字。

> **管程的基本特征**

1.  局部于管程的数据只能被局部于管程的过程所访问；
2.  一个进程只有通过调用管程内的过程才能进入管程访问共享数据；
3.  每次仅允许一个进程在管程内执行某个内部过程。

### 22.4、拓展1： 用管程解决生产者消费者问题 ###

> **1、管程解决生产者消费者问题的伪代码**

`monitor` 和 `endmonitor` 表示定义一个管程

1.  管程中可以设置条件变量和等待/唤醒操作，以解决同步问题
2.  由编译器负责实现各进程互斥地进入管程中的过程

![image-20201228214821723][]

--------------------

生产者进程

![image-20201228214940862][]

--------------------

消费者进程

![image-20201228214949556][]

> **2、引入管程的目的无非就是要更方便地实现进程互斥和同步**

**管程的注意事项**

1.  需要在管程中定义共享数据（如生产者消费者问题的缓冲区）
2.  需要在管程中定义用于访问这些共享数据的“入口” ——其实就是一些函数（如生产者消费者问题中， 可以定义一个函数用于将产品放入缓冲区， 再定义一个函数用于从缓冲区取出产品）
3.  只有通过这些特定的“入口” 才能访问共享数据
4.  管程中有很多“入口” ， 但是每次只能开放其中一个“入口” ， 并且只能让一个进程或线程进入（如生产者消费者问题中， 各进程需要互斥地访问共享缓冲区。 管程的这种特性即可保证一个时间段内最多只会有一个进程在访问缓冲区。 注意： 这种互斥特性是由编译器负责实现的，程序员不用关心）
5.  可在管程中设置条件变量及等待/唤醒操作以解决同步问题。 可以让一个进程或线程在条件变量上等待（此时， 该进程应先释放管程的使用权， 也就是让出“入口” ） ； 可以通过唤醒操作将等待在条件变量上的进程或线程唤醒。

--------------------

程序员可以用某种特殊的语法定义一个管程（比如: `monitor ProducerConsumer …… end monitor;`） ，之后其他程序员就可以使用这个管程提供的特定“入口” 很方便地使用实现进程同步/互斥了（封装的思想）

### 22.5、拓展2： Java 中类似于管程的机制 ###

Java 中， 如果用关键字 synchronized 来描述一个函数（同步方法）， 那么这个函数同一时间段内只能被一个线程调用

每次只能有一个线程进入 `insert` 函数， 如果多个线程同时调用 `insert` 函数， 则后来者需要排队等待

![image-20201228215420601][]

--------------------

熟悉 Java 的同学在时间充裕的情况下可以动手尝试用 synchronized 实现生产者消费者问题的“管程”

### 22.6、本节课小结 ###

![image-20201228214641088][]

## 23、死锁的概念 ##

### 23.1、思维导图 ###

![image-20201228215550777][]

### 23.2、什么是死锁 ###

> **死锁的举例一**

哲学家进餐问题的错误代码：导致死锁

--------------------

1.  哲学家进餐问题中， 如果5位哲学家进程并发执行， 都拿起了左手边的筷子…
    
    ![image-20201228215717463][]
2.  每位哲学家都在等待自己右边的人放下筷子， 这些哲学家进程都因等待筷子资源而被阻塞。 即发生“死锁
    
    ![image-20201228215723632][]

> **死锁的举例二**

有一首歌的歌词： 我爱你， 你爱他， 他爱她， 她爱我……这世界每个人都爱别人……

我们从资源占有的角度来分析， 这段关系为什么看起来那么纠结…

![image-20201228215942650][]

![image-20201228215946615][]

--------------------

每个人都占有一个资源，同时又在等待另一个人手里的资源。 发生“死锁”

在并发环境下， 各进程因竞争资源而造成的一种互相等待对方手里的资源， 导致各进程都阻塞， 都无法向前推进的现象， 就是“死锁” 。发生死锁后若无外力干涉，这些进程都将无法向前推进。

### 23.3、 饥饿、 死循环的区别 ###

> **死锁 & 饥饿 & 死循环**

死锁： 各进程互相等待对方手里的资源， 导致各进程都阻塞， 无法向前推进的现象。

饥饿： 由于长期得不到想要的资源， 某进程无法向前推进的现象。 比如： 在短进程优先（SPF） 算法中， 若有源源不断的短进程到来， 则长进程将一直得不到处理机， 从而发生长进程“饥饿” 。

死循环： 某进程执行过程中一直跳不出某个循环的现象。 有时是因为程序逻辑 bug 导致的， 有时是程序员故意设计的。

![image-20201228220201709][]

### 23.4、死锁产生的必要条件 ###

> **产生死锁的四个必要条件**

产生死锁必须同时满足以下四个条件， 只要其中任一条件不成立， 死锁就不会发生。

1.  互斥条件： 只有对必须互斥使用的资源的争抢才会导致死锁（如哲学家的筷子、 打印机设备） 。像内存、 扬声器这样可以同时让多个进程使用的资源是不会导致死锁的（因为进程不用阻塞等待这种资源） 。
2.  不剥夺条件： 进程所获得的资源在未使用完之前， 不能由其他进程强行夺走， 只能主动释放。
3.  请求和保持条件： 进程已经保持了至少一个资源， 但又提出了新的资源请求， 而该资源又被其他进程占有， 此时请求进程被阻塞， 但又对自己已有的资源保持不放。
4.  循环等待条件： 存在一种进程资源的循环等待链， 链中的每一个进程已获得的资源同时被下一个进程所请求。

> **循环等待是死锁的必要不充分条件**

注意！ 发生死锁时一定有循环等待， 但是发生循环等待时未必死锁（循环等待是死锁的必要不充分条件）

Why？如果同类资源数大于1， 则即使有循环等待， 也未必发生死锁。 但如果系统中每类资源都只有一个， 那循环等待就是死锁的充分必要条件了。

比如哲学家 3 可以等待两个同类资源：

1.  哲学家 3 除了等待哲学家手里的 4 号筷子之外，还可以等待另一个白头发哲学家手中的筷子
    
    ![image-20201228220447339][]
2.  如果能够占用白头发哲学家手中的筷子，那么哲学家 3 依然能够完成进餐，释放其左右两边的筷子，这样其他哲学家也能够完成进餐，并不会导致死锁
    
    ![image-20201228220451094][]

### 23.5、什么时候会发生死锁 ###

> **死锁的举例**

1.  对系统资源的竞争。 各进程对不可剥夺的资源（如打印机） 的竞争可能引起死锁， 对可剥夺的资源（CPU） 的竞争是不会引起死锁的。
2.  进程推进顺序非法。 请求和释放资源的顺序不当， 也同样会导致死锁。 例如， 并发执行的进程P1、P2 分别申请并占有了资源 R1、 R2， 之后进程P1又紧接着申请资源R2， 而进程P2又申请资源R1，两者会因为申请的资源被对方占有而阻塞， 从而发生死锁。
3.  信号量的使用不当也会造成死锁。 如生产者-消费者问题中， 如果实现互斥的P操作在实现同步的P操作之前， 就有可能导致死锁。 （可以把互斥信号量、 同步信号量也看做是一种抽象的系统资源）

--------------------

总之， 对不可剥夺资源的不合理分配， 可能导致死锁。

### 23.6、死锁的处理策略 ###

> **预防、避免、检测解除**

1.  预防死锁。 破坏死锁产生的四个必要条件中的一个或几个。
2.  避免死锁。 用某种方法防止系统进入不安全状态， 从而避免死锁（银行家算法）
3.  死锁的检测和解除。 允许死锁的发生， 不过操作系统会负责检测出死锁的发生， 然后采取某种措施解除死锁。

### 23.7、本节课小结 ###

![image-20201228220731331][]

## 24、死锁的处理策略 ——预防死锁 ##

### 24.1、思维导图 ###

**产生死锁的四个必要条件**： 死锁的产生必须满足四个必要条件， 只要其中一个或者几个条件不满足， 死锁就不会发生。

![image-20201228220756567][]

### 24.2、破坏互斥条件 ###

> **破坏互斥条件的做法**

**互斥条件**： 只有对必须互斥使用的资源的争抢才会导致死锁。

如果把只能互斥使用的资源改造为允许共享使用， 则系统不会进入死锁状态。 比如: SPOOLing技术。操作系统可以采用 SPOOLing 技术把独占设备在逻辑上改造成共享设备。 比如， 用SPOOLing 技术将打印机改造为共享设备…

--------------------

使用 SPOOLing 技术之前：进程 1 在使用打印机资源时，进程 2 请求打印机资源时会被阻塞

![image-20201228221123836][]

--------------------

**使用 SPOOLing 技术之后**

1.  进程 1 和进程 2 将打印任务交给输出进程，然后就可以去干自己的事情了
    
    ![image-20201228221202341][]
2.  输出进程与打印机交互执行进程 1 的打印任务
    
    ![image-20201228221222245][]
3.  输出进程与打印机交互执行进程 2 的打印任务
    
    ![image-20201228221248191][]

> **破坏互斥条件的缺点**

该策略的缺点： 并不是所有的资源都可以改造成可共享使用的资源。 并且为了系统安全， 很多地方还必须保护这种互斥性。 因此， 很多时候都无法破坏互斥条件。

### 24.3、破坏不剥夺条件 ###

> **破坏不剥夺条件的做法**

**不剥夺条件**： 进程所获得的资源在未使用完之前， 不能由其他进程强行夺走， 只能主动释放。

--------------------

**破坏不剥夺条件**：

1.  方案一： 当某个进程请求新的资源得不到满足时， 它必须立即释放保持的所有资源， 待以后需要时再重新申请。 也就是说， 即使某些资源尚未使用完， 也需要主动释放， 从而破坏了不可剥夺条件。
2.  方案二： 当某个进程需要的资源被其他进程所占有的时候， 可以由操作系统协助， 将想要的资源强行剥夺。 这种方式一般需要考虑各进程的优先级（比如： 剥夺调度方式， 就是将处理机资源强行剥夺给优先级更高的进程使用）

> **破坏不剥夺条件的缺点**

1.  实现起来比较复杂。
2.  释放已获得的资源可能造成前一阶段工作的失效。 因此这种方法一般只适用于易保存和恢复状态的资源， 如CPU。
3.  反复地申请和释放资源会增加系统开销， 降低系统吞吐量。
4.  若采用方案一， 意味着只要暂时得不到某个资源， 之前获得的那些资源就都需要放弃， 以后再重新申请。 如果一直发生这样的情况， 就会导致进程饥饿。

### 24.4、破坏请求和保持条件 ###

> **破坏请求和保持条件的做法**

**请求和保持条件**： 进程已经保持了至少一个资源， 但又提出了新的资源请求， 而该资源又被其他进程占有， 此时请求进程被阻塞， 但又对自己已有的资源保持不放。

可以采用静态分配方法， 即进程在运行前一次申请完它所需要的全部资源， 在它的资源未满足前，不让它投入运行。 一旦投入运行后， 这些资源就一直归它所有， 该进程就不会再请求别的任何资源了

> **破坏请求和保持条件的缺点**

该策略实现起来简单， 但也有明显的缺点：有些资源可能只需要用很短的时间， 因此如果进程的整个运行期间都一直保持着所有资源， 就会造成严重的资源浪费， 资源利用率极低。 另外， 该策略也有可能导致某些进程饥饿（因为需要获取所有资源才能运行，那获取不到就只能挨饿咯）。

### 24.5、破坏循环等待条件 ###

> **破坏循环等待条件的做法**

**循环等待条件**： 存在一种进程资源的循环等待链， 链中的每一个进程已获得的资源同时被下一个进程所请求。

可采用顺序资源分配法。 首先给系统中的资源编号， 规定每个进程必须按编号递增的顺序请求资源，同类资源（即编号相同的资源） 一次申请完。

原理分析： 一个进程只有已占有小编号的资源时， 才有资格申请更大编号的资源。 按此规则， 已持有大编号资源的进程不可能逆向地回来申请小编号的资源， 从而就不会产生循环等待的现象。

--------------------

假设系统中共有10个资源， 编号为 1, 2, …… 10。在任何一个时刻， 总有一个进程拥有的资源编号是最大的， 那这个进程申请之后的资源必然畅通无阻。因此， 不可能出现所有进程都阻塞的死锁现象

![image-20201228221709487][]

> **破坏循环等待条件的缺点**

1.  不方便增加新的设备， 因为可能需要重新分配所有的编号
2.  进程实际使用资源的顺序可能和编号递增顺序不一致， 会导致资源浪费。比如 P3 进程先使用扫描仪再使用打印机，但打印机的编号为 5，扫描仪的编号为 7，这就导致打印机有很长一段时间的空档期
3.  必须按规定次序申请资源， 用户编程麻烦（编号顺序调换，得重新改写进程对临界资源操作的代码~~~）

### 24.6、本节课小结 ###

![image-20201228222034984][]

## 25、死锁的处理策略——避免死锁 ##

### 25.1、思维导图 ###

![image-20201228222058630][]

### 25.2、什么是安全序列 ###

> **银行家贷款案例**

你是一位成功的银行家， 手里掌握着100个亿的资金…

有三个企业想找你贷款， 分别是 企业B、 企业A、 企业T， 为描述方便， 简称BAT。

B 表示： “大哥， 我最多会跟你借70亿…”  
A 表示： “大哥， 我最多会跟你借40亿…”  
T 表示： “大哥， 我最多会跟你借50亿…”

然而…江湖中有个不成文的规矩： 如果你借给企业的钱总数达不到企业提出的最大要求， 那么不管你之前给企业借了多少钱， 那些钱都拿不回来了…

刚开始， BAT三个企业分别从你这儿借了 20、 10、 30 亿，此时手里还有： 40亿

![image-20201229122418184][]

> **情况一：B 还想借 30 亿， 你敢借吗？**

此时 B 还想借 30 亿， 你敢借吗？假如答应了B的请求，那么手里还有：10亿。

只剩下10亿，如果BAT都提出再借20亿的请求，那么任何一个企业的需求都得不到满足

![image-20201229122858117][]

> **情况二：A 还想借 20 亿， 你敢借吗？**

此时 A 还想借 20 亿， 你敢借吗？假如答应了A的请求，之后按T → B → A的顺序借钱是OK的

可以先把20亿全部借给T， 等T把钱全部还回来了， 手里就会有20+30=50亿， 再把这些钱全借给B， B还钱后总共有50+20=70亿， 最后再借给A

![image-20201229123100093][]

> **情况三：A 还想借 20 亿， 你敢借吗？**

此时 A 还想借 20 亿， 你敢借吗？假如答应了A的请求，之后按A → T → B的顺序借钱是OK的

可以先借10亿给A，等A还钱了手里就有20+30=50亿，再借20亿给T，等T还钱了就有50+30=80亿，最后再借50亿给B

![image-20201229123100093][image-20201229123100093 1]

### 25.3、安全状态和死锁 ###

> **1、安全序列和安全状态**

所谓安全序列， 就是指如果系统按照这种序列分配资源， 则每个进程都能顺利完成。 只要能找出一个安全序列， 系统就是安全状态。 当然， 安全序列可能有多个。

> **2、不安全状态**

如果分配了资源之后， 系统中找不出任何一个安全序列， 系统就进入了不安全状态。 这就意味着之后可能所有进程都无法顺利的执行下去。 当然， 如果有进程提前归还了一些资源， 那系统也有可能重新回到安全状态， 不过我们在分配资源之前总是要考虑到最坏的情况。

> **3、死锁与不安全状态的联系**

如果系统处于安全状态， 就一定不会发生死锁。 如果系统进入不安全状态， 就可能发生死锁（处于不安全状态未必就是发生了死锁， 但发生死锁时一定是在不安全状态）

> **4、银行家算法核心思想**

因此可以在资源分配之前预先判断这次分配是否会导致系统进入不安全状态， 以此决定是否答应资源分配请求。 这也是“银行家算法” 的核心思想。

> **5、举例**

1.  借给 B 30 亿将进入不安全状态
    
    ![image-20201229123912635][]
2.  借给 A 20 亿是安全的，T → B → A 是安全序列
    
    ![image-20201229123942275][]

### 25.4、银行家算法 ###

> **银行家算法概述**

银行家算法是荷兰学者 Dijkstra 为银行系统设计的， 以确保银行在发放现金贷款时， 不会发生不能满足所有客户需要的情况。 后来该算法被用在操作系统中， 用于避免死锁。

核心思想： 在进程提出资源申请时， 先预判此次分配是否会导致系统进入不安全状态。 如果会进入不安全状态， 就暂时不答应这次请求， 让该进程先阻塞等待。

> **思考：银行家贷款问题**

思考： BAT 的例子中， 只有一种类型的资源——钱， 但是在计算机系统中会有多种多样的资源， 应该怎么把算法拓展为多种资源的情况呢？

可以把单维的数字拓展为多维的向量。 比如： 系统中有5个进程 P0~P4， 3种资源 R0~R2， 初始数量为 (10, 5, 7)， 则某一时刻的情况可表示如下：

![image-20201229124330256][]

此时总共已分配 (7, 2, 5)， 还剩余 (3, 3, 2) 可把最大需求、 已分配的数据看作矩阵，两矩阵相减， 就可算出各进程最多还需要多少资源了

> **举例一：此时系统是否处于安全状态？**

思路：系统资源总数 (10, 5, 7)，尝试找出一个安全序列

1.  依次检查剩余可用资源 (3, 3, 2) 是否能满足各进程的需求，不满足 P0 进程的需求
    
    ![image-20201229124626433][]
2.  依次检查剩余可用资源 (3, 3, 2) 是否能满足各进程的需求，可满足P1需求， 将 P1 加入安全序列（如果优先将资源分配给 P1，那么 P1 肯定能够顺利执行结束，然后将资源归还给操作系统）， 并更新剩余可用资源值为 (5, 3, 2)
    
    ![image-20201229124653858][]
3.  依次检查剩余可用资源 (5, 3, 2) 是否能满足剩余进程（不包括已加入安全序列的进程） 的需求，不满足 P0 进程的需求
    
    ![image-20201229124710247][]
4.  依次检查剩余可用资源 (5, 3, 2) 是否能满足剩余进程（不包括已加入安全序列的进程） 的需求，可满足P3需求， 将 P3 加入安全序列（如果优先将资源分配给 P3，那么 P3 肯定能够顺利执行结束，然后将资源归还给操作系统）， 并更新剩余可用资源值为 (7, 4, 3)
    
    ![image-20201229124837247][]
5.  依次检查剩余可用资源 (7, 4, 3) 是否能满足剩余进程（不包括已加入安全序列的进程） 的需求
    
    ![image-20201229124917357][]
6.  以此类推， 共五次循环检查即可将5个进程都加入安全序列中， 最终可得一个安全序列。 该算法称为安全性算法。 可以很方便地用代码实现以上流程， 每一轮检查都从编号较小的进程开始检查。实际做题时可以更快速的得到安全序列。

> **举例二：手动计算找到一个安全序列**

实际做题（手算） 时可用更快速的方法找到一个安全序列：

经对比发现， (3, 3, 2) 可满足 P1、 P3， 说明无论如何， 这两个进程的资源需求一定是可以依次被满足的， 因此P1、 P3 一定可以顺利的执行完， 并归还资源。 可把 P1、 P3 先加入安全序列。

P1 和P3 归还资源后，系统可用的资源个数为：(2, 0, 0) + (2, 1, 1) + (3, 3, 2) = (7, 4, 3)，剩下的 P0、 P2、 P4 都可被满足。 同理， 这些进程都可以加入安全序列。于是， 5个进程全部加入安全序列， 说明此时系统处于安全状态， 暂不可能发生死锁。

![image-20201229125251873][]

> **举例三：再看一个找不到安全序列的例子**

系统资源总数 (10, 5, 7)

![image-20201229125317569][]

经对比发现， （3, 3, 2） 可满足 P1、 P3， 说明无论如何， 这两个进程的资源需求一定是可以依次被满足的， 因此P1、 P3 一定可以顺利的执行完， 并归还资源。 可把 P1、 P3 先加入安全序列。

P1 和P3 归还资源后，系统可用的资源个数为：(2, 0, 0) + (2, 1, 1) + (3, 3, 2) = (7, 4, 3)，剩下的 P0 需要 (8, 4, 3)， P2 需要 (6, 5, 0)， P4 需要 (4, 3, 4)，因此任何一个进程都不能被完全满足。于是， 无法找到任何一个安全序列， 说明此时系统处于不安全状态， 有可能发生死锁。

![image-20201229125642046][]

> **银行家算法步骤**

假设系统中有 n 个进程， m 种资源。

每个进程在运行前先声明对各种资源的最大需求数，则可用一个 n\*m 的矩阵（可用二维数组实现） 表示所有进程对各种资源的最大需求数，不妨称为最大需求矩阵 Max， Max\[i, j\]=K 表示进程 Pi 最多需要 K 个资源 Rj。

同理， 系统可以用一个 n\*m 的分配矩阵 Allocation 表示对所有进程的资源分配情况。 Max – Allocation = Need 矩阵， 表示各进程最多还需要多少各类资源。另外， 还要用一个长度为 m 的一维数组 Available 表示当前系统中还有多少可用资源。

另外， 还要用一个长度为m的一维数组 Available 表示当前系统中还有多少可用资源。某进程Pi向系统申请资源， 可用一个长度为 m 的一维数组 Requesti 表示本次申请的各种资源量。

![image-20201229130127000][]

> **银行家算法伪代码**

可用银行家算法预判本次分配是否会导致系统进入不安全状态：

①如果 Requesti\[j\]≤Need\[i, j\] (0≤j≤m)便转向②（进程请求的资源数小于它实际需要的资源数）； 否则认为出错。

②如果 Requesti\[j\]≤Available\[j\] (0≤j≤m)， 便转向③（系统可用资源数大于进程所申请的资源数） ； 否则表示尚无足够资源， Pi必须等待。

③系统试探着把资源分配给进程Pi， 并修改相应的数据（并非真的分配， 修改数值只是为了做预判） ：

Available = Available - Requesti;（更新可用资源数）  
Allocation\[i, j\] = Allocation\[i, j\] + Requesti\[j\];（更新已分配的资源数）  
Need\[i, j\] = Need\[i, j\] – Requesti\[j\];（更新各进程最多还需的资源数）

④操作系统执行安全性算法， 检查此次资源分配后， 系统是否处于安全状态。 若安全， 才正式分配； 否则， 恢复相应数据， 让进程阻塞等待。

![image-20201229130243983][]

> **银行家算法总结**

数据结构：

1.  长度为 m 的一维数组 Available 表示还有多少可用资源
2.  n\*m 矩阵 Max 表示各进程对资源的最大需求数
3.  n\*m 矩阵 Allocation 表示已经给各进程分配了多少资源
4.  Max – Allocation = Need 矩阵表示各进程最多还需要多少资源
5.  用长度为 m 的一位数组 Request 表示进程此次申请的各种资源数

> **银行家算法步骤**

①检查此次申请是否超过了之前声明的最大需求数

②检查此时系统剩余的可用资源是否还能满足这次请求

③试探着分配， 更改各数据结构

④用安全性算法检查此次分配是否会导致系统进入不安全状态

> **安全性算法步骤**

1.  检查当前的剩余可用资源是否能满足某个进程的最大需求， 如果可以， 就把该进程加入安全序列，并把该进程持有的资源全部回收。
2.  不断重复上述过程， 看最终是否能让所有进程都加入安全序列

## 26、死锁的处理策略——检测和解除 ##

### 26.1、思维导图 ###

> **如果出现思索了应该怎么呢？**

如果系统中既不采取预防死锁的措施， 也不采取避免死锁的措施， 系统就很可能发生死锁。 在这种情况下， 系统应当提供两个算法：

①死锁检测算法： 用于检测系统状态， 以确定系统中是否发生了死锁。

②死锁解除算法： 当认定系统中已经发生了死锁， 利用该算法可将系统从死锁状态中解脱出来。

![image-20201229130452627][]

### 26.2、死锁的检测 ###

> **死锁检测的步骤**

为了能对系统是否已发生了死锁进行检测， 必须：

①用某种数据结构来保存资源的请求和分配信息；

②提供一种算法， 利用上述信息来检测系统是否已进入死锁状态。

![image-20201229130535910][]

> **举个栗子**

1.  P1 和 P2 表示进程，R1 和 R2 表示资源（里面有多少个圆圈就表示有多少个资源）
2.  R1 到 P1 的边为分配边，表示 R1 资源被分配给 P1 进程，有多少个条边就表示被分配了多少个资源
3.  P1 到 R2 的边为请求边，表示 P1 进程想要请求占用 R2 资源，有多少条边就表示想要申请多少个资源

![image-20201229130558503][]

--------------------

Tips：学习过数据结构——图的同学可以动手尝试一下如何定义这个数据结构

> **如何进行死锁的检测**

如果系统中剩余的可用资源数足够满足进程的需求， 那么这个进程暂时是不会阻塞的， 可以顺利地执行下去。如果这个进程执行结束了把资源归还系统， 就可能使某些正在等待资源的进程被激活， 并顺利地执行下去。相应的， 这些被激活的进程执行完了之后又会归还一些资源， 这样可能又会激活另外一些阻塞的进程…

如果按上述过程分析， 最终能消除所有边， 就称这个图是可完全简化的。 此时一定没有发生死锁（相当于能找到一个安全序列）

如果最终不能消除所有边， 那么此时就是发生了死锁。

最终还连着边的那些进程就是处于死锁状态的进程。

--------------------

> **举个栗子**

1.  初始状态
    
    ![image-20201229131440321][]
2.  P1 进程申请到 R1 资源，执行完毕后所占用的释放资源
    
    ![image-20201229132407016][]
3.  P2 进程申请到 R1 资源，执行完毕后所占用的释放资源。可以看到，这种情况下可以消除所有的边，说明未发生死锁
    
    ![image-20201229131846732][]

> **再举个栗子**

1.  初始状态
    
    ![image-20201229132109834][]
2.  P3 进程申请到 R2 资源，执行完毕后所占用的释放资源，但是 P1 和 P2 进程形成死锁
    
    ![image-20201229132118474][]

> **检测死锁的算法**

1） 在资源分配图中， 找出既不阻塞又不是孤点的进程 Pi（即找出一条有向边与它相连， 且该有向边对应资源的申请数量小于等于系统中已有空闲资源数量。 如下图中， R1没有空闲资源， R2有一个空闲资源。 若所有的连接该进程的边均满足上述条件， 则这个进程能继续运行直至完成， 然后释放它所占有的所有资源） 。 消去它所有的请求边和分配变， 使之称为孤立的结点。 在下图中，P1 是满足这一条件的进程结点， 于是将P1的所有边消去。

2） 进程 Pi 所释放的资源， 可以唤醒某些因等待这些资源而阻塞的进程， 原来的阻塞进程可能变为非阻塞进程。 在下图中， P2 就满足这样的条件。 根据 1） 中的方法进行一系列简化后， 若能消去途中所有的边， 则称该图是可完全简化的。

![image-20201229131440321][image-20201229131440321 1]

--------------------

**死锁定理**： 如果某时刻系统的资源分配图是不可完全简化的， 那么此时系统死锁

既然检测到死锁， 那就要想办法解除

### 26.3、死锁的解除 ###

> **死锁解除的解决办法**

一旦检测出死锁的发生， 就应该立即解除死锁。补充： 并不是系统中所有的进程都是死锁状态， 用死锁检测算法化简资源分配图后， 还连着边的那些进程就是死锁进程

解除死锁的主要方法有：

1.  资源剥夺法。 挂起（暂时放到外存上） 某些死锁进程， 并抢占它的资源， 将这些资源分配给其他的死锁进程。 但是应防止被挂起的进程长时间得不到资源而饥饿。
2.  撤销进程法（或称终止进程法） 。 强制撤销部分、 甚至全部死锁进程， 并剥夺这些进程的资源。 这种方式的优点是实现简单， 但所付出的代价可能会很大。 因为有些进程可能已经运行  
    了很长时间， 已经接近结束了， 一旦被终止可谓功亏一篑， 以后还得从头再来。
3.  进程回退法。 让一个或多个死锁进程回退到足以避免死锁的地步。 这就要求系统要记录进程的历史信息， 设置还原点。

> **如何决定“对谁动手”**

1.  进程优先级
2.  已执行多长时间
3.  还要多久能完成
4.  进程已经使用了多少资源
5.  进程是交互式的还是批处理式的

### 26.4、本节课小结 ###

![image-20201229131543698][]

[image-20201218085942983]: /images/20221023/f9b9c0a8099248008ca00581b4af3b34.png
[image-20201218093210186]: /images/20221023/1d73815f3cf747238d9f9b7328e10fa2.png
[image-20201218093815262]: /images/20221023/42e5c23aaecf4ce0ba2372d6f2f231e3.png
[image-20201218094011860]: /images/20221023/2e597384cede4251a03a27ed3c5ef752.png
[image-20201218094042707]: /images/20221023/8f98097e52854faca860a549b7653965.png
[image-20201218094234026]: /images/20221023/ff872df230804675bbe32530b893f9fd.png
[image-20201218094321580]: /images/20221023/0e2a5b59b07c4d16828b1a01191a6f95.png
[image-20201218094556826]: /images/20221023/b81c2b845416464492c5851da6bf6ec1.png
[image-20201218132154347]: /images/20221023/94d0fb2eac3949cbbd6dee0bb3349a52.png
[image-20201218132009062]: /images/20221023/563d1ab0cd71419f84881c422cb449e3.png
[image-20201218134618372]: /images/20221023/7730fb93bc8345d7ba362929b3be3273.png
[image-20201218135012834]: /images/20221023/46a143ba781c48d6bdc447c64de859e7.png
[image-20201218135038780]: /images/20221023/b9fbbecc2ee6459a87cbd6bf87348600.png
[image-20201218132112376]: /images/20221023/fa3dc3913c8046f0b082230ffd7deef3.png
[image-20201218132726292]: /images/20221023/46621624587b41339b0dcd4a7eb37d8c.png
[image-20201218132739661]: /images/20221023/b66904fcfb75402ca411a7546b20d714.png
[image-20201218135136328]: /images/20221023/c9af11524e904601b207383abfcb9c3f.png
[image-20201218142556495]: /images/20221023/b328f73b809f4d3c9d4400763eaca1dd.png
[image-20201218141927600]: /images/20221023/b303176f8e3540f1b2e671443de5b835.png
[image-20201218142229188]: /images/20221023/5468c573729d479d9f81b8637991dfbd.png
[image-20201218142310200]: /images/20221023/87480ad075c44fb3a346f24911165a75.png
[image-20201218142608986]: /images/20221023/cf00c81f4f114bf19a14b6016dc5ab56.png
[image-20201218143322931]: /images/20221023/b73d224ee08149c99786a49e9d4a830e.png
[image-20201218143404330]: /images/20221023/6ad8153c1dd84e59a4135f7f13ca1884.png
[image-20201218143446378]: /images/20221023/4b7fe06aafd446d88606166b07c6ecc5.png
[image-20201218143732086]: /images/20221023/b00217645cf840edbb6e3b04e27fcd0b.png
[image-20201218143748962]: /images/20221023/189ab02fbbae4690a7434e632c8f5d76.png
[image-20201218143938249]: /images/20221023/112bc7e5ccd64210bf40797432b8911b.png
[image-20201218144017799]: /images/20221023/805156782e4144979489ec96b7dbc400.png
[image-20201218144256367]: /images/20221023/af72c4a132d84c36957d1d8c8084bfd7.png
[image-20201218144407550]: /images/20221023/68ae33edba094f998f5cc6fd8644655b.png
[image-20201218144639414]: /images/20221023/20dec8dd43be43c8bdc02bb57d0f8013.png
[image-20201218144902747]: /images/20221023/fb262afc7b304458900c5e81067c32fd.png
[image-20201218145252330]: /images/20221023/78f7942150a04cc0a19d2ebcdc3acb54.png
[image-20201218145345123]: /images/20221023/7e749518c3234e129f7dd87e8f226181.png
[image-20201218145715294]: /images/20221023/a85531d1148e48638d9dd87cdf87d6b9.png
[image-20201218150502718]: /images/20221023/31d97e87208848928fc97ac5a4b02e4e.png
[image-20201218150505631]: /images/20221023/d3c3ec3af022462da1ad453a930226df.png
[image-20201218145145641]: /images/20221023/de97f46512a34223b680eb4060fda35a.png
[image-20201218150802851]: /images/20221023/61d7d57938894ac48207fddf0751d64f.png
[image-20201218150837380]: /images/20221023/b8f5e3b02436462db4d134f067f95ef0.png
[image-20201218150855646]: /images/20221023/b50433c82e5746ff8b77c0d2e85e1cf4.png
[image-20201218150953309]: /images/20221023/a70827eb7a8a40dc9f0a745050234a1d.png
[image-20201218151016526]: /images/20221023/f9d90762f28444f180ab884cdcd5fc0b.png
[image-20201218151228124]: /images/20221023/91e444114d8b462db080daf4d7b27846.png
[image-20201218151445286]: /images/20221023/bb3d6f26ac2842b595b974ddecf938a6.png
[image-20201218151839546]: /images/20221023/4a5adc83eaee4d15a6f4110162c9cec0.png
[image-20201218151903125]: /images/20221023/d5ac2bcbc04c4603b728809979fd5649.png
[image-20201218152437336]: /images/20221023/690c385f82364ddfbdaa52642d7fa8e0.png
[image-20201218152512650]: /images/20221023/c180f9dea9ad486fada817c74d5098a2.png
[image-20201218152539820]: /images/20221023/17316505444442ba831d217b155ae283.png
[image-20201218152649895]: /images/20221023/fc6d7686687f48cabf01b197d4bea300.png
[image-20201218152840806]: /images/20221023/8dc2910244f64cdd94d154f1c018cd8f.png
[image-20201218153410524]: /images/20221023/22d08da6b98a4c97ad68ab24fecabd44.png
[image-20201218153716209]: /images/20221023/af034f31df104549aa15a442a083adab.png
[image-20201218153809063]: /images/20221023/ed5d47c57e5a4e2a9e27680ea7c63b85.png
[image-20201218154003391]: /images/20221023/68cc1d7f0c5e4d8c86f10ed35a363ca0.png
[image-20201218154153062]: /images/20221023/78b5d9c7efe441de94e4ef3e5f432406.png
[image-20201221102853214]: /images/20221023/6f770ca015c7415bbe042cae209097d5.png
[image-20201221104423839]: /images/20221023/a3881b6d59f54d368ba27946b71698ec.png
[image-20201221104439086]: /images/20221023/0e89d84151ab43f997c8564fe6e1287c.png
[image-20201221104546598]: /images/20221023/783f2815367e40d1877be3afe435ee21.png
[image-20201221104619839]: /images/20221023/2b96da944af242a1a8e059e99673415e.png
[image-20201221104658737]: /images/20221023/155c00ba807240b3b0ab712e3a75f21c.png
[image-20201221104908339]: /images/20221023/73c1c1ab3b964820ae2cdbd357777dac.png
[image-20201221105014716]: /images/20221023/e88716ffc59c484b8b7dba4d583b7342.png
[image-20201221105138627]: /images/20221023/0d8e7190a3e3404c94c2b9fb755739cd.png
[image-20201221110444114]: /images/20221023/568785fae7d1482baddc6aaf0d376ac6.png
[image-20201221112734910]: /images/20221023/1704e0f51c4d49ebb4e7152e33484c5d.png
[image-20201221122253142]: /images/20221023/283a88b9f92941108f2e260ce461d52b.png
[image-20201221141114922]: /images/20221023/816609f7231c4e51ba3aa5bb710ff019.png
[image-20201221142917250]: /images/20221023/192909a17fff4031ade726b17ad5b7bf.png
[image-20201221143124793]: /images/20221023/7fc4e54ff18a4a7ab1bc44ec041aa2ed.png
[image-20201221143158555]: /images/20221023/70dc7710d6414be49bfdf8ebba5da1d1.png
[image-20201221143735352]: /images/20221023/2973f96c27a6409f8670aae3b5690027.png
[image-20201221144427924]: /images/20221023/6220da91379d4f7ab050e9730ac6840d.png
[image-20201221144730287]: /images/20221023/3ea0cdece54f42c796428a3ff01369b8.png
[image-20201221145841914]: /images/20221023/576708aa15b346fd870318ae4b11c2c8.png
[image-20201221150146784]: /images/20221023/b87ecf0ef6c84fd6b9466ceecba0fb82.png
[image-20201221150229550]: /images/20221023/5996943873644cb6a478cc12516e024e.png
[image-20201221151112946]: /images/20221023/4c4a3db626644479bd2d26c5d043a703.png
[image-20201221151136965]: /images/20221023/d3efb19b9de144bbb8bfac6343e94167.png
[image-20201221151154206]: /images/20221023/63b649ecef3a43bdb6de070179860dfd.png
[image-20201221151218737]: /images/20221023/44c644185e2542c49ee6fa36a6a366cd.png
[image-20201221151256786]: /images/20221023/e7bcf8b1a9644733a29b18f3ebfc93dd.png
[image-20201221151308131]: /images/20221023/2fd0ce7f78e44e4da8728a258bfe1e4a.png
[image-20201221151318331]: /images/20221023/2800682713664a85bb6ddf58d6d892ce.png
[image-20201221151329879]: /images/20221023/1c6828569acf4ad88902cefdb422aec5.png
[image-20201221151548254]: /images/20221023/4254093f793d4483aa31e1742efd435a.png
[image-20201221151341561]: /images/20221023/0df5b4e7d387463096a8d1c8499a7e23.png
[image-20201221151700354]: /images/20221023/7ecce66fd86c4ee499b26eecc82e263b.png
[image-20201221152917160]: /images/20221023/efb4ffc664a74b0a9a2f764dd67d1c3b.png
[image-20201221153003786]: /images/20221023/a20edbbff69844d9a431692f4232d7eb.png
[image-20201221154520333]: /images/20221023/8271611646ee47c0ab564da1da695893.png
[image-20201221154705993]: /images/20221023/717a6d7eeb354029b752b1cda2c24c66.png
[image-20201221154710765]: /images/20221023/e097383947c54d7f88dd215894c8edb4.png
[image-20201221154823449]: /images/20221023/4146d6698b3c40ef8f607bae2b740508.png
[image-20201221154845541]: /images/20221023/4d8fea7f1c7b4b039826046385038cff.png
[image-20201221154907864]: /images/20221023/098c6a7362cd4020bdd1ec2109e15ee1.png
[image-20201221154946207]: /images/20221023/82b880c9d03f44e1899a91bbd4969243.png
[image-20201221155051824]: /images/20221023/fe0a2d281755477ab7a0c78a70b3794e.png
[image-20201221155100496]: /images/20221023/cbe96cda147b41ecb4f8fa16cb1090f0.png
[image-20201221155300015]: /images/20221023/7b6f9811ca304d4191712ef832321e8b.png
[image-20201221155316894]: /images/20221023/11e4550f852b4672a71e84696d6d8a48.png
[image-20201221155347385]: /images/20221023/99f8b6faf0e748a4842f81627e40d70e.png
[image-20201221153805755]: /images/20221023/7c2b81f003374c6a860c11939d3f651d.png
[image-20201221160652620]: /images/20221023/9219a79bf88a44089c91186665be4a71.png
[image-20201221185048122]: /images/20221023/35a9d23e71d24842b8f34db4bfa7a9f9.png
[image-20201221185229814]: /images/20221023/0a2c3d467d394f8b8381bf5262cc286c.png
[image-20201221185344073]: /images/20221023/c5d00d15e2d54be7b7ebc6587515ea8f.png
[image-20201221185545963]: /images/20221023/4cf53ee8371c44cc91bda840a5aa791d.png
[image-20201221190117340]: /images/20221023/9164f822f86d4e39afa3684bae98e607.png
[image-20201221190159687]: /images/20221023/fc44e7e7b614419a8ad48753146bb8d8.png
[image-20201221190337082]: /images/20221023/658bf4a5899242038dc54e7423285c86.png
[image-20201221190405613]: /images/20221023/9df72f24dbd84ff6aeb9a8b5c6d29c31.png
[image-20201221190516527]: /images/20221023/ec55339ef83e4fcbac656601090b782b.png
[image-20201221190656026]: /images/20221023/4428be8cc1e2466ebbb63f30a59cf109.png
[image-20201221190722806]: /images/20221023/f23173008c7845c497b96a5423f5f588.png
[image-20201221190743655]: /images/20221023/e75fe8d69c2f443886861fd29d95dced.png
[image-20201221190825843]: /images/20221023/9bf10fed74674f8d8fc82c2df0bc15ce.png
[image-20201221191115134]: /images/20221023/31859e794426498aa2656b9b273bad49.png
[image-20201221191135495]: /images/20221023/27f8deadb53343a7b72d0c6ed096f5ef.png
[image-20201221191214390]: /images/20221023/4b68d66c8a684c548041929f4e584219.png
[image-20201221191500747]: /images/20221023/b56b6c43211243c388518f2a262a6a20.png
[image-20201221191505991]: /images/20221023/0cd989b3b74940c99e36c4c0f2e8e638.png
[image-20201221191524585]: /images/20221023/d19f0ea31bb64817a7b862196b2725b1.png
[image-20201221191728953]: /images/20221023/89d9992f1307468ba7d13675465188bb.png
[image-20201221192305605]: /images/20221023/658fb63cf58449529aab1a1ccab459f4.png
[image-20201221192446256]: /images/20221023/821e61612dc3427f9a84cdc19f208580.png
[image-20201221192544628]: /images/20221023/b41982a116b743139c32c6b8210d4758.png
[image-20201221192620487]: /images/20221023/fdd11d21766f48afb16215f8445c726d.png
[image-20201221195057854]: /images/20221023/0e66fede530c49c0aefa331645a2b7f9.png
[image-20201225220028296]: /images/20221023/1578b5b6a2654b6caa4baf8983fd2da6.png
[image-20201225220115364]: /images/20221023/df236ed853d04a2f8b41dd5d0b5f849d.png
[image-20201225220214426]: /images/20221023/1effe5c6f43f45f8a7db4af8da46145b.png
[image-20201225220243851]: /images/20221023/74c030ff3e654b32a36a2b886f7532a0.png
[image-20201225220311940]: /images/20221023/4ab8d3dd5f784f2ab197d61ef1ecef04.png
[image-20201225220512184]: /images/20221023/bbceeee4746c4c3cb1e812dae9fb0e65.png
[image-20201225220922141]: /images/20221023/8e9f7a8904e949669eafd04a6b49644a.png
[image-20201225221105765]: /images/20221023/2130fdf814c24a168830f39d5932331d.png
[image-20201225221249464]: /images/20221023/01290aa6be3a4d84b95c7bbaaf7c2544.png
[image-20201225221348531]: /images/20221023/3203fb82af0b4430b4cc507c5e37bb86.png
[image-20201225221423403]: /images/20221023/98456f20d0914a7bbec87f054ec6501d.png
[image-20201225221441148]: /images/20221023/9cd2795263f3447081756ce8f35c0be2.png
[image-20201225221529735]: /images/20221023/6c66f7b2a50848a9a04d9d9afaeb2254.png
[image-20201225221547140]: /images/20221023/8243e05f64614225ab0cdca8911bce81.png
[image-20201225221736623]: /images/20221023/88f7ae0c122e470f861f81309c2e450c.png
[image-20201225221739634]: /images/20221023/ea4626b0d9f44c128dfd2c96d45ee387.png
[image-20201225221829066]: /images/20221023/f3203f82da3448f89e58dd4c208ae0cc.png
[image-20201225221924183]: /images/20221023/b54ee704696d45478a385cf350590945.png
[image-20201225222056991]: /images/20221023/b78e31541fa943c7b716e9621525e999.png
[image-20201225222133163]: /images/20221023/1f8e72c918b04188b4321dde9e1734ac.png
[image-20201225222221417]: /images/20221023/63076bfc4fb140cc88db87feb1daa786.png
[image-20201225222354720]: /images/20221023/b84b2759dc0a4e069ccfc1a42f2375ee.png
[image-20201225222455883]: /images/20221023/f94a8f086bf44aaeacbce092a1613ba6.png
[image-20201225222511090]: /images/20221023/b73178fc126d49d0986b2961792629c0.png
[image-20201225222526386]: /images/20221023/a2b4edd0c57f4cbbac180ea63d7addec.png
[image-20201225222946839]: /images/20221023/5b5c85a6cd4046d5bead0390a2adf09d.png
[image-20201225223015377]: /images/20221023/0812e9a4a5774c09b4706f502d0469b2.png
[image-20201225223102458]: /images/20221023/32b27a9d6a3d4f5a9fec0477f8832691.png
[image-20201225223124665]: /images/20221023/0d057954923142e59556bdd7de4e3045.png
[image-20201225223249870]: /images/20221023/77a3f32eff094b1abd11a1b946d3c0b1.png
[image-20201225224134383]: /images/20221023/804bda8c62cf4c40a6a1f5c8a4fc51f4.png
[image-20201225224210643]: /images/20221023/f45e7d8132534e7fa051dbf8e8bc43ce.png
[image-20201225224440709]: /images/20221023/d33653079f3e4978b7d514d6da1adb5f.png
[image-20201225224615547]: /images/20221023/f4d5211d4b9f431b852b195decff7c70.png
[image-20201225224706818]: /images/20221023/4227145c89ab451ebb30552aead1689c.png
[image-20201225224827782]: /images/20221023/31cbc2f839554bfe9a7799b7160114fa.png
[image-20201225225007075]: /images/20221023/9e23bd9f94134e569eb3dcf301f4cf55.png
[image-20201225225438679]: /images/20221023/44aeb37ce2744712b52ca64f6d73e011.png
[image-20201225225521551]: /images/20221023/a1be3b1107cc4a9aa4177874338de07d.png
[image-20201225225542467]: /images/20221023/be35885ff5434138bd1a3eb3c2e93509.png
[image-20201225225542467 1]: /images/20221023/126c13d8b809494283c42afe43462ff1.png
[image-20201225230039724]: /images/20221023/33f1b2f9984d415dbe052e7c48866be8.png
[image-20201225230052499]: /images/20221023/796730271922443caa8a4afc613d1834.png
[image-20201226195915492]: /images/20221023/921e8adf3205443f808e9759a68b45dc.png
[image-20201226195929687]: /images/20221023/bdec3ce53fa1498c917a0d846a6fd517.png
[image-20201226195944641]: /images/20221023/004454ddd9644d6f89571d63ffeec30e.png
[image-20201226200425454]: /images/20221023/81a0699b36df4471ae43b56f15d929d3.png
[image-20201227210928554]: /images/20221023/b386f579a6e544e4a206951f77703a63.png
[image-20201228182716414]: /images/20221023/44d075507db04abfbad960be3c0b5aa5.png
[image-20201228183456427]: /images/20221023/8e9f1b2518a14665a2e5e9fa47d4b754.png
[image-20201228183903441]: /images/20221023/3513f727faf0401da046fe68ec3fae8f.png
[image-20201228184300557]: /images/20221023/5910d03082644c94a030cc2faf117cbf.png
[image-20201228184929253]: /images/20221023/19311d2e6f304ae386e8b00441b01a0f.png
[image-20201228185358901]: /images/20221023/017ca3da168b4ca086f24f919cd7dcd7.png
[image-20201228185603219]: /images/20221023/ca79ea9b7aaf447aa5d19d8618b1fd80.png
[image-20201228185837821]: /images/20221023/8b952ca07e0f4010bca5d3f063d763c3.png
[image-20201228191734900]: /images/20221023/3d544e478a66402fb952af9339c8d57b.png
[image-20201228191911837]: /images/20221023/17d875ba21df47a9871fc8f9e576cc99.png
[image-20201228192008894]: /images/20221023/15b023c685c74cf0accd1fb3e6c8fe80.png
[image-20201228192059068]: /images/20221023/724324b55d6c4572af464036a85d6fd6.png
[image-20201228192451465]: /images/20221023/dbc3c32dc3d846b18bb7690d272e795f.png
[image-20201228192835544]: /images/20221023/5aa08ba34b824d559aef0b56ea107582.png
[image-20201228192840501]: /images/20221023/6a7ad71c30004ad4b590640873c6b785.png
[image-20201228214014375]: /images/20221023/823733b55b1743069c9977eb09c674f5.png
[image-20201228214137563]: /images/20221023/7224b4a0dace427a9e07edb014636e10.png
[image-20201228214821723]: /images/20221023/d7a59725bc7c4807a6a1d53e63fe38f3.png
[image-20201228214940862]: /images/20221023/9fce8c21004348dfb7b272d9053358c3.png
[image-20201228214949556]: /images/20221023/7823859630a54cb6919b720b5c89071f.png
[image-20201228215420601]: /images/20221023/4fb10b6d7141460fac642320d1aa7892.png
[image-20201228214641088]: /images/20221023/e84c38be23c54669900ecb34ec4fd4c4.png
[image-20201228215550777]: /images/20221023/e390b5f3277d40e28bac8cc4eb95e0a0.png
[image-20201228215717463]: /images/20221023/63ede65fc2ec40389d36c6753c48e7be.png
[image-20201228215723632]: /images/20221023/d0626935fe21494f8e54d4925c7f7945.png
[image-20201228215942650]: /images/20221023/d5c50f3e055f4e5ab4af878dd8b57f4a.png
[image-20201228215946615]: /images/20221023/d5bb463b553f4ae1a896d00a22062664.png
[image-20201228220201709]: /images/20221023/35b7ad5670ae4de9a6d2c6225abd0ef3.png
[image-20201228220447339]: /images/20221023/aba3c9eb8cec437b979657b488e42986.png
[image-20201228220451094]: /images/20221023/740bede168e747089be61e45f4b775cd.png
[image-20201228220731331]: /images/20221023/4f1eddbaef6541d7a88b16ac373acfb9.png
[image-20201228220756567]: /images/20221023/aaf2178d0fc64a7ab81b933565eff4d5.png
[image-20201228221123836]: /images/20221023/00982716b36046ae90b4317680c7915e.png
[image-20201228221202341]: /images/20221023/eaf0d007a64b4c0d99880c0240754e98.png
[image-20201228221222245]: /images/20221023/c86733f148a74ce2843dc93db6dc8506.png
[image-20201228221248191]: /images/20221023/3d4179ba4d9e490db2b029de8116f0a6.png
[image-20201228221709487]: /images/20221023/f4bbc3800e524e3eb2da19a8a050b51c.png
[image-20201228222034984]: /images/20221023/c75ffbb60b7f4e8385d8bdf9b1540fcd.png
[image-20201228222058630]: /images/20221023/1005964fee46471e9b7686ca0697bfc1.png
[image-20201229122418184]: /images/20221023/de0def2a0658421d899b42b3c760bd8e.png
[image-20201229122858117]: /images/20221023/bde7f37369b5465aad1c598db3d37a2b.png
[image-20201229123100093]: /images/20221023/0fc07bba19944a149a8efbe58d40a3f5.png
[image-20201229123100093 1]: /images/20221023/1d124fcab42e4603bc33641b9f34694f.png
[image-20201229123912635]: /images/20221023/800b4828b0784ce6b0f1b49d13e16cc3.png
[image-20201229123942275]: /images/20221023/f322b7a248be4e6c8c1d567653848fd8.png
[image-20201229124330256]: /images/20221023/3c50bd77b2a54664963716802d0e891a.png
[image-20201229124626433]: /images/20221023/581286d3c3a2424c873e536875102228.png
[image-20201229124653858]: /images/20221023/6eb6af6916f44ceca7ecf0a7827887e1.png
[image-20201229124710247]: /images/20221023/9f93f3d395174c22818b4adb370056a1.png
[image-20201229124837247]: /images/20221023/4c839a565e2640d0afc5c6378b7ff0f3.png
[image-20201229124917357]: /images/20221023/693ec0648eba412888bc8eac6ccfb1ad.png
[image-20201229125251873]: /images/20221023/e95145cf6fe94b0f962e6cd27539d0ee.png
[image-20201229125317569]: /images/20221023/31baec81043e46aeb14832ed6cafd966.png
[image-20201229125642046]: /images/20221023/60eb6e9caf194ad0a2f72d67c1caf7f8.png
[image-20201229130127000]: /images/20221023/540dc116878f4530bf5df75b6d8d0b69.png
[image-20201229130243983]: /images/20221023/ede5f70251d845a3aa1f3951e3dfdb55.png
[image-20201229130452627]: /images/20221023/00fa8d1011484483880c5ffe22deb42c.png
[image-20201229130535910]: /images/20221023/e925be5511824bdba28a345b89487d11.png
[image-20201229130558503]: /images/20221023/ef090569ebe642d9888175e0f1c506a6.png
[image-20201229131440321]: /images/20221023/2f813532999e4842946f2924b5145bd2.png
[image-20201229132407016]: /images/20221023/e004b32aedda4b9281689c594ce3e442.png
[image-20201229131846732]: /images/20221023/6aeda8b45e6e425998f0e1dd74569088.png
[image-20201229132109834]: /images/20221023/a436f64bfe47423ca27fbc4ca786940d.png
[image-20201229132118474]: /images/20221023/e97a20d1744a48fd9ab72ce776398056.png
[image-20201229131440321 1]: /images/20221023/cbc505751cdc483fba620a9b92b8862a.png
[image-20201229131543698]: /images/20221023/f4202e3e13c5434eb4aba8055c13b2fa.png