Re: [Openexr-devel] Thread safety

[Peter Hillman]

On 04/03/2013 12:25 PM, Larry Gritz wrote:
> > (This does assume that IlmThread's Lock mechanism is compatible with the way 
> > your threads are created).
> I'm not sure I followed that statement. Huh?
I'd understood that there are some high performance threading libraries 
which aren't pthread compatible. On Posix systems, for example, 
IlmThread::Mutex::lock() calls pthread_mutex_lock(). This might not 
actually lock the thread if it is some exotic thread implementation 
unrelated to pthread. If you are using pthread, windows threads, or 
better still the IlmThread library, all will be well.

> My threads do each set up separate frame buffers.  It's too bad the framebuffer 
> isn't an argument to readPixels/readTiles rather than set by a separate call to 
> setFrameBuffer
There'd be little point in passing a framebuffer to readpixels unless 
the file read is separated from decoding the pixel data, in the same way 
that the rawpixel approach does in deepscanlines.
Under the hood, it might as well just do a lock, setframebuffer, 
readpixels, unlock. It might be worth extending the deepscanline 
rawpixel approach to regular images


> > As always, the fastest way to read EXRs is to read as much of the file as 
> > possible in a single call, and let the EXR library manage its own threads.
> Ha ha, yeah, until you have 2 TB of image files you're accessing incoherently.
Oh dear.  Perhaps it might be worth the effort of implementing some 
super system with a single thread that handles calls to 
readPixels/readTiles, with other threads post requests to that and wait 
for the reply. That thread can reorder the requests to reduce the amount 
of file seeking that takes place. I'm guessing that file seeks are far 
more expensive than decoding pixels.

Rather you than me :-)

Peter