Last snapshot question
Moderator: Moderator Team
Last snapshot question
Hello, I want to ask, if someone knows, if last dicom toolkit snapshot has "dicomnet" module thread safe.
Thanks.
Thanks.
-
- DCMTK Developer
- Posts: 2055
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
no, nothing special for dcmnet.
the application is built on base dcmtk/ofstd libs, so, as i can remember I changed mutexes initialization to allow "recursive" mode, it is important in some applications.
think it is better to add "be recursive" as option for OFMutex but, it is okay for me as is
and i didn't solve this problem for solaris mutexes sol 8/10 threads libs are very different.
dcmtk (lib) is working very good in heavy loaded multi-thread network application, i didn't manage to find any memory leak (except socket leak i reported before) during weeks of stable running.
I think there are some issues with global objects like dictionary, if someone will try to change/use it from different threads.
diff -ru dcmtk-3.5.5_20090818/ofstd/libsrc/ofthread.cc dcmtk-3.5.5_20090818_local/ofstd/libsrc/ofthread.cc
--- dcmtk-3.5.5_20090818/ofstd/libsrc/ofthread.cc 2005-12-08 18:49:02.000000000 +0300
+++ dcmtk-3.5.5_20090818_local/ofstd/libsrc/ofthread.cc 2009-11-02 23:37:13.000000000 +0300
@@ -551,16 +551,22 @@
#ifdef WINDOWS_INTERFACE
theMutex = (void *)(CreateMutex(NULL, FALSE, NULL));
#elif defined(POSIX_INTERFACE)
+ pthread_mutexattr_t _attr;
+
+ pthread_mutexattr_init(&_attr);
+ pthread_mutexattr_settype(&_attr, PTHREAD_MUTEX_RECURSIVE);
+
pthread_mutex_t *mtx = new pthread_mutex_t;
if (mtx)
{
- if (pthread_mutex_init(mtx, NULL)) delete mtx;
+ if (pthread_mutex_init(mtx, &_attr)) delete mtx;
else theMutex = mtx;
}
#elif defined(SOLARIS_INTERFACE)
mutex_t *mtx = new mutex_t;
if (mtx)
{
+ #pragma message("TODO: we need recursive mutexes for Solaris!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!")
if (mutex_init(mtx, USYNC_THREAD, NULL)) delete mtx;
else theMutex = mtx;
}
the application is built on base dcmtk/ofstd libs, so, as i can remember I changed mutexes initialization to allow "recursive" mode, it is important in some applications.
think it is better to add "be recursive" as option for OFMutex but, it is okay for me as is
and i didn't solve this problem for solaris mutexes sol 8/10 threads libs are very different.
dcmtk (lib) is working very good in heavy loaded multi-thread network application, i didn't manage to find any memory leak (except socket leak i reported before) during weeks of stable running.
I think there are some issues with global objects like dictionary, if someone will try to change/use it from different threads.
diff -ru dcmtk-3.5.5_20090818/ofstd/libsrc/ofthread.cc dcmtk-3.5.5_20090818_local/ofstd/libsrc/ofthread.cc
--- dcmtk-3.5.5_20090818/ofstd/libsrc/ofthread.cc 2005-12-08 18:49:02.000000000 +0300
+++ dcmtk-3.5.5_20090818_local/ofstd/libsrc/ofthread.cc 2009-11-02 23:37:13.000000000 +0300
@@ -551,16 +551,22 @@
#ifdef WINDOWS_INTERFACE
theMutex = (void *)(CreateMutex(NULL, FALSE, NULL));
#elif defined(POSIX_INTERFACE)
+ pthread_mutexattr_t _attr;
+
+ pthread_mutexattr_init(&_attr);
+ pthread_mutexattr_settype(&_attr, PTHREAD_MUTEX_RECURSIVE);
+
pthread_mutex_t *mtx = new pthread_mutex_t;
if (mtx)
{
- if (pthread_mutex_init(mtx, NULL)) delete mtx;
+ if (pthread_mutex_init(mtx, &_attr)) delete mtx;
else theMutex = mtx;
}
#elif defined(SOLARIS_INTERFACE)
mutex_t *mtx = new mutex_t;
if (mtx)
{
+ #pragma message("TODO: we need recursive mutexes for Solaris!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!")
if (mutex_init(mtx, USYNC_THREAD, NULL)) delete mtx;
else theMutex = mtx;
}
just to remember one ticket for dcmnet, i am not sure if you fixed it (i really think it is a bug)
viewtopic.php?t=2159
viewtopic.php?t=2159
-
- DCMTK Developer
- Posts: 2055
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Hi,
thanks for the hints regarding the threading.
I had a look into the dulconst.cc code you posted in the other thread (it's still on our internal TODO list) and I'm 99% sure you're right. However, it would be good to test that code -- actually it was never really tested as far as i know because the role selection feature is not needed for most of the DICOM services. The dcmqrdb tool (our mini pacs) should be able to support C-GET (which needs that feature) as an option to the standard C-MOVE, however I have to look after a C-GET client SCU tool for this
Regards,
Michael
thanks for the hints regarding the threading.
I had a look into the dulconst.cc code you posted in the other thread (it's still on our internal TODO list) and I'm 99% sure you're right. However, it would be good to test that code -- actually it was never really tested as far as i know because the role selection feature is not needed for most of the DICOM services. The dcmqrdb tool (our mini pacs) should be able to support C-GET (which needs that feature) as an option to the standard C-MOVE, however I have to look after a C-GET client SCU tool for this
Regards,
Michael
Who is online
Users browsing this forum: Baidu [Spider], Bing [Bot], Google [Bot] and 0 guests