第三讲一个线程库的实现.ppt

第三讲 一个线程库的实现 本讲将讨论在Linux平台下，如何实现一个线程库，以让同学们体会利用现代程序设计思想，进行程序开发的方法 帮助同学们建立从高级语言到软件架构的映射 第三讲 一个线程库的实现 Linux的基本编程环境 日志的实现 线程的创建与终止 线程创建的封装 线程同步的封装 线程创建的再封装 Windows消息在Linux的重现 线程库的使用 第三讲 一个线程库的实现 Linux的基本编程环境 日志的实现 线程的创建与终止 线程创建的封装 线程同步的封装 线程创建的再封装 Windows消息在Linux的重现 线程库的使用 第三讲 一个线程库的实现 Linux的基本编程环境 日志的实现 线程的创建与终止 线程创建的封装 线程同步的封装 线程创建的再封装 Windows消息在Linux的重现 线程库的使用 日志的实现 本章围绕线程模型的程序库展开 当库中函数或系统API出错时，总希望把出错信息记录下来。这一任务通常是由日志来实现的 在本库中，假设日志信息被记录在文件中 日志的实现 出错处理 CLLog的实现 日志的实现 出错处理 CLLog的实现 线程库的出错处理 程序库对外提供若干类，每个方法出错时如何告知调用者是否出错，以及出错码？ 方法很多，为了简化起见，函数将返回一个对象，该对象保存了函数的返回值和出错码 线程库的出错处理 在线程库中，CLStatus类作为绝大多数方法的返回类型，其对象即保存了函数的返回值和出错码。 例： CLStatus Run(void *pContext); CLStatus的实现版本1（代码3.4） 线程库的出错处理 在3.4的实现中，需要调用GetErrorCode函数方可获得出错码，有无更为简便的方法 直接让m_lErrorCode成为public成员？ 能否有类内部可读可写，而外部只能读的数据成员？（代码3.5） CLStatus的使用者效率问题 由于CLStatus作为传值类型返回，存在一些效率优化的问题 代码3.6 CLStatus的使用者效率问题 为了兼顾移植性、提高效率，建议CLStatus的使用方式： 例： CLStatus f() { return CLStatus(…); } CLStatus s = f(); 日志的实现 出错处理 CLLog的实现 CLLog的实现 CLLog类用于记录程序库的日志信息到某个文件中，例如API调用出错、类库中某个方法调用出错等等 为了简化起见，文件中每条日志仅记录字符串的文字说明，以及出错码 代码3.7 CLLog的实现 代码3.7中，每次记录一条信息，都需要打开、关闭文件，效率不高 解决方法：将打开和关闭文件的操作，放在CLLog的构造和析构函数中 代码3.8 CLLog的实现 效率最高的情况是：在整个程序的运行过程中，日志文件只被打开、关闭一次。 这样一来，只能实例化CLLog一次，并将这次实例化的对象在整个程序中传递 如何改进？ 如何保证CLLog只能实例化一次 如何保证程序任何地方，都可以方便地获取CLLog对象 代码3.9 CLLog的实现 3.9的示例中，每次调用GetInstance，都需要调用者检查指针是否有效，能否简化 示例3.10 CLLog还存在的问题？ CLLog的实现 CLLog还存在的问题 多线程同时记录日志如何？ 目前，CLLog不是线程安全的；后续再改进 CLLog的实现 作业7 CLLog类的实现不是很高效 每次调用WriteLogMsg时，即调用了fwrite进行I/O操作 改进的办法是：CLLog可以提供一个缓存，如页面大小4k 用户每次调用WriteLogMsg等接口时，先将日志信息写入缓存 待缓存写满、程序退出、或者用户明确指示时，才将缓存内容写入日志文件 请实现带缓存的CLLog类 日志的实现 出错处理 CLLog的实现 第三讲 一个线程库的实现 Linux的基本编程环境 日志的实现 线程的创建与终止 线程创建的封装 线程同步的封装 线程创建的再封装 Windows消息在Linux的重现 线程库的使用 第三讲 一个线程库的实现 Linux的基本编程环境 日志的实现 线程的创建与终止 线程创建的封装 线程同步的封装 线程创建的再封装 Windows消息在Linux的重现 线程库的使用 线程创建的封装 基于对象的封装 面向对象的封装 基于接口的封装 面向对象的封装 示例3.15 为什么析构是虚的？ 能否封装变化点？ 耦合度如何？ 如何理解继承关系耦合度高？ 耦合于接口、耦合于实现 在3.15中，只能通过创建线程的方式执行业务逻辑 若现在需要通过创建进程的方式执行业务逻辑，该怎么办 基于接口的封装 不同的线程，通常处理不同的事情，即业务功能 如何对