DCMTK中storeSCP例子的多线程实现

本文介绍如何使用DCMTK开发多线程DicomServer,重点在于将storescp服务独立并采用多线程处理方式以提高服务器效率。文中详细记录了具体的实现步骤及测试过程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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.

 

       首先将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论坛里面的所讲,不会出现什么问题,但我还没有在医院正式的环境中测试,具体如果不敢下定论,写的过程中,断断续续,肯定有不少错误,请见谅。

 

评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

伍心

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值