2006.09.23 01:45 "Re: [Tiff] libjpeg", by Bob Friesenhahn

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.

Bob, in the popular arena, it's practically been and gone! :-)

Yes, in the popular (i.e. Intel) arena. IBM and Sun are pushing hard on the multi-thread approach and I believe that AMD is doing research in this area. It is mostly useful for large servers and scientific applications. PCs already have more power than they know what to do with and they mostly only do a few things at a time.

SMT (Simultaneous MultiThreading, or Hyper-Threading Technology, as Intel like to call it) is a Pentium 4 feature, and Pentium 4's are now being phased out in favour of the Core architecture (which is more of a reversion to the P6/PentiumPro/Pentium3 scheme of things). Currently no Core processor supports SMT (although I guess it may appear again at some stage, and/or other manufacturers may incorporate it), instead all the emphasis in the x86 world now seems to be on multi core processors, where each core only executes one thread.

It seems that Intel's approach was not as successful as was hoped for. The processor memory bandwidth has been insufficient to keep the cores adequately fed and if Intel was to provide the needed bandwidth, their product would be too expensive for their market.

Just to comment on thread safety, another tool available to solve some of these sorts of problems is thread local storage. MSWindows certainly has it, and so apparently does POSIX threads.

Yes. The MSWindows versions of thread local storage now has a bug in that it can only store a 32 bit 'long' value. This is an annoying problem now that 64-bits is emerging in Windows and the most common thing stored is a pointer. The POSIX version is always capable of storing at least the size of a pointer.

My understanding is that libjpeg and libpng have used the setjmp/longjump scheme as a poor-man's form of exceptions which means it is also necessary to control the execution flow. Thread specific storage is ok for reporting errors as long as there is a programmed error return path to return immediately to the invoker.

For libtiff, I was able to use thread specific storage to store the error information reported by libtiff for later use. But libtiff is designed to return without requiring the equivalent of an exception thrown by a callback function.

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