LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2006
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2006.09.22 17:09 "Re: libjpeg", by Bob Friesenhahn
On Fri, 22 Sep 2006, Philip Watkinson wrote: > > 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/