2006.09.22 17:09 "RE: [Tiff] libjpeg", by Bob Friesenhahn

I just did some searching on the Internet and found the following from March 2000:

libjpeg is thread-safe as long as (a) you don't have multiple threads operating concurrently on the same jpeg object, and (b) your underlying C library (particularly malloc/free) is thread-safe. You can have multiple jpeg objects being manipulated concurrently by different threads.

In this case, "underlying C library" would need to include setjmp/longjmp. While these may be thread safe on certain CPUs/platforms, portable software can not rely on them to be thread safe. If a platform does not document these APIs to be thread safe, then even if the current version of the platform happens to implement thread safe versions, the implementation in a future version of the platform might not be thread safe.

Applications and libraries can only be considered thread safe if they can be *proven* to be thread safe. Use of any non-safe API voids the warranty.

The next (latest?) big thing in CPU architectures is to provide hardware support for thread contexts so that if a thread would be delayed by a slow memory access, a different thread can be scheduled to run instantaneously. This is seen as yet another tool to improve efficiency when memory access is the bottleneck. Previously we have seen VLIW, deep memory pipelining, and speculative scheduling, used to try to ease the bottleneck. The upshot of this is that the underlying execution model is becoming more and more complex and the situation is not likely to improve for setjmp/longjmp.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/