DCMTK中storeSCP例子的多线程实现

DCMTK中storeSCP例子的多线程实现

       关键词：DCMTK；DicomServer；storescp；multi-threaded ；

        最近打算用DCMTK来开发DicomServer；准备把DicomServer中的storescp服务与其它服务分开，以减轻服务器端的压力。初步想法是设计为多线程，这样客户端的storescu请求不会有延迟，以下是最近在Google上检索到的有用的信息，其中主要是参考了第一条的方法。

 

一、GOOGLE论坛中关于DCMTK多线程编程的讨论

What we did to support this in our application was we took the code from the
storescp sample and split it into 2 chunks:

1.  All code leading up to an association being received
2.  All code to handle processing an association

The main thread first runs all code form chunk #1 and then sits in a loop
calling ASC_receiveAssociation.

The rest of the code we put into a thread procedure, and whenever the main
thread receives an association, it creates a thread for that thread proc and
passes in the association pointer as the thread param.

We've been doing it this way for about 3 years now and have it out working
in dozens of sites with multiple modalities.  We've never had a problem
before, so I think this is a safe way to do it.

（原文地址：http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/e391b7974521d980）

 

二、DCMTK官方论坛关于DCMTK多线程编程的说明

Is DCMTK safe for use in multi-threaded applications?

No, in general DCMTK is not thread-safe.

Starting with release 3.4.2, experimental multi-thread support has been added to the ofstd, dcmdata and dcmimgle libraries within DCMTK, i.e. everything that handles DICOM data in memory and in files is thread-safe as long as each object instance is only handled by one thread at a time. Only a few globals (in particular the DICOM data dictionary) are safe for use by multiple threads in parallel, based on read-write locks. Multi-thread support requires that either the Posix, Solaris or Win32 thread API is available.

Other DCMTK libraries are still unsafe for use in multi-threaded applications, in particular the dcmnet library that implements the DICOM network protocol is not reentrant.

（原文地址： http://forum.dicom-cd.de/viewtopic.php?f=1&t=3249）

 

       首先将DCMTK中的storescp例子单独拿出来，删除了其中关于参数解析的部分，改为从ini配置文件中读取参数，在其它内容不变的情况下进行测试，测试用了三个病人的数据是：A、同一病人一次检查的两个序列图像，总共约400M；B、另外是一个病人的一个序列图像约300M；C、五张单独的数据；

       测试用的工具是DCMTK官网下载的可执行文件包中的storescu.exe。找三台电脑，启动storescp，storescu的具体命令如下：

       A、storescu  172.16.148,12  104  +sd dicoms1 (发送dicoms1文件下的所有DICOM文件)

       B、storescu  172.16.148,12  104  +sd dicoms2(发送dicoms2文件下的所有DICOM文件)

       C、storescu  172.16.148,12  104  98.dcm (不停的发送98.dcm文件)

       启动storescp后，首先在电脑A上运行上面的A命令，接着在电脑B上运行上面的B命令，之后再启动storescp的电脑上不停的重复运行上面的C命令。

       测试的结果是直到电脑A的请求被处理完成后，接着处理电脑B上的请求，而C请求最后完成。

       如果不修改为多线程，同一时间的请求如果过多，storescp服务将会出现卡机或等待的现象。

  

       中间停留好久没有写了，突然不知道怎么写了。

      多线程处理，主要是在两层循环上做修改，第一个是监听端口；第二个是在接受通讯之后。

      分离这两个分别建立新线程就OK了。

      经过反复测试，该方法确实如GOOGLE论坛里面的所讲，不会出现什么问题，但我还没有在医院正式的环境中测试，具体如果不敢下定论，写的过程中，断断续续，肯定有不少错误，请见谅。