AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

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
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



Thread

2006.09.22 14:20 "libjpeg", by Philip Watkinson
2006.09.22 14:31 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 15:22 "Re: libjpeg", by Joris Van Damme
2006.09.22 16:31 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 16:49 "Re: libjpeg", by Philip Watkinson
2006.09.22 17:09 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 17:25 "Re: libjpeg", by Joris Van Damme
2006.09.23 00:51 "Re: libjpeg", by Graeme Gill
2006.09.23 01:45 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 15:20 "Re: libjpeg", by Joris Van Damme
2006.09.22 16:42 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 17:31 "Re: libjpeg", by Joris Van Damme
2006.09.22 18:09 "Re: libjpeg", by Toby Thain
2006.09.22 18:16 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 19:21 "Re: libjpeg", by Joris Van Damme
2006.09.22 18:29 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 19:18 "Re: libjpeg", by Joris Van Damme
2006.09.22 20:09 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 20:21 "Re: libjpeg", by Joris Van Damme

2006.09.23 01:45 "Re: libjpeg", by Bob Friesenhahn

On Sat, 23 Sep 2006, Graeme Gill wrote:

> Bob Friesenhahn wrote:
>> 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/