使用线程池调用QueueUserWorkItem时不知道WT_EXECUTEDEFAULT和WT_EXECUTEINIOTHREAD哪个效率高

社会栋梁 2010-11-10 10:14:05
使用线程池调用QueueUserWorkItem时,
我要处理的工作是通过网络在共享文件夹大量的生成jpg文件
不知道此情况该用WT_EXECUTEDEFAULT还是WT_EXECUTEINIOTHREAD
我自己测试,效果不明显
请问有经验的朋友
哪个效率高?
谢谢


-------------------------
PS.
QueueUserWorkItem Function

Queues a work item to a worker thread in the thread pool.


BOOL WINAPI QueueUserWorkItem(
__in LPTHREAD_START_ROUTINE Function,
__in PVOID Context,
__in ULONG Flags
);

Flags
Value Meaning

WT_EXECUTEDEFAULT
0x00000000
By default, the callback function is queued to a non-I/O worker thread.

The callback function is queued to a thread that uses I/O completion ports, which means they cannot perform an alertable wait. Therefore, if I/O completes and generates an APC, the APC might wait indefinitely because there is no guarantee that the thread will enter an alertable wait state after the callback completes.

WT_EXECUTEINIOTHREAD
0x00000001
The callback function is queued to an I/O worker thread. This thread performs an alertable wait. This is less efficient, so this flag should be used only if the callback generates APCs to the current thread and the APC should be executed after the thread returns to the thread pool.

The callback function is queued as an APC. Be sure to address reentrancy issues if the function performs an alertable wait operation.

WT_EXECUTEINPERSISTENTTHREAD
0x00000080
The callback function is queued to a thread that never terminates. It does not guarantee that the same thread is used each time. This flag should be used only for short tasks or it could affect other timer operations.

Note that currently no worker thread is truly persistent, although worker threads do not terminate if there are any pending I/O requests.

WT_EXECUTELONGFUNCTION
0x00000010
The callback function can perform a long wait. This flag helps the system to decide if it should create a new thread.

WT_TRANSFER_IMPERSONATION
0x00000100
Callback functions will use the current access token, whether it is a process or impersonation token. If this flag is not specified, callback functions execute only with the process token.

Windows XP/2000: This flag is not supported until Windows XP SP2 and Windows Server 2003.
...全文
367 点赞 收藏 9
写回复
9 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
visualwind 2010-11-19
[Quote=引用 4 楼 robertbaker 的回复:]
QueueUserWorkItem API 会受别的程序影响!在某些情况下,飞信(仅以此为例,还有别的程序)在运行和没有飞信运行的 CPU 明显比较高,楼主可以自己留意一下,
具体原因不明,可能是 QueueUserWorkItem 的线程池为整个系统公有的?我没深究,不过我觉得QueueUserWorkItem的接口很好,我就用完成端口写了个仿QueueUserWorkItem接口的 dll,……
[/Quote]

飞信是.net做的,.net的线程池是逻辑上的线程,应该是基于WIN32 API的QueueUserWorkItem线程池,但他们并不是一个东西。
回复
wyx100 2010-11-17
QueueUserWorkItem API 会受别的程序影响!在某些情况下,飞信(仅以此为例,还有别的程序)在运行和没有飞信运行的 CPU 明显比较高,楼主可以自己留意一下,
回复
chenyu2202863 2010-11-17
WT_EXECUTEDEFAULT 让非IO组件的线程来处理工作项目
WT_EXECUTEINIOTHREAD 回调函数被排队以一个 I/O 工作线程来完成,

据楼主所说,应该是个耗时的过程,可以考虑加上WT_EXECUTELONGFUNCTION

回复
ningbupt 2010-11-17
不太清楚,支持一下
回复
nuistbaker 2010-11-17
UP....
回复
LiuYinChina 2010-11-16
QueueUserWorkItem API 会受别的程序影响!在某些情况下,飞信(仅以此为例,还有别的程序)在运行和没有飞信运行的 CPU 明显比较高,楼主可以自己留意一下,
具体原因不明,可能是 QueueUserWorkItem 的线程池为整个系统公有的?我没深究,不过我觉得QueueUserWorkItem的接口很好,我就用完成端口写了个仿QueueUserWorkItem接口的 dll,就没CPU受飞信等程序影响的问题了。
回复
社会栋梁 2010-11-15
up。。。。
回复
信阳毛尖 2010-11-15
不太清楚,支持一下
回复
visualwind 2010-11-10
用哪个都可以,关键是你的程序要相应设计的合理
回复
发帖
进程/线程/DLL
创建于2007-09-28

1.5w+

社区成员

VC/MFC 进程/线程/DLL
申请成为版主
帖子事件
创建了帖子
2010-11-10 10:14
社区公告
暂无公告