[gt-users] gt python with (multi)processing

Sascha Steinbiss steinbiss at zbh.uni-hamburg.de
Wed Jan 20 16:36:32 CET 2010


On 01/20/2010 02:03 PM, Gordon Gremme wrote:
>> Any ideas or opinions? Could making the C library thread-safe be
>> worth the effort (and how much would that be)? And does anyone have
>> experience with that?
> I started making libgenometools multithreading-safe (MT-safe),
> thanks for pushing the issue ;-)

Thanks to you for your commitment! :)

> The following pointers should make it easy to make the FeatureIndex
> MT-safe. I haven't looked into the details, but it would probably be
> best to use the Mutexes (or Read/Write locks) on the interface level
> to avoid reimplementation for every FeatureIndex implementation.

Yes, that's what I did (in annotationsketch/feature_index.c).

> - If I didn't miss something, everything with a global state in 
> libgenometools should be MT-safe now (file allocator, symbol and 
> random number generator module). The memory allocator is MT-safe, if 
> the memory bookkeeping is not used. Making the memory bookkeeping 
> MT-safe is not possible without a major redesign which I consider 
> low-priority.

Agreed. Making the reference counting thread-safe is another major
issue, IMHO. What do you think?

> - Testing is even more important for multithreaded-code! I thought 
> twice the memory allocator with bookkeeping is now MT-safe before I 
> realized it is not possible with the current design. As a testing
> strategy, I added a -j development option to the gt binary which can
> then be used in the unit tests to start parallel threads to stress
> test the corresponding data structure in parallel (gt_multithread()
> starts -j many threads, see core/symbol.c for an example).

Very useful. Do you think we should add a multithreading test case to
every unit test when the class in question has been modified for
thread-safety?

> If possible, store the mutexes or read/write-locks in the data 
> structure itself and not globally, as in the file allocator module.

Sounds natural.

> - The valgrind tool helgrind is your friend (valgrind 
> --tool=helgrind)! Without it I would still wonder why the memory 
> allocator with bookkeeping isn't MT-safe. The valgrind tool DTD
> might be useful, too.

Cool. I will familiarize myself with that.

> @Sascha: Could you look into making the FeatureIndex MT-safe? It 
> shouldn't be much work at this point as the basic infrastructure is 
> already there. If anything of the above is unclear or questions
> arise, please ask!

Yes, I am working on that. Synchronizing the read/write accesses to the
FeatureIndex is quite simple, I will also test everything later and
report back when I am ready.

> Gordon

Sascha

-- 
Sascha Steinbiss
Center for Bioinformatics
University of Hamburg
Bundesstr. 43
20146 Hamburg
Germany

Email:  steinbiss at zbh.uni-hamburg.de
URL:    http://www.zbh.uni-hamburg.de/steinbiss
Phone:  +49 (40) 42838 7322
FAX:    +49 (40) 42838 7312



More information about the gt-users mailing list