DICOM：fo-dicom之C-STORE再分析‘解决System.ObjectDisposedException异常’

背景：

在我的【DICOM系列专栏】中希望尽量涵盖关于DICOM协议的所有知识，但是在具体到某个知识点的讲解时往往会穿插使用DICOM协议的多种开源实现，例如基于C++的dcmtk、基于C#的fo-dicom、甚至是最近更加入的基于Java的dcm4che。之所以穿插介绍多种开源实现，简单概括其用意有三，第一，开源实现各有利弊，为了方便大家自己动手练习，第一时间会选择对该知识点实现最简单的开源库；第二，开源库的实现过程中应用到了许多编码和工程的设计理念，直接查看源码有时候会看起来与DICOM协议脱离甚远，因此在着重介绍DICOM协议具体内容时会使用实现直接、最符合DICOM协议原状的开源库；第三，开源库最终是为了实际应用，某些时候为了项目效率和性能考虑，会使用实现技术最新的开源库。

题记：

对于开源库的实现技术，之前部分博文也进行过简单分析。例如DICOM医学图像处理：Dcmtk与fo-dicom保存文件的不同设计模式之“同步VS异步”+“单线程VS多线程”。fo-dicom与mDCM库同属于DICOM的C#开源实现，正如上述博文所述，fo-dicom中使用了大量的.NET异步编程模式技术对mDCM进行重构。之前博文只对fo-dicom中I/O操作（文件读取和保存）的异步实现进行了介绍，近期在项目具体部署过程中遇到了一个奇葩问题，最终排查发现是由于之前对fo-dicom库中网络部分的异步实现理解有偏差所致。因此此次博文通过分析fo-dicom中的C-STORE服务实现再次分析fo-dicom中使用的.NET异步编程模型。

fo-dicom C-STORE服务弹出System.ObjectDisposedException异常

之前在DICOM医学图像处理：fo-dicom网络传输之 C-Echo and C-Store博文中对于C-STORE SCU的介绍直接使用的是fo-dicom在github上的官方示例，其代码很简单，如下所示：

var client = new DicomClient();
client.AddRequest(new DicomCStoreRequest(@"test.dcm"));
client.Send("127.0.0.1", 12345, false, "SCU", "ANY-SCP");

单个文件的发送请求与DICOM标准第7部分中对于C-STORE的具体描述严格一致，fo-dicom在具体实现时，首先利用AddRequest将数据体添加到client内部的数据链表中，然后通过Send函数利用TCP协议发送到指定的PACS服务端。
但是在C-STORE SCU服务的具体应用场景中，尤其是放射科，往往需要传送的是一个Series序列中的多张图像，也就是说需要构造多个DicomCStoreRequest对象通过AddRequest添加到DicomClient内部数据链表中，然后通过Send()进行发送。因此直接来看的话，对于序列的发送，实现代码应该是：

for(int i=0;i<series.number;++i)
{
    DicomCStoreRequest req = new DicomCStoreRequest(series.files[i]);
    client.AddRequest(req);
    client.Send("127.0.0.1",12345,false,"SCU","ANY-SCP");
}

但是在具体部署Release发布版时，会偶然随机性的出现崩溃的现象，且概率较高，传输320层图像序列大概每间隔两到三次出现一次崩溃。调试时刻发现断点停在fo-dicom库的核心代码DicomService中，如下图所示：