随笔分类 - Win32多线程程序设计
1
使用 MtVerify.h头文件 ,用的时候把他头文件的内容添加到项目
摘要:#include <windows.h> //windodws变量相关头文件 MtVerify.h的内容如下:#pragma comment( lib, "USER32" ) #include <stdlib.h> #include <crtdbg.h> #define MTASSERT(a) _A
阅读全文
谈论如何有效地保护你的数据
摘要:谈论如何有效地保护你的数据,避免race condition 的侵扰。 如果操作系统有什么机制能够做你所需要的事情,使用它,不要犹豫。 例如,你可以使用“ anonymous pipes”,不必再自己写个多线程的环状缓冲区。Pipe或许不是最快、最精致、最有能力的解决方法,但是它们已经被完成、被测试
阅读全文
mutex锁住共用线程函数 造成了死锁 ,为什么?
摘要:锁住共用的线程函数,为什么出现了死锁的现象,是真的死锁了吗?为什么勒【清晰早点】 【逍遥游】# 一般都是用 EnterCriticalSection 和 LeaveCriticalSection 锁住和解锁访问的数据 【瓶子】# @天天快乐 你在自己的线程里等待自己结束,当然锁死了! @天天快乐 你
阅读全文
线程函数执行次数
摘要:为什么让线程函数执行5次,实际运行却不止5次 为什么让线程函数执行5次,实际运行却不止5次 试着运行好多次都大于5次函数执行输出 【逍遥游】# 我认为问题出在 printf 函数,处理显示的函数都不能在线程里面用,包括窗口界面和控制台界面都是这样 【§Victor§】# 你把要输出的数据, 放入缓冲
阅读全文
第6章 Overlapped I/O, 在你身后变戏法 ---被激发的 Event 对象 -4
摘要:以文件 handle 作为激发机制,有一个明显的限制,那就是没办法说出到底是哪一个 overlapped 操作完成了。如果每个文件 handle 只有一个操作等待决定,上述问题其实并不成为问题。但是如我稍早所说,系统有可能同时接受数个操作,而它们都使用同一个文件 handle。于是很明显地,为每一个
阅读全文
第6章 Overlapped I/O, 在你身后变戏法 ---被激发的 File Handles -3
摘要:最简单的 overlapped I/O 类型,是使用它自己的文件 handle 作为同步机制。首先你以 FILE_FLAG_OVERLAPPED 告诉 Win32 说你不要使用默认的同步 I/O。然后,你设立一个 OVERLAPPED 结构,其中内含“I/O 请求”的所有必要参数,并以此识别这个“I
阅读全文
第6章 Overlapped I/O, 在你身后变戏法 ---Win32 文件操作函数 -2
摘要:Win32 之中有三个基本的函数用来执行 I/O,它们是: i CreateFile() i ReadFile() i WriteFile() 没有另外哪一个函数用来关闭文件,只要调用 CloseHandle() 即可。本章对于这些函数将只涵盖其与 overlapped I/O 有关的部分,至于其他
阅读全文
第6章 Overlapped I/O, 在你身后变戏法 ---1
摘要:这一章描述如何使用 overlapped I/O(也就是 asynchronous I/O)。某些时候 overlapped I/O 可以取代多线程的功用。然而,overlapped I/O 加上completion ports,常被设计为多线程处理,以便在一个“受制于 I/O 的程序”(所谓 I/
阅读全文
第5章 不要让线程成为脱缰的野马(Keeping your Threads on Leash) ----初始化一个线程
摘要:使用线程的一个常见问题就是如何能够在一个线程开始运行之前,适当地将它初始化。初始化最常见的理由就是为了调整优先权。另一个理由是为了在SMP 系统中设定线程比较喜欢的 CPU。第10 章谈到 MFC 时我们会看到其他一些理由。 基本问题在于,你需要一个线程 handle,才能够调整线程的性质。但如果你
阅读全文
第5章 不要让线程成为脱缰的野马(Keeping your Threads on Leash) ---线程优先权(Thread priority)
摘要:有没有过这样的经验?你坐在你的车子里,目的地还在好几公里之遥,而时间已经很晚了。你拼命想告诉那些挡住你去路的人们,今天这个约会对你是多么多么重要,能不能请他们统统……呃……滚到马路外?很不幸,道路系统并没有纳入所谓的优先权观念。如果有某条专用道是给“非常重要”的通行所用的,你就可以摆脱那些如潮水般在
阅读全文
第5章 不要让线程成为脱缰的野马(Keeping your Threads on Leash) ---干净的终止一个线程
摘要:干净的终止一个线程 我曾经在第2章产生一个后台线程,用以输出一张屏幕外的 bitmap 图。我们必须解决的一个最复杂的问题就是,如果用户企图结束程序,而这张bitmap 图尚未完成,怎么办?第2章的一个鸵鸟做法就是在任何 worker 线程还没完成其工作之前,不准用户结束程序。只要修改主消息循环,使
阅读全文
第5章 不要让线程成为脱缰的野马(Keeping your Threads on Leash) ---简介
摘要:这一章描述如何初始化一个新线程,如何停止一个执行中的线程,以及如何了解并调整线程优先权。 读过这一章之后,你将有能力回答一个 Win32 多线程程序设计的最基本问题。你一定曾经在 Usenet 的 Win32 论坛中一再地看过这个问题。当我开始在 Win32 上使用线程时,这个问题就一直在折磨我。我
阅读全文
第4章 同步控制 Synchronization ----同步机制的摘要
摘要:同步机制摘要Critical Section Critical section(临界区)用来实现“排他性占有”。适用范围是单一进程的各线程之间。它是: 一个局部性对象,不是一个核心对象。 快速而有效率。 不能够同时有一个以上的 critical section 被等待。 无法侦测是否已被某个线程放弃
阅读全文
第4章 同步控制 Synchronization ----Interlocked Variables
摘要:同步机制的最简单类型是使用 interlocked 函数,对着标准的 32 位变量进行操作。这些函数并没有提供“等待”机能,它们只是保证对某个特定变量的存取操作是“一个一个接顺序来”。稍后我会把这些 interlocked 函数展示出来,因为唯有你自己亲身比较它们和其他同步机制的差异,才能够了解它们
阅读全文
第4章 同步控制 Synchronization ----事件(Event Objects)
摘要:Win32 中最具弹性的同步机制就属 events 对象了。Event 对象是一种核心对象,它的唯一目的就是成为激发状态或未激发状态。这两种状态全由程序来控制,不会成为 Wait...() 函数的副作用。 Event 对象之所以有大用途,正是因为它们的状态完全在你掌控之下。Mutexes 和 sem
阅读全文
第4章 同步控制 Synchronization ----信号量(Semaphore)
摘要:许多文件中都会提到 semaphores(信号量),因为在电脑科学中它是最具历史的同步机制。它可以让你陷入理论的泥淖之中,教授们则喜欢问你一些有关于信号量的疑难杂 症。你可能不容易找到一些关于 semaphores 的有用例子,但是我告诉你,它是解决各种 producer/consumer 问题的关
阅读全文
第4章 同步控制 Synchronization ----互斥器(Mutexes)
摘要:Win32 的 Mutex 用途和 critical section 非常类似,但是它牺牲速度以增加弹性。或许你已经猜到了,mutex 是 MUTual EXclusion 的缩写。一个时间内只能够有一个线程拥有 mutex,就好像同一时间内只能够有一个线程进入同一个 critical sectio
阅读全文
第4章 同步控制 Synchronization ---哲学家进餐问题(The Dining Philosophers)
摘要:哲学家进餐问题是这样子的:好几位哲学家围绕着餐桌坐,每一位哲学家要么思考,要么等待,要么就吃饭。为了吃饭,哲学家必须拿起两支筷子(分放于左右两端)。不幸的是,筷子的数量和哲学家相等,所以每支筷子必须由两位哲学家共享。图4-1 显现出这种状态。? FAQ 16:我如何避免死锁? 哲学家都是有点倔强的人
阅读全文
第4章 同步控制 Synchronization ----死锁(DeadLock)
摘要:Jeffrey Richter 在他所主持的 Win32 Q&A 专栏(Microsoft Systems Journal,1996/07)中曾经提到过,Windows NT 和 Windows 95 在管理 dangling critical sections 时有极大的不同。在 Windows
阅读全文
第4章 同步控制 Synchronization ----critical section 互斥区 ,临界区
摘要:本章讨论 Win32 同步机制,并特别把重点放在多任务环境的效率上。撰写多线程程序的一个最具挑战性的问题就是:如何让一个线程和另一个线程合作。除非你让它们同心协力,否则必然会出现如第2章所说的“raceconditions”(竞争条件)和“data corruption”(数据被破坏)的情况。 在典
阅读全文
1