您正在查看: 标签 的问题 下的文章

Visual Basic、NET实现双检锁(DCL)模式(二)

Visual Basic、NET实现双检锁(DCL)模式(二)

Private Sub Run1()
Dim o As Product
o = Factory1.GetInstance
System.Console.WriteLine("Total number of objects created: {0} ", o.GetCount)
End Sub

Private Sub btnCreate1_Click(…) Handles btnCreate1.Click
Dim t(9) As Thread
Dim count As Integer

For count = 0 To 9
t(count) = New Thread(AddressOf Run1)
t(count).Start()
Next
End Sub

代码清单4、客户端的源代码

另外在Factory1的GetInstance()方法的第一行加入:

Thread.Sleep(10)

的语句,相当于模拟一个冗长的产品创建过程,使得最早进入的线程等待后面的线程,从而凸显现多线程的问题。

上面的客户端代码使用了10个线程同时调用工厂方法,然后调用产品的计数方法,打印出产品类的实例总数。如果读者运行一下这些代码的话,就会发现,工厂方法会创建出远多于1个的产品实例,在笔者运行这段代码时,系统整整产生了9个产品实例。

因此Factory1作为循环使用产品实例的工厂在多线程环境中是失败的。使用类似于代码清单4的客户端进行试验的话,可以看出系统自始至终仅仅创建了一个产品实例。

一个线程安全的版本

  为了克服没有线程安全的缺点,下面给出一个线程安全的GetInstance()方法:

<MethodImpl(MethodImplOptions.Synchronized)>_
Public Shared Function GetInstance() As Product
 Thread.Sleep(10)

 If (instance Is Nothing) Then
  instance = New Product()
 End If

 Return instance
End Function

代码清单5、这是一个线程安全的正确答案

  显然,由于整个静态工厂方法都是同步化的,因此,不会有两个线程同时进入这个方法。因此,当线程A和B作为第一批调用者同时或几乎同时调用此方法时:

  早到一点的线程A会率先进入此方法,同时线程B会在方法外部等待;

  1. 对线程A来说,instance变量的值是Nothing,因此instance = New Product()语句会被执行。

  2. 线程A结束对方法的执行,instance变量的值不再是Nothing。

  3. 线程B进入此方法,instance变量的值不再是Nothing,因此instance = New Product()语句不会被执行。线程B取到的是instance变量所含有的引用,也就是对线程A所创立的Product实例的引用。

  显然,线程A和B持有同一个Product实例,这是正确的。

  读到这里,读者可以参看本文后面的问答题1、2和3。

  优化的线程安全版本---DCL模式

  再进入本节的讨论之前,首先复习一下Mutex类。Mutex可以提供排他性的访问限制,通过只允许一个线程访问这个资源,从而达到同步化的目的。需要取得访问许可的线程,必须调用WaitOne()方法。如果当前没有其他线程访问,则线程可以取得访问许可;不然就会在这个语句处等待。访问结束的时候,可以调用ReleaseMutex()方法,释放访问许可。

  仔细审察上面的代码清单5就会发现,同步化实际上只在instance变量第一次被赋值之前才有用。在instance变量有了值以后,同步化实际上变成了一个不必要的瓶颈。如果能有一个方法去掉这个小小的额外开销,不是更加完美了吗?因此,就有了下面这个设计巧妙的双检锁(Double-Check Locking)。

Public Class Factory3
Private Shared instance As Product
Private Shared m As Mutex = New Mutex()

Private Sub New()
 System.Console.WriteLine("Factory object is created.")
End Sub

Public Shared Function GetInstance() As Product
 Thread.Sleep(10)
 If (instance Is Nothing) Then '位置1
  '位置2
  m.WaitOne()
  '位置3
  If (instance Is Nothing) Then '位置4
   instance = New Product()
  End If
  m.ReleaseMutex()
 End If

 Return instance
 End Function
End Class

