希望英文好的同志站出来(翻译"专家谈多线程：并行应用详情")

[DentistryDoctor]

Intel的有关多线程编程中的同步的好文章:

http://www.intel.com/cd/ids/developer/apac/zho/dc/code/languages/183321.htm

[Juchiyufei]

up一下

[Juchiyufei]

再up一下

[碧海情天-赵亮]

呵呵，也帮着顶了
有时间的话，对照翻译软件都可以看懂的，只是我时间也不多。
看来对于电脑领域翻译来说，又是生财好机会了。此后不久应该能看到很多翻译过来的技术汇编吧

[lotuis]

翻译过来给加分吗？=。=

[bjskyhorse]

我愿意报名,但是想知道具体怎么操作,另外也想知道是否是白干的..

[celineshi]

谁能翻译过来我给他加可用分

[bjskyhorse]

先发第一部分;:附原文
Anyone designing multithreaded applications will agree: the problem of efficient synchronization is among the most difficult tasks of parallel programming. Modern operating systems provide a multitude of synchronization objects, which determine a variety of synchronization methods and schemes.

This article addresses some of the issues of parallel program synchronization and tries to clarify at least a few of them.

Below, several synchronization schemes are discussed; synchronization object behavior is described; internal system implementation of user-visible synchronization objects or functions is also explained where applicable. Hidden timings and latencies are provided; execution thread layout is shown over time, and non-obvious thread time shifts are pointed out.

Readers will also find code examples illustrating important points of the synchronization problem.

All discussions of synchronization objects and algorithms appearing in this article pertain to Microsoft Windows* implementations of such objects and algorithms.

Definitions

Several abbreviations are used throughout the article to denote the following terms:

IPI stands for Inter-Processor Interrupt, an interruption signal sent by one processor to another.

APC, Asynchronous Procedure Call, which is a Microsoft Windows* notification scheme enabling the execution of a specified procedure within the context of a specified thread.

任何一个设计多线程程序的人都会赞同以下说法:有效的同步在并行处理中是最难以
解决的问题.现代的OS提供了大量的同步对象,这使得有了多种同步的方法和策略.
这篇文章谈及并行处理同步的问题并尽量对它们中的一些予以阐明.
在以下部分,几种同步策略将予以讨论;并描述同步对象的行为;用户可见的同步兑现或功能的
内部系统实现机制也将予以解释;内部的计时和存取也予以说明;线程规划和线程时间转换也将指出;
读者将找到举例说明同步问题重点的例子.
本文中所有同步对象和算法均依照MS的WINDOWS对此类对象和算法的实现.
定义:几个缩写在本文中用来指呆以下内容.
IPI: 处理器间中断,一个处理器向另外一个发出的中断信号.
APC:异步过程调用.这是MS WINDOWS提出的说法,使在某一个进程上下文的指定过程得以执行.

[bjskyhorse]

