Threading in digiKam
Locked
 
|
Hi Everyone!
The GSoC community bonding period has started. My exams just got over and I'm trying to get familiar with digiKam's workings. Now, a major concern is that libface's methods should be thread-safe to be usable in digKam. pthreads are POSIX-only. So, I'd like to know what sort of threading digiKam uses. I can browse the code myself, but it'd be faster if someone points me to some relevant source files which make use of threading, just so that I can learn quicker. Thanks in advance, -- Aditya Bhatt Blog : http://adityabhatt.wordpress.com Bitbucket: http://bitbucket.org/aditya_bhatt Face Recognition Library : http://libface.sourceforge.net _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
> Hi Everyone! > > The GSoC community bonding period has started. My exams just got over and > I'm trying to get familiar with digiKam's workings. > Now, a major concern is that libface's methods should be thread-safe to be > usable in digKam. > > pthreads are POSIX-only. So, I'd like to know what sort of threading > digiKam uses. I can browse the code myself, but it'd be faster if someone > points me to some relevant source files which make use of threading, just > so that I can learn quicker. Of course, we use Qt ;-) If you now feel the need, reconsider to build upon Qt Core at least. It's about as cross-platform as it gets nowadays. Also think about if you want to have thread-safety or reentrancy: Reentrancy is often easily achieved. Store your data in a C++ object and do not use any global-static data structures. Now a single object can only be used from a single thread, but this is usually absolutely sufficient. If usage of global-static data is needed for optimization purposes, it is critical to make this thread-safe, to mutex-protect them. See above for my Qt hint. Thread-safe means that the same single object can be access from multiple threads. This requires strict mutex protection for all methods, but is usually unnecessary for objects like images. Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
There is no threading in libface anyways so the only thing left is to implement thread safety with simple mutex locks.
On 1 May 2010, at 14:14, Marcel Wiesweg wrote: > >> Hi Everyone! >> >> The GSoC community bonding period has started. My exams just got over and >> I'm trying to get familiar with digiKam's workings. >> Now, a major concern is that libface's methods should be thread-safe to be >> usable in digKam. >> >> pthreads are POSIX-only. So, I'd like to know what sort of threading >> digiKam uses. I can browse the code myself, but it'd be faster if someone >> points me to some relevant source files which make use of threading, just >> so that I can learn quicker. > > Of course, we use Qt ;-) > If you now feel the need, reconsider to build upon Qt Core at least. It's > about as cross-platform as it gets nowadays. > > Also think about if you want to have thread-safety or reentrancy: > > Reentrancy is often easily achieved. Store your data in a C++ object and do > not use any global-static data structures. Now a single object can only be > used from a single thread, but this is usually absolutely sufficient. > If usage of global-static data is needed for optimization purposes, it is > critical to make this thread-safe, to mutex-protect them. See above for my Qt > hint. > > Thread-safe means that the same single object can be access from multiple > threads. This requires strict mutex protection for all methods, but is usually > unnecessary for objects like images. > > Marcel > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel If we knew what we were doing, it wouldn't be called research, would it? -- Albert Einstein _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
> There is no threading in libface anyways so the only thing left is to > implement thread safety with simple mutex locks. Do you use any global-static data structures? Or does OpenCV use them? Otherwise all will be fine already. As I wrote before, we'll need reentrant code. If there are singleton classes, you'll need to mutex-protect them. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Hi Marcel,
Yeah there are some global structures i.e. like the face recognition config. I have asked if Aditya wanted to implement simple mutex lock in libface using couple of boolean variables in the main class. Also described some use cases, hopefully this should be enough to get him going and finish it quickly. I am also assuming, please correct me if I am wrong, that a single instance of LibFace will be created and then shared between threads. Which means that we will lock appropriate methods only from being run in separate threads at the same time. E.g. things like if one thread updating the face recognition config everything else will have to wait. But 2 face recognition methods in separate threads can be run at the same time, as they are only reading from the config. I am also putting finishing touches on getting and loading config from/into LibFace as strings and storing them in database in this case. Otherwise you can also let libface store them in separate XML file in some directory. But thats besides the point. Alex On 2 May 2010, at 14:30, Marcel Wiesweg wrote: > >> There is no threading in libface anyways so the only thing left is to >> implement thread safety with simple mutex locks. > > Do you use any global-static data structures? Or does OpenCV use them? > Otherwise all will be fine already. > As I wrote before, we'll need reentrant code. If there are singleton classes, > you'll need to mutex-protect them. > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel If we knew what we were doing, it wouldn't be called research, would it? -- Albert Einstein _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Marcel Wiesweg
2010/5/1 Marcel Wiesweg <[hidden email]>:
> >> Hi Everyone! >> >> The GSoC community bonding period has started. My exams just got over and >> I'm trying to get familiar with digiKam's workings. >> Now, a major concern is that libface's methods should be thread-safe to be >> usable in digKam. >> >> pthreads are POSIX-only. So, I'd like to know what sort of threading >> digiKam uses. I can browse the code myself, but it'd be faster if someone >> points me to some relevant source files which make use of threading, just >> so that I can learn quicker. > > Of course, we use Qt ;-) > If you now feel the need, reconsider to build upon Qt Core at least. It's > about as cross-platform as it gets nowadays. To second Marcel, we use QThread in digiKam core, as with this class dedecated to run image editor tool code in a separated thread : main classes : http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/threads/dynamicthread.h?revision=1118746&view=markup http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/filters/dimgthreadedfilter.h?revision=1115803&view=markup And there a simple filtre to adjust brightness, contrast and gamma... http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/filters/bcg/bcgfilter.h?revision=1099598&view=markup Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Hi Gilles, Alex, and Marcel,
Thanks for the files gilles :) As Alex said, we might use some simple variables for locking critical sections. We do use global stuff as he pointed out. We don't want to pull in a Qt dependency for libface. PS: I just got my modem to work and am now building digiKam and dependencies. On Mon, May 3, 2010 at 11:40 AM, Gilles Caulier <[hidden email]> wrote: 2010/5/1 Marcel Wiesweg <[hidden email]>: -- Aditya Bhatt Blog : http://adityabhatt.wordpress.com Bitbucket: http://bitbucket.org/aditya_bhatt Face Recognition Library : http://libface.sourceforge.net _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by alexjironkin
> > I am also assuming, please correct me if I am wrong, that a single instance > of LibFace will be created and then shared between threads. Which means > that we will lock appropriate methods only from being run in separate > threads at the same time. E.g. things like if one thread updating the face > recognition config everything else will have to wait. But 2 face > recognition methods in separate threads can be run at the same time, as > they are only reading from the config. Another way to go is if you just document thread-unsafety in the API docs. It's ok, we just need to know then and use a mutex. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |