Skip to main content

ImageReader thread safety

8 replies [Last post]
newmanw10
Offline
Joined: 2009-08-17
Points: 0

I am using an api (imageio-ext) that is synchronizing a private map winthin thier custom ImageReader. The map is not static. I have always assumed that they did this because maybe imageio would hold on to readers and give the same instance. However after reading this: http://docs.oracle.com/javase/1.4.2/docs/guide/imageio/spec/goals.fm2.html, I am not so sure that is the case.

When imageio uses the SPI to create a reader does it always create a new reader?

i.e. If I don't specify a reader SPI should create a reader for me (and it does), but will I always get a new one?

ParameterBlockJAI params = new ParameterBlockJAI();

params.setSource(imageFile);

JAI.create("ImageRead", params);

If I will always get a new reader I am a little puzzled by imageio-ext synchronization.

If I am missing something please let me know, thanks in advance/

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rgd
Offline
Joined: 2005-08-23
Points: 0

I don't know as that's not something I've tried. However, if you're
worried about it, you can always create your own ImageReader instance
and pass it in as a parameter to the imageread operation. I would be
somewhat surprised if it cached reader instances, but you can trace down
through the source code to find out.

The syncing within the reader implementation may simply be protection
against someone trying to use the same reader from multiple threads.
Even if JAI.create() were to return a new instance every time, that
wouldn't prevent someone from using the same reader (either via
imageread or directly) from multiple threads. So it may just be
defensive programming.

-Bob

On 2/2/12 5:26 PM, forums@java.net wrote:
> I am using an api (imageio-ext) that is synchronizing a private map winthin
> thier custom ImageReader. The map is not static. I have always assumed
> that they did this because maybe imageio would hold on to readers and give
> the same instance. However after reading this:
> http://docs.oracle.com/javase/1.4.2/docs/guide/imageio/spec/goals.fm2.html,
> I
> am not so sure that is the case.
>
> When imageio uses the SPI to create a reader does it always create a new
> reader?
>
> i.e. If I don't specify a reader SPI should create a reader for me (and it
> does), but will I always get a new one?
>
> ParameterBlockJAI params = new ParameterBlockJAI();
>
> params.setSource(imageFile);
>
> JAI.create("ImageRead", params);
>
>
>
> If I will always get a new reader I am a little puzzled by imageio-ext
> synchronization.
>
> If I am missing something please let me know, thanks in advance/
>
>
>
>

newmanw10
Offline
Joined: 2009-08-17
Points: 0

Are readers expensive to create? I.E. is it common to use the same reader in multiple threads?

simboss1
Offline
Joined: 2005-08-08
Points: 0

Ciao,
generally speaking imageio does not require imagereader instances to
be thread safe, the same applies to imageio-ext.

However, for some of the plugins which we developed, e.g. the one to
connect to JP2 using Kakadu or the one to use the GDAL library, we
managed to make
possible to make multiple parallel calls to the read* methods of the
same reader safe, we also developed a replacement of the ImageRead
operation so that you can
load multiple tiles from some format in _real_ parallel.

To be more explicit, here is the pseudo code:

- create an imagereader
- set the input (now the reader is initialized)
- perform multiple read in parallel to load different tiles from the same source

Notice that:
-1- JAI ImageRead does synchronized on the provided/created reader
therefore it is impossible to load more tha on tile at a time with a
renderedimage created via ImageRead
-2- Our own ImageRead operation relaxes this constraint by requiring
readparams to be clonable and therefore allowing to load multiple
tiles for the same renderedimage with _real_ parallelism

On a different line, yes, reader are expensive to create since they
open files and read metadata so we try to cache them as much as
possible. Think about
creating a reader to read a large geotiff. Depending on how the
geotiff is configured the metadata can be huge (order of MB),
therefore it can be crucial to properly cache and reuse such readers.

Regards,
Simone Giannecchini

newmanw10
Offline
Joined: 2009-08-17
Points: 0

Thanks Simone!

I do have the issue in which my source images do not have multiple tiles, (one tile per image). I would like to open/read mulitple source files in parrallel. Unfortunatly becuase the open is synchronus my threads spend a lot of time blocking each other waiting to read. Each mosiac operation may contain hundereds (or more) reads on different source files. It is a tremendous speed up to remove the synchronization but I have to recompile the code to do that.

Any other ideas? Thanks for the responses so far. You have been a huge help.

simboss1
Offline
Joined: 2005-08-08
Points: 0

Ciao,
In order to help out we need more info. First of all, what kind of format
are you trying to read with imageio-ext? Moreover, where in our code is the
synchronization you are talking about? It would also be good to have an
isolated test case that shows the synchronization code biting you. We mght
find ways to improve eith your code or the imageio-ext one.

Regards,
Simone.

On Saturday, February 4, 2012, wrote:
> Thanks Simone!
>
> I do have the issue in which my source images do not have multiple tiles,
> (one tile per image). I would like to open/read mulitple source files in
> parrallel. Unfortunatly becuase the open is synchronus my threads spend
a
> lot of time blocking each other waiting to read. Each mosiac operation
may
> contain hundereds (or more) reads on different source files. It is a
> tremendous speed up to remove the synchronization but I have to recompile
> the code to do that.
>
> Any other ideas? Thanks for the responses so far. You have been a huge
> help.
>
>

newmanw10
Offline
Joined: 2009-08-17
Points: 0

Simone,

Thought that since we are talking specifically about imageio-ext this would be more appropriate in the imageio-ext mailing list.

Please look here:

http://java.net/projects/imageio-ext/lists/users/archive/2012-02/message/0

simboss1
Offline
Joined: 2005-08-08
Points: 0

kk

Regards,
Simone Giannecchini

imagero
Offline
Joined: 2003-11-18
Points: 0

Wow, that's really weird design.

You might use JPEGCodec class (assuming you need to read jpeg files).

Or you may try Imagero, which making extensive use of multithreading.