TIFF and LibTiff Mail List Archive

2007.03.23 15:49 "[Tiff] Any known problems with using libtiff G4 compression in a multithreaded application?", by Tim Tomassi


I am using libtiff-3.7.2 as a compression engine within an application that I am developing. I use TIFFClientOpen() so that I can receive data buffers from both the LZW and the G4 compression engines into my TIFFWriteProc().

I am in the process of expanding my application so that it works efficiently on SMP hardware. To do this, I launch a set of of worker threads and open an equivalent number of TIFF files with TIFFClientOpen(). The threads each deliver uncompressed data to libtiff in parallel, with each separate TIFF file getting a different band of data to compress. Within my TIFFWriteProc(), I serialize the strips of compressed data that I receive from libtiff and write it out to the actual destination file.

I am encountering intermittent data corruption of individual strips when I execute my application with more than one thread. However, this corruption only occurs when the G4 compression feature of libtiff is used. LZW compression never experiences any corruption, regardless of the number of threads I run. This leads me to suspect that the G4 compression engine might have some type of problem if more than one band of data is being compressed simultaneously within the library. I have scanned tif_fax3.c, looking for obvious examples of non-thread-safe code, but I don't have a lot of experience with the internals of libtiff, so I easily could have missed something.

Are there any data structures within libtiff that might preclude it from being used simultaneously with more than one open TIFF file? Are there other areas where libtiff might not be multithread safe, and could cause errors in the G4 compression if the engine is used to compress multiple buffers simultaneously?

Tim Tomassi