代码清单6、使用DCL模式的懒汉式工厂类

  对于初次接触DCL模式的读者来说,这个技巧的思路并不明显易懂,因此本文在这里给出一个详尽的解释。同样,这里假设线程A和B作为第一批调用者同时或几乎同时调用静态工厂方法。

  1. 因为线程A和B是第一批调用者,因此当它们进入此静态工厂方法时,instance变量是Nothing。因此线程A和B会同时或几乎同时到达位置1。

  2. 假设线程A会首先到达位置2,并进入m.WaitOne()并到达位置3。这时,由于m.WaitOne()的同步化限制,线程B无法到达位置3,而只能在位置2等候。

  3. 线程A执行instance = New Product()语句,使得instance变量得到一个值,即对一个Product对象的引用。此时,线程B只能继续在位置2等候。

  4. 线程A退出m.WaitOne(),返回instance对象,退出静态工厂方法。

  5. 线程B进入m.WaitOne()块,达到位置3,进而达到位置4。由于instance变量已经不是Nothing了,因此线程B退出 m.WaitOne(),返回instance所引用的Product对象(也就是线程A所创建的Product对象),退出静态工厂方法。

创建有个性的对话框之MFC篇(二)

创建有个性的对话框之mfc篇(二)

图.4 就是这段代码的效果,在这里我们不分“青红皂白”,向所有的控件返回我们自己的画刷,看起来不错,Edit控件的文字颜色也改了,但是好像多行Edit控件有了麻烦,看来需要对多行Edit控件特殊对待。


图.4 重载OnCtlColor之后的效果
对于多行Edit控件特殊处理,如下所示,上面的问题解决了:
HBRUSH CCustDlgDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
if(pWnd->GetDlgCtrlID() == IDC_EDIT_MULTI_LINE) //IDC_EDIT_MULTI_LINE是多行Edir控件的ID
{
pDC->SetTextColor(m_clrText);
return hbr;
}
else
{
pDC->SetTextColor(m_clrText);
pDC->SetBkMode(TRANSPARENT);
return (HBRUSH)m_brBkgnd;
}
}
上面的代码解决了IDC_EDIT_MULTI_LINE的问题,但是对每个多行Edit控件都要判断ID,下面的方法可以一劳永逸地解决多行编辑控件的问题:
HBRUSH CCustDlgDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
TCHAR szClassName[64];
::GetClassName(pWnd->GetSafeHwnd(),szClassName,64);
if(lstrcmpi(szClassName,_T("Edit")) == 0) //是Edit 控件
{
DWORD dwStyle = pWnd->GetStyle();
if((dwStyle & ES_MULTILINE) == ES_MULTILINE) //多行edit控件
{
pDC->SetTextColor(m_clrText);
return hbr;
}
else
{
pDC->SetTextColor(m_clrText);
pDC->SetBkMode(TRANSPARENT);
return (HBRUSH)m_brBkgnd;
}
}
else //不是编辑控件
{
pDC->SetTextColor(m_clrText);
pDC->SetBkMode(TRANSPARENT);
return (HBRUSH)m_brBkgnd;
}
}
下面我们针对每个控件设置特殊的颜色,区分控件可以通过控件的ID,修改控件背景也很简单,直接返回相应的画刷就可以了,下面就是颜色设置的完整代码:
HBRUSH CCustDlgDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
TCHAR szClassName[64];
::GetClassName(pWnd->GetSafeHwnd(),szClassName,64);
if(lstrcmpi(szClassName,_T("Edit")) == 0) //是Edit 控件
{
DWORD dwStyle = pWnd->GetStyle();
if((dwStyle & ES_MULTILINE) == ES_MULTILINE) //多行edit控件
{
pDC->SetTextColor(m_clrText);
return hbr;
}
else
{
pDC->SetTextColor(m_clrText);
pDC->SetBkMode(TRANSPARENT);
return (HBRUSH)m_brBkgnd;
}
}
else //不是编辑控件

用C语言编写Windows服务程序的五个步骤