第二部分,原文太长就不附了,,其它的有空再翻..
本文涉及用以直接控制线程的执行的唤醒和信号机制.主要用于同步资源使用的互斥机制(
使得仅有一个线程可以访问资源),则不属于本文的范畴.加载
在本文中我们也假设所有必要的资源已经在线程直接分配.任务只是唤醒线程并为他们加载合适
的任务.
就像互斥不在本文的范畴一样,这里只谈论两种机制:事件和信号量.
从OS内核的角度来看,所有涉及同步的对象(其句柄通过WaitForSingleObject / WaitForMultipleObjects
指定)都来源于定义在MS Driver Development Kit里的一个基本结构DISPATCHER_HEADER,形式如下:
typedef struct _DISPATCHER_HEADER {
union {
struct {
UCHAR Type;
UCHAR Absolute;
UCHAR Size;
union {
UCHAR Inserted;
BOOLEAN DebugActive;
};
};

volatile LONG Lock;
};
LONG SignalState;
LIST_ENTRY WaitListHead;
} DISPATCHER_HEADER;
最重要的域是Type, SignalState和WaitListHead,这是用来区分同步对象,并且可以组织一个
等待线程的列表,当SignalState变为Signaled,这些线程就会被唤醒.
所以,事件,信号量,互斥量,时钟和线程对象对于内核而言是相似的.
根据用户级的auto-reset和manual reset事件,OS内核支持两种事件,即:同步事件和notification事件.
对于用户级的事件而言,这二者很相似:给一个同步事件发信号只会唤醒一个等待线程,而把一个notification事件
设置为signaled状态则会唤醒所有等待的线程.
信号量对象的功能类似与notification事件:当一个信号量被释放,操作系统将满足尽可能多的线程(如标记尽可能多的线程
为准备执行),尽管信号量对象的创建可能是有限的.以上所说的限制是信号量和notificatio对象唯一的差别.
线程唤醒算法:
两个基本的方法用于触发线程的执行:
通过给一个同步对象发信号唤醒一个线程(原文此处有遗漏?)
把一个APC排入准备执行线程的上下文.
一个细心的读者可能认为我们忘记了SuspendThread和ResumeThread的sleep函数,但前一个函数等同于等待一个时钟,因此
同我们的分类并不矛盾.
后一个挂起/恢复的情况更加复杂,虽然仍然属于上述分类的范畴.挂起一个线程是通过等待系统内部和每个线程联系的信号量
实现的.当调用SuspendThread,系统建立一个APC对象的队列,并依次进入等待状态.ResumeThread函数释放信号量,线程的执行就恢复.
以下的伪码举例说明了OS内核的唤醒等待线程的过程.通常的,事件或者信号量驱动的算法如下:
OnSetEvent(object)
{
switch(object->type)
{
case SynchronizationEvent:

new_thread = object->WaitList[0];
processor = SelectIdleProcessor();
SendIPI(processor, new_thread);
break;

case NotificationEvent:

for(i = 0; i < object->WaitList.size; i++)
{
new_thread = object->WaitList[i];
processor = SelectIdleProcessor();
SendIPI(processor, new_thread);
}
break;

case Semaphore:

for(i = 0; i < min(object->WaitList.size, object->limit); i++)
{
new_thread = object->WaitList[i];
processor = SelectIdleProcessor();
SendIPI(processor, new_thread);
}
}
}
基于APC的线程唤醒算法,与信号驱动机制不同,由两阶段组成.
首先,APC在线程的上下文建立队列,
QueueAPC(thread, function, type)
{
If(type == kernel_mode_APC)
{
InsertKernelQueueAPC(thread, function);
}
else
{
InsertNormalQueueAPC(thread, function);
}
if(thread.state == waiting_in_user_mode_and_alertable)
{
processor = SelectIdleProcessor();
SendIPI(processor, thread);
}
}
随后,当一个新线程并激活,与该线程关联的APC函数则得以执行
OnThreadSwitch(new_thread)
{
if(new_thread->APC_queue.size != 0)
{
for(i = 0; I < new_thread->APC_queue.size; i++)
{
CallAPCFunction(new_thread->APC_queue.function[i])
}
}
}
你也许会注意到在目标线程执行的"真实"代码中被延迟了,直到队列中的函数被执行.在我们看来,
这也许会增加这种用以线程同步的机制的额外开销.另一方面,当使用这个方法通知一个运行或挂起
的线程,一个按照固定时间间隔的IO操作完成或者终止时,APC方法是最快的解决方法之一.

[celineshi]

翻译完了么？

[OnlyFor_love]

好象没有 应该还有很多 呵呵 希望楼上那位好心人再显身手

[OnlyFor_love]

我也去试试 虽然英语没过四级 但是只要看懂 然后用自己语言去组织 应该问题不是很大 呵呵

[bjskyhorse]

第3部分：
3.
让我们证明或者反驳以上关于同步方法的考量以及实际时序机制。以一个使用不同编译器（这样是
为了产生至少两种不同的同步模型）的OpenMP程序和一个手动的线程控制例子来进行研究，结果如下。
表1显示了对于例子程序的总览。由虚线划分的三个部分对应代码的APC-,event-和semaphore-triggered
部分。每个部分包含了控制三个额外线程的主线程。该程序是在具有超线程的双核Intel® Xeon® 2.4 GHz的机器上
执行的。每个线程由一个水平的色带表示。在一些色带右上角的小间隔表示了这样的事实：一个相应的线程由于一个
同步函数的调用而被停止。类似的色带下的间隔对应于有编程者插入的记号。下划线显示了同步函数的持续时间。
APC Invocation Delay
表2提供了一个基于APC线程控制的例子。主线程把3个APC线程插入每个控制的线程队列。在该表中，
APC插入的开始和最后一个线程的开始由虚线标出，标出的间隔相当于47ms，这就是APC invocation delay。
Event Triggering Delay
表3表示了基于事件的同步方法的类似信息。从第一个事件的触发到最后一个线程的激活执行区域
覆盖了33MS,这要比APC的时间快。
Semaphore Release Delay
表4例证了由一个信号量控制的三个线程的情况。标注的区域，包含了从调用ReleaseSemaphore到
最后一个线程的挂起的时间。标注的时间间隔相当于32MS。
以上的时间信息证实了我们关于同步的内部实现算法的推断。就像所预测的那样，事件和基于信号量
的方法收效相当，相比之下，两阶段的APC队列则增加了额外开销。

[bjskyhorse]

先把分给了，再贴下面的部分吧。

[OnlyFor_love]

顶一个 支持楼上

[bjskyhorse]

好歹先给些分鼓励鼓励吧，也好有点动力。

[celineshi]

先给你100分，继续努力啊，都翻完了让大家看看质量如何，好的话给你更多奖励

[bjskyhorse]

没有啊，你怎么给我的？

[leecyi]

mark

[celineshi]

已经给你了，没有收到？