class CDcmThread : public OFThread {
public:
CDcmThread();
~CDcmThread();
virtual void run();
};
void CDcmThread::run()
{
// Do processing stuff.
// Is it ok to auto delete myself like this?
delete this;
}
int main()
{
for (int i = 0; i < 10; i++) {
CDcmThread *p = new CDcmThread;
p->start();
}
return 0;
}
Is it ok to call 'delete this' inside run() to clean up the memory for the thread after its run is complete, or is there some other method to auto delete the thread when it is complete?
Also, what does the prefix OF stand for in all these methods, is it representitive of Offis?
This code is legal but dangerous. If somebody ever creates a CDcmThread instance on the stack (i.e. as local or global variable), the destructor will exhibit undefined behaviour. You should at least declare all constructors as private and define a public static factory method as the only way of creating instances of the class, always on the heap.
The other problem you have is that the network module in DCMTK is not safe for multithread applications, so your code is likely to cause hard-to-detect problems. See FAQ #18 for details.
I didn't realize that the network module is not thread safe. I wonder how disastrous the following method would be that creates a thread to handle incoming associations:
T_ASC_Network *net;
while (cond.good()) {
T_ASC_Association *assoc;
cond = ASC_receiveAssociation(net, &asoc, ASC_DEFAULTMAXPDU, NULL, NULL, OFFalse);
// A thread is created to handle each incoming association.
// The run() method of the thread follows the scu example.
CThreadHandleAssoc *p = new CThreadHandleAssoc;
p->SetNet(net);
p->SetAssoc(assoc);
p->start();
}
I ran some trials so far without any errors (that I could see) in which I sent studies from multiple clients to the test application, but if the network is not thread safe I'm sure a problem will arise at some point.
Is there anyway in which I can modify the elements that are not thread safe?
This depends. If your target platform is Win32 only, the modifications should be rather simple because all of the standard library functions are thread safe on this platform. A portable solution that also works on Posix is more complex, because the reentrant versions of many systems functions need to be used there, which implies writing configure tests for their presence. A discussion of this topic is available in this thread.