c语言编写Windows服务程序的五个步骤

  Windows服务被设计用于需要在后台运行的应用程序以及实现没有用户交互的任务。为了学习这种控制台应用程序的基础知识,C(不是C++)是最佳选择。本文将建立并实现一个简单的服务程序,其功能是查询系统中可用物理内存数量,然后将结果写入一个文本文件。最后,你可以用所学知识编写自己的 Windows 服务。

  当初我写第一个 NT 服务时,我到 MSDN 上找例子。在那里我找到了一篇 Nigel Thompson 写的文章:“Creating a Simple win32 Service in C++”,这篇文章附带一个 C++ 例子。虽然这篇文章很好地解释了服务的开发过程,但是,我仍然感觉缺少我需要的重要信息。我想理解通过什么框架,调用什么函数,以及何时调用,但 C++ 在这方面没有让我轻松多少。面向对象的方法固然方便,但由于用类对底层 win32 函数调用进行了封装,它不利于学习服务程序的基本知识。这就是为什么我觉得 C 更加适合于编写初级服务程序或者实现简单后台任务的服务。在你对服务程序有了充分透彻的理解之后,用 C++ 编写才能游刃有余。当我离开原来的工作岗位,不得不向另一个人转移我的知识的时候,利用我用 C 所写的例子就非常容易解释 NT 服务之所以然。

  服务是一个运行在后台并实现勿需用户交互的任务的控制台程序。Windows NT/2000/XP 操作系统提供为服务程序提供专门的支持。人们可以用服务控制面板来配置安装好的服务程序,也就是 Windows 2000/XP 控制面板|管理工具中的“服务”(或在“开始”|“运行”对话框中输入 services.msc /s——译者注)。可以将服务配置成操作系统启动时自动启动,这样你就不必每次再重启系统后还要手动启动服务。

  本文将首先解释如何创建一个定期查询可用物理内存并将结果写入某个文本文件的服务。然后指导你完成生成,安装和实现服务的整个过程。

  第一步:主函数和全局定义

  首先,包含所需的头文件。例子要调用 Win32 函数(windows.h)和磁盘文件写入(stdio.h):

以下是引用片段:
   #include
   #include

  接着,定义两个常量:

以下是引用片段:
   #define SLEEP_TIME 5000
   #define LOGFILE "C:\\MyServices\\memstatus.txt"

  SLEEP_TIME 指定两次连续查询可用内存之间的毫秒间隔。在第二步中编写服务工作循环的时候要使用该常量。

  LOGFILE 定义日志文件的路径,你将会用 WriteToLog 函数将内存查询的结果输出到该文件,WriteToLog 函数定义如下:

以下是引用片段:
   int WriteToLog(char* str)
   {
   FILE* log;
   log = fopen(LOGFILE, "a+");
   if (log == NULL)
   return -1;
   fprintf(log, "%s\n", str);
   fclose(log);
   return 0;
   }

  声明几个全局变量,以便在程序的多个函数之间共享它们值。此外,做一个函数的前向定义:

以下是引用片段:
   SERVICE_STATUS ServiceStatus;
   SERVICE_STATUS_HANDLE hStatus;
   void ServiceMain(int argc, char** argv);
   void ControlHandler(DWORD request);
   int InitService();

  现在,准备工作已经就绪,你可以开始编码了。服务程序控制台程序的一个子集。因此,开始你可以定义一个 main 函数,它是程序的入口点。对于服务程序来说,main 的代码令人惊讶地简短,因为它只创建分派表并启动控制分派机。

以下是引用片段:
   void main()
   {
   SERVICE_TABLE_ENTRY ServiceTable[2];
   ServiceTable[0].lpServiceName = "MemoryStatus";
   ServiceTable[0].lpServiceProc = (LPSERVICE_MAIN_FUNCTION)ServiceMain;
   ServiceTable[1].lpServiceName = NULL;
   ServiceTable[1].lpServiceProc = NULL;
   // 启动服务的控制分派机线程
   StartServiceCtrlDispatcher(ServiceTable);
   }

  一个程序可能包含若干个服务。每一个服务都必须列于专门的分派表中(为此该程序定义了一个 ServiceTable 结构数组)。这个表中的每一项都要在 SERVICE_TABLE_ENTRY 结构之中。它有两个域:

  lpServiceName: 指向表示服务名称字符串的指针;当定义了多个服务时,那么这个域必须指定;

  lpServiceProc: 指向服务主函数的指针(服务入口点);

  分派表的最后一项必须是服务名和服务主函数域的 NULL 指针,文本例子程序中只宿主一个服务,所以服务名的定义是可选的。

  服务控制管理器(SCM:Services Control Manager)是一个管理系统所有服务的进程。当 SCM 启动某个服务时,它等待某个进程的主线程来调用 StartServiceCtrlDispatcher 函数。将分派表传递给 StartServiceCtrlDispatcher。这将把调用进程的主线程转换为控制分派器。该分派器启动一个新线程,该线程运行分派表中每个服务的 ServiceMain 函数(本文例子中只有一个服务)分派器还监视程序中所有服务的执行情况。然后分派器将控制请求从 SCM 传给服务。

  注意:如果 StartServiceCtrlDispatcher 函数30秒没有被调用,便会报错,为了避免这种情况,我们必须在 ServiceMain 函数中(参见本文例子)或在非主函数的单独线程中初始化服务分派表。本文所描述的服务不需要防范这样的情况。

  分派表中所有的服务执行完之后(例如,用户通过“服务”控制面板程序停止它们),或者发生错误时。StartServiceCtrlDispatcher 调用返回。然后主进程终止。

  第二步:ServiceMain 函数

  Listing 1 展示了 ServiceMain 的代码。该函数是服务的入口点。它运行在一个单独的线程当中,这个线程是由控制分派器创建的。ServiceMain 应该尽可能早早为服务注册控制处理器。这要通过调用 RegisterServiceCtrlHadler 函数来实现。你要将两个参数传递给此函数:服务名和指向 ControlHandlerfunction 的指针。

  它指示控制分派器调用 ControlHandler 函数处理 SCM 控制请求。注册完控制处理器之后,获得状态句柄(hStatus)。通过调用 SetServiceStatus 函数,用 hStatus 向 SCM 报告服务的状态。

  Listing 1 展示了如何指定服务特征和其当前状态来初始化 ServiceStatus 结构,ServiceStatus 结构的每个域都有其用途:

  dwServiceType:指示服务类型,创建 Win32 服务。赋值 SERVICE_WIN32;

  dwCurrentState:指定服务的当前状态。因为服务的初始化在这里没有完成,所以这里的状态为 SERVICE_START_PENDING;

  dwControlsAccepted:这个域通知 SCM 服务接受哪个域。本文例子是允许 STOP 和 SHUTDOWN 请求。处理控制请求将在第三步讨论;

  dwWin32ExitCode 和 dwServiceSpecificExitCode:这两个域在你终止服务并报告退出细节时很有用。初始化服务时并不退出,因此,它们的值为 0;

  dwCheckPoint 和 dwWaitHint:这两个域表示初始化某个服务进程时要30秒以上。本文例子服务的初始化过程很短,所以这两个域的值都为 0。

  调用 SetServiceStatus 函数向 SCM 报告服务的状态时。要提供 hStatus 句柄和 ServiceStatus 结构。注意 ServiceStatus 一个全局变量,所以你可以跨多个函数使用它。ServiceMain 函数中,你给结构的几个域赋值,它们在服务运行的整个过程中都保持不变,比如:dwServiceType。
在报告了服务状态之后,你可以调用 InitService 函数来完成初始化。这个函数只是添加一个说明性字符串到日志文件。如下面代码所示:

以下是引用片段:
   // 服务初始化
   int InitService()
   {
   int result;
   result = WriteToLog("Monitoring started.");
   return(result);
   }

  在 ServiceMain 中,检查 InitService 函数的返回值。如果初始化有错(因为有可能写日志文件失败),则将服务状态置为终止并退出 ServiceMain:

以下是引用片段:
   error = InitService();
   if (error)
   {
   // 初始化失败,终止服务
   ServiceStatus.dwCurrentState = SERVICE_STOPPED;
   ServiceStatus.dwWin32ExitCode = -1;
   SetServiceStatus(hStatus, &ServiceStatus);
   // 退出 ServiceMain
   return;
   }

  如果初始化成功,则向 SCM 报告状态:

以下是引用片段:
   // 向 SCM 报告运行状态
   ServiceStatus.dwCurrentState = SERVICE_RUNNING;
   SetServiceStatus (hStatus, &ServiceStatus);

  接着,启动工作循环。每五秒钟查询一个可用物理内存并将结果写入日志文件。

  如 Listing 1 所示,循环一直到服务的状态为 SERVICE_RUNNING 或日志文件写入出错为止。状态可能在 ControlHandler 函数响应 SCM 控制请求时修改。

  第三步:处理控制请求

  在第二步中,你用 ServiceMain 函数注册了控制处理器函数。控制处理器与处理各种 Windows 消息的窗口回调函数非常类似。它检查 SCM 发送了什么请求并采取相应行动。

  每次你调用 SetServiceStatus 函数的时候,必须指定服务接收 STOP 和 SHUTDOWN 请求。Listing 2 示范了如何在 ControlHandler 函数中处理它们。

  STOP 请求是 SCM 终止服务的时候发送的。例如,如果用户在“服务”控制面板中手动终止服务。SHUTDOWN 请求是关闭机器时,由 SCM 发送给所有运行中服务的请求。两种情况的处理方式相同:

  写日志文件,监视停止;

  向 SCM 报告 SERVICE_STOPPED 状态;

  由于 ServiceStatus 结构对于整个程序而言为全局量,ServiceStatus 中的工作循环在当前状态改变或服务终止后停止。其它的控制请求如:PAUSE 和 CONTINUE 在本文的例子没有处理。

  控制处理器函数必须报告服务状态,即便 SCM 每次发送控制请求的时候状态保持相同。因此,不管响应什么请求,都要调用 SetServiceStatus。

  第四步:安装和配置服务

  程序编好了,将之编译成 exe 文件。本文例子创建的文件叫 MemoryStatus.exe,将它拷贝到 C:\MyServices 文件夹。为了在机器上安装这个服务,需要用 SC.EXE 可执行文件,它是 Win32 Platform SDK 中附带的一个工具。(译者注:Visaul Studio .NET 2003 IDE 环境中也有这个工具,具体存放位置在:C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\Bin\winnt)。使用这个实用工具可以安装和移除服务。其它控制操作将通过服务控制面板来完成。以下是用命令行安装 MemoryStatus 服务的方法:

以下是引用片段:
   sc create MemoryStatus binpath= c:\MyServices\MemoryStatus.exe

  发出此创建命令。指定服务名和二进制文件的路径(注意 binpath= 和路径之间的那个空格)。安装成功后,便可以用服务控制面板来控制这个服务。用控制面板的工具栏启动和终止这个服务。

  MemoryStatus 的启动类型是手动,也就是说根据需要来启动这个服务。右键单击该服务,然后选择上下文菜单中的“属性”菜单项,此时显示该服务的属性窗口。在这里可以修改启动类型以及其它设置。你还可以从“常规”标签中启动/停止服务。以下是从系统中移除服务的方法:

以下是引用片段:
   sc delete MemoryStatus

  指定 “delete” 选项和服务名。此服务将被标记为删除,下次西通重启后,该服务将被完全移除。

  第五步:测试服务

  从服务控制面板启动 MemoryStatus 服务。如果初始化不出错,表示启动成功。过一会儿将服务停止。检查一下 C:\MyServices 文件夹中 memstatus.txt 文件的服务输出。在我的机器上输出是这样的:

  Monitoring started.

  273469440

  273379328

  273133568

  273084416

  Monitoring stopped.

  为了测试 MemoryStatus 服务在出错情况下的行为,可以将 memstatus.txt 文件设置成只读。这样一来,服务应该无法启动。

  去掉只读属性,启动服务,在将文件设成只读。服务将停止执行,因为此时日志文件写入失败。如果你更新服务控制面板的内容,会发现服务状态是已经停止

用C设计 用C++编码

用C设计 用C++编码
来源:csdn

【引自孟岩的博客】《不得不看的两次从C++回归C的高手评论C++》中先是提了一下所谓C++带来的思想包袱(文言文曰“心智包袱”)问题,然后重重地引用了Linus的话:“关键是设计”,其实他是在暗示:好的设计C同样能做出来,不劳C++大驾;而C++一旦出面,就要让人背上额外的思想包袱。

我明确地表个态,在系统级程序设计中,事实就是这样的。

别小看这个思想包袱,大部分,甚至绝大部分C++程序员过不了这一关。相反,做系统级开发,C是几乎没有思想包袱的语言,说白了就是刺刀见红,你想要啥你就去写啥,它给你的不多也不少,没什么干不了,也没什么非让你背着不可。

我早在N年前就发现自己写程序速度慢,我当时对STL远比周围人熟悉,照例说长缨在手,应该效率很高才对。结果发现不是,写程序的时候特别没自信,总在想:“这样固然是可以work了,但恐怕有更好的方案吧!会是什么呢?加个模板参数试试?要么抽象出一个基类?做一个bridge模式?那么Ownership的问题怎么解决?谁来负责回收内存呢?移植一个boost::shared_ptr过来吧!可多线程情况下会不会拖慢速度呢?应该不会,可是会碰到循环引用的情况。要么在中间搞一个weak_ptr把循环链断开?哎呀!不行不行,太复杂,别人也理解不了。还是先这样吧!能work就行。”就这样,兜了一个圈子回来。有的时候,这个圈子不是纯柏拉图式的,我会真的实现不少“优化”设计来比对,那个时间啊!花花的就耗在里面了。有的时候确实会获得一些改进,但是多数时候是得不偿失,旁边那些在我看来连C都只是一知半解的家伙采用“CtrlC-CtrlV-Modify-Debug”大法,早就冲到我前头去了。这就是“心智包袱”的威力。

最近几年没怎么用C++写程序,业余时间倒是别的语言用了好几种。大概是体会到这些语言的某些好处之后,对C++就能看得更客观一些了,也琢磨了一下,如果自己有朝一日重新跑回去写C/C++,我会怎么干?毕竟现在C++程序员全球紧缺,工资越来越高,这个问题还是有其现实意义的。正好跟chensh 聊了一会儿,两个人的看法一致,就是采取“ C + Concreate Class + STL”的风格。说白了就是用C来设计,用C++来编码。

这里面的道理是这样的,反正现在C和C++都是来做系统级开发,那些华丽的抽象机制用不上,思考解决方案的时候,就以C的方式。注意,C也是可以做基于对象甚至面向对象甚至组件级别的设计的,但是在C的层面上思考问题,设计能够更精益(lean,现在这是个时髦词),更轻便,更直接。当你构思的设计方案出来以后,如果其中有些部分,恰好是C++现成做好了,而且使用C++又可以提高开发效率,也没什么明显的副作用,那么就用C++来做相应的部分。比如,COM原来设计的时候就是在C基础上做的,设计的时候发现实际上跟C++实现多态的的vptr + vtable是吻合的,所以后来就主要用C++来做COM开发。事实上,为了适应COM开发的需要,微软直接改了C++编译器。很显然,微软是首先构思好的设计,然后让C++去适应这个设计。而后来很多C++程序员,是让设计去适应C++的那些语言机制,在系统开发中,这个叫做本末倒置。当然这样的事情在应用级别上就不是那么离谱。

实际上回头看看C++早期的历史,最早C++就是把一些C中常用的patterns内置到语言里而出现的,早期它曾经有效地提高了开发效率。今天应该回头去寻找这种精神。

我支持STL是基于同样的理由。很多时候,你从C出发得到的设计,也无非就是STL已经实现得很好的东西。在这个时候,当然可以用STL。尤其是那些算法,针对C array也是适用的,用accumulate求和,用transform映射,用adjacent_find寻找相等的毗邻项,用lower_bound和equal_range做二分查找等等,这不是比手写要爽多了吗?当然,使用STL,还是必须熟悉其背后的机理,没有这个底子,还是规规矩矩用C算了。

索引访问方法接口定义索引锁的考量

51.4. 索引锁的考量

索引访问方法必须支持多个进程对索引的并发更新。在索引扫描期间, PostgreSQL 核心系统在索引上抓取 AccessShareLock, 并且在更新索引期间(包括 VACUUM)也会抓取RowExclusiveLock 。因为这些锁类型不会冲突,所以访问方法有责任处理任何它自己需要的更细致 的锁需求。在全部索引上的排他锁将只是在索引的创建、删除或REINDEX 的时候被使用。

创建一个支持并发更新的索引类型通常要求对所需的行为进行广泛并且细致的分析。 对于b-tree 和 Hash索引类型,你可以读取在src/backend/access/ nbtree/README和src/backend/access/hash/README里面的设计 决策。

除了索引自己内部的一致性要求之外,并发更新创建了一些有关父表(堆)和索引之 间的一致性问题。因为 PostgreSQL是把堆的访问和 更新与索引的访问和更新分开的,所以存在一些窗口,在这些窗口里索引可能会与堆 不一致。我们用下面的规则处理这样的问题:

  • 在制作一行的索引记录之前,先做堆记录。(因此并发的索引扫描很可能看不 到堆记录。这么做应该是 OK 的,因为索引读者对未授权的行不感兴趣。不过 需要看看节49.5Section 51.5。)

  • 如果一条堆记录要被删除(通过“清空”命令),所有其索引记录都必须首先删除。

  • 一次索引扫描必须在保存有amgettuple最后返回的索引页面上维护一个销,而ambulkdelete不能删除其它后端用销固定的索引页面里面的记录。下面会解释需要这条规则的原因。

没有第三条规则,如果一个索引是并发的,那么一个索引读者是可能在一条索引记 录被 VACUUM删除之前看到它的,然后在VACUUM删除它之 后找到其对应的堆记录。如果读者到达该项时,该项编号仍然没有使用,那么这种 情况不会导致严重的问题,因为空的项槽位会被 heap_fetch()忽略。 但是如果第三个后端已经为其它什么东西复用了这个项槽位又如何?如果使用MvcC兼容的快照,那么就不会有问题,因为新占据的槽位当然是太新了,因而无法通过 快照测试。但是,对于非 MvcC 兼容的快照(比如 SnapshotNow),那 么就有可能接受并返回一个实际上并不匹配扫描键字的行。可以通过要求扫描键字 在所有场合下都重新检查的方法来避免这种情况,但是这种方法开销太大了。取而 代之的是,通过在索引页面上使用一个销,当作一个代理,告诉系统说,读者可能 还在对应堆记录的索引记录上空"飞行"。在这样的销上面进行 ambulkdelete块确保 VACUUM 无法在读者完成读取之前删除堆记录. 这种解法增加了一点点运行时开销,而只是在非常罕见的实际有冲突的情况下才导致阻塞开销。

这个解决方法要求索引扫描必须是"同步的":必须在扫描完对应的索引记录之后马上 抓取每个堆记录。这样的方案开销比较大,原因有若干个。而"异步的"扫描,可以先 从索引里收集很多 TID ,然后再稍后的某时访问堆行,这样就会烧很多索引锁的开 销,以及可以允许更有效的堆访问模式。但是按照上面的分析,在非 MVCC 兼容单块 着上必须使用同步方法,而对使用 MVCC 快照的查询,使用异步扫描应该是可以实现的。

在amgetmulti索引扫描里,访问方法不需要保证在任何返回的行上 保持一个销。毕竟,除了给最后一个行加销之外,也没法给其它的加。 因此,只能在MVCC兼容的快照里使用这样的扫描